How do I set a User Profile Configuration with a service?

[mneumann]

Hi...

I have user for Remote Devices, which do not have a password - so they are unable to login anyway.

However, some of these - for troubleshooting - will receive a password, but should be extremely restricted in what they can do / see.

This includes the User Profile Configuration with all the available menu points.

How can I empty all of these (except for "Modelling - Things") ?

I tried to use the ConfigurationTable, but was not successful.

When exporting to xml, I can see that the "Settings" Configuration Table does not have a dataShapeName.

However, the service requires an InfoTable with a DataShape, so therefore the ConfigurationTable is not updated.

I do not want to do this manually as per https://support.ptc.com/help/thingworx/platform/r9.6/en/index.html#page/ThingWorx/Help/Composer/Security/Users/UserProfileConfiguration.html#wwID0EY64Y ... so how can I do this via a service?

[nmutter]

you can get current configuration via

// result: JSON
result = Users["Test"].GetPersistentValue({
	name: "profileConfiguration" /* STRING */
});

and set it back via SetPersistentValue

[mneumann]

Thanks!

I tried to run the service on several users, but it always returns empty.

That indicates that the service does exist but does not return any valid JSON result. Maybe there was a change with ThingWorx 10.0.0.

I checked in PostgreSQL and didn't find any kind of profile configuration in the user tables.

I'll continue to check where this will be stored - because, in the end, I think users should not have ALL rights and permissions by default. It needs to be an additive model instead of a subtractive one.

[nmutter]

You are (somewhat) right, interesting.

If I did not save the profile configuration in composer for the user first, I do get empty result.

If I saved it once I do get the result.

It seems that it does not return the "default" settings. But for sure you could write the settings to it.

So the services work as desribed before but you need to handle the case where it was not yet changed. (also works in twx 10)

[mneumann]

D'oh .... I have tried to save and save and save the Profile without anything ever returned in the service.

It seems like you need to do at least one change to persist it, otherwise it defaults to all=true. If there was no change, it never persists.

After this, I am then able to actually get a result.

I'm using this now to block all menu-items except for "Modelling > Things".

This will then just be an additional measure, but should be covered by removing access to the Composer completely.

But the service returns something useful now
Thanks for pointing this out!

[Constantine · Accepted solution]

You might not need to touch those profiles. From your other post, I'd suggest you start by removing Users from ComposerUsers. I've just checked -- and I don't see Subsystems and Resources then.

They won't be able to access Composer then, so you'd need to troubleshoot via HTTP directly, e.g. something like Postman, curl or writing shell scripts with ThingWorx CLI.

---

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

[mneumann]

Thanks Constantine!

In addition to your suggestions I changed the following and the only stuff I now see via the REST API is one Thing and one User, when using the device's credentials. Our use case is that only a specific Admin-group and maybe a handful of developers should have access to ThingWorx, as we don't use Mashups for viewing and analysing the data.

Project: PTCDefaultProject

• remove Visibility for Everyone

• add Visibility for Composer:Composer to only allow visibility for users that are in the Composer’s organisation - by default this is the ComposerUsers group

User Group: ComposerUsers

• remove all members

• add members that are allowed to access the Composer:

  • Administrators group

[Constantine]

@mneumann Just be careful with that ComposerUsers group -- removing users from it has some non-trivial implications which go beyond access to Composer. Search in Help for "ComposerUsers" to get more info, for example check this: https://support.ptc.com/help/thingworx/platform/r9.6/en/index.html#page/ThingWorx/Help/Composer/Security/UserGroups.html

Tl;dr -- if those are real human users and you just want to hide Composer from them, you'd need to add some permissions manually one by one, so that they can access normal mashups after that. For example, you'd need to grant permissions to CurrentSessionInfo, which they'll lose once you remove them from ComposerUsers. Of course, for "device" users it's OK because they won't ever try to access mashups, but your Users group also contains innocent people, which will get affected once you apply this change. You'll need to decide what is the best way to do this -- for example, you can split your users into two large groups like "Devices" and "People", and put the latter back into ComposerUsers, if that's OK from your organization's point of view. Or keep only admins in your ComposerUsers, and then grant those missing permissions to People group.

/ Constantine

[mneumann]

I think that should be fine. We will only have a handful of Administrators that use the system ... plus a handful of users in a Developer role, that should be able to check (some of the) devices.

Once we are at the stage where we bring in the Developers, I should of course not forget to add them into the ComposerUsers group

Our use-case is that we expose and show ThingWorx data only via Grafana and custom micro services, that allow us to query exactly what is needed. Most device data is streamed into InfluxDB and then displayed in a custom app. Our users / customers will never be exposed to ThingWorx Mashups.

Only Administrators and Developers will be able to view the data directly IN ThingWorx, and then of course the RemoteDevice-Users will send data TO ThingWorx.