Unable to push CSDK properties to ThingWorx 10.0.0

[mneumann]

Hi,

I just installed ThingWorx 10.0.0 and created a service that will create

• User
• ApplicationKey for this User
• Organization with a Top Organizational Unit with the User as a Member

After this, the service create a new RemoteThing and sets visibility to the Organization and adds Runtime Permissions (property read/write, service invoke, event invoke/subscribe) and Design Time Permissions (Read).

With the ApplicationKey and thing name I can now connect a CSDK application.

The application has three properties and on changing the status of the "isConnected" property, the Platform will run a service that will create these remote properties on the RemoteThing.

However, when running the CSDK I can see that the properties are connected but they fail to synchronise with the following error in the CSDK:

[ERROR] 2025-08-20 10:58:30,206: twSubscribedPropsMgr_PushPropertyInfoList: Error pushing properties for ON1111-2. Error: 1111.
[ERROR] 2025-08-20 10:58:30,206: twSubscribedPropsMgr_PushProperties: error pushing or persisting property list, code: 1111

This continues throughout any restart of the CSDK (where properties are no longer touched on the RemoteThing). Only when restarting ThingWorx, the properties will synchronise.

Why would this be blocked, but starts working after a ThingWorx restart?

There seems to be some kind of permission issue, because everything works just fine with an Administrator-ApplicationKey.

Thanks for your help,

Michael

[mneumann]

- deleted due to a temporary hiccup that made it work.

The issue still continues.

[Constantine · Accepted solution]

If you change the owner, then you should be able to remove all other permissions. You might want to check services like SetPropertyValues instead.

Beware — Allowing a remote device own some entities has pretty deep security implications. If I remember correctly, it also grants design time ones, meaning you can impersonate System.

/ Constantine

[mneumann]

Thanks Constantine!

I somehow managed to make the original issue work.

You have a good point about ownership here.

For now I created a generic user (without password nor any other permissions) that owns all remote devices, and I kept the assigned permissions for the Things themselves. Before that, we had the owner set to whoever created the device, but that put unnecessary ownership questions to the original creators.

[Constantine]

I've done a few security audits for ThingWorx apps, and concluded that things ownership is one of the worst-understood concepts, which is especially painful for the IoT projects, where everyone expects some degree of dynamic Things provisioning.

Once I was able to demonstrate a permission escalation that allowed me to obtain passwords for ActiveDirectory users just by compromising a single device, which was auto-provisioned and had its own unique AppKey. Crazy things can be (could have been?) done if you don't reset ownership on those things after calling CreateThing().

[nmutter]

yes Owner is a security issue. and still no easy way to 'workaround' it. My idea was unfortunately archived

https://community.ptc.com/t5/ThingWorx-Ideas/Allow-entity-creation-with-a-different-Owner-for-non/idi-p/874464 

[mneumann]

@Constantine yeah, I am trying to restrict everything as much as possible - but there are some issues that just don't work. That new user with no permissions and no visibility on anything can still see a lot of stuff (including some Subsystems and Resources) when calling the REST API /Thingworx/Server
I will probably report this via a Security case to PTC.

@nmutter maybe they picked up your idea I am now creating my Entities with

Resources["EntityServices"].CreateThingWithOwner()

where I can directly set the owner during creation.
It would be great though, if the Thing could be created directly with owner AND permissions. But I just call a second service to update the permissions after the creation.

[nmutter]

Thanks. Yes, the service CreateThingWithOwner exists, but is only usable by Administrators (mentioned in the idea). Which is not what I wanted.

Yes, I wanted exactly what you mention as well: Create thing with custom owner and with permissions (added this permission issue as a comment in my ide).