Users
Each user of ThingWorx must be defined.
User names can be email addresses. User names cannot include the following characters:
• & (ampersand)
• : (colon)
 |
In ThingWorx 8.4.7 and later, colons are accepted in user names, although you will not be able to log in through the basic authenticator, and Active Directory does not support the colon character in user names. Other forms of authentication are supported, such as form login and custom authenticators.
|
• / (forward slash)
• + (plus sign)
For more information, see Naming Entities.
A user can belong to any number of groups and can be assigned most combinations of rights and permissions. Unlike Things, users do not have services, events, or subscriptions.
You can access properties for the current user (the user who is logged in) in the Mashup Builder on the User tab. They are also available in a mashup at run time. You can create and clone users at run time using the resources service library.
Default Users
|
Default User
|
Details
|
|---|---|
|
Administrator
|
The Administrator is a default user account that cannot be deleted. The Administrator has create, read, update, and delete permissions for all entities and all run time execution permissions.
|
|
SuperUser
|
If you are using the Extension SDK for extension development and you need to access a secured resource to which the user making the request may not have access, you can generate the super user or system user contexts using the appropriate factory methods. You must ensure that the security context is only used to access the secured resources that are needed for proper functionality.
|
|
System User
|
See System User for more information.
|
Guidelines for Naming Users
PTC strongly recommends the following:
• Do not include sensitive information in user names.
• For highly sensitive use cases, consider employing arbitrarily-assigned or random user names instead of deriving them from user-defined public data, in accordance with OWASP recommendations.
Configuring Permissions for Non-administrator Users and Debugging Error Messages
Non-administrator users do not have any permissions out of the box. They cannot view anything until explicitly permitted by an Administrator. Follow these tips to configure new users and to debug error messages when certain actions are restricted:
• New users must be placed in the ComposerUser user group in ThingWorx. This will allow the user to log into Composer with run time service invoke permissions.
• If there are other actions that a user should have but they appear to be restricted, an Administrator user can debug using the Application Log. Look for error-level messages which indicate that an entity may be missing or some other function cannot be authorized. The following are example error messages:
◦ Entity Not Found : [CurrentSessionInfo]] indicates that an Administrator must grant the non-administrator user visibility permissions to see the CurrentSessionInfo resource.
◦ Not authorized for ServiceInvoke on GetDaysRemainingInLicense in LicensingSubsystem] indicates that a run time service invoke permission for the GetDaysRemainingInLicense service on the licensing subsystem is missing for that non-administrator user.
• Any user entities that are migrated from a pre-existing version of ThingWorx (prior to 8.4.0) must be manually added to the ComposerUsers user group. ThingWorx will not migrate imported user entities into the ComposerUsers user group automatically.
User Extensions
A user can have any number of properties, called user extensions. User extension properties are stored in configuration tables (they are all strongly-typed STRINGS). Due to this, it is not possible to add an infotable property into the user extensions' Data Shape and then set a value in that infotable for the user. The most common use of configuration tables is to store credentials and host information for an external resource. Configuration Tables should not be used for storing dynamic data that is updated frequently.
|
|
Since the User Extensions configuration table is a unique type of configuration table that does not use a simple DataShape structure, there are services that cannot be used to modify it. These services are SetConfigurationTable, SetConfigurationTableRows, and SetMultiRowConfigurationTable.
|
To modify a user extensions configuration, edit its Thing Shape under > > .
If you allow a password reset for users, the following user extension properties are required:
• firstName
• lastName
• emailAddress
User Permissions on Services
Services are explicitly designed to not require permissions for the user initiating the service. For example, users can change their own passwords. You cannot prevent a user from using any service on their own account.
Language Preference
In the Languages field, an administrator who knows the names of available languages can enter an ordered comma-separated list (for example, ca,es,hu,fr-CA) or select from a list of available languages. The first language listed is the preferred language for the user. If a user does not have language preferences set, the Default and System localization tables are used.
The displayed value (translation) of a localization token is determined by the user’s language preferences, the localization tables configured in the system, and the translation for the token existing in the specified localization tables.
For example, a user's language preference is fr,pt,ru,hi (French, Portuguese, Russian, Hindi). The system is configured with localization tables for es (Spanish), fr-CA (Canadian French), it (Italian),pt-BR (Brazilian Portuguese), ru (Russian), and the default (likely English). The system is searching for a value for a given token. The system first looks for a fr localization table, which exists. However, the token is not included in the fr localization table. Therefore, the system continues to the pt localization table. There is no pt localization table in the system. Therefore, it continues to ru. The system finds the ru localization table and the token. The token has a value, so that value is displayed on the UI.