Benutzer
Jeder Benutzer von ThingWorx muss definiert werden.
Benutzernamen können E-Mail-Adressen sein. Benutzername dürfen die folgenden Zeichen nicht enthalten:
& (kaufmännisches Und-Zeichen)
: (Doppelpunkt)
* 
In ThingWorx 8.4.7 und höher sind Doppelpunkte in Benutzernamen zulässig, obwohl Sie sich nicht über den Standardauthentifikators anmelden können und Active Directory den Doppelpunkt in Benutzernamen nicht unterstützt. Andere Formen der Authentifizierung werden unterstützt, z.B. Formularanmeldung und benutzerdefinierte Authentifikatoren.
/ (Schrägstrich)
+ (Pluszeichen)
Weitere Informationen finden Sie unter Entitäten benennen.
Ein Benutzer kann beliebig vielen Gruppen angehören und den meisten Kombinationen von Rechten und Berechtigungen zugewiesen werden. Im Gegensatz zu Dingen haben Benutzer keine Dienste, Ereignisse oder Abonnements.
Sie können auf Eigenschaften für den aktuellen Benutzer (den angemeldeten Benutzer) im Mashup Builder auf der Registerkarte Benutzer zugreifen. Sie sind auch in einem Mashup zur Laufzeit verfügbar. Sie können Benutzer zur Laufzeit mithilfe der Ressourcen-Dienstbibliothek erstellen und klonen.
Standardbenutzer
Standardbenutzer
Details
Administrator
Der Administrator ist ein Standardbenutzerkonto, das nicht gelöscht werden kann. Der Administrator hat Berechtigungen zum Erstellen, Lesen, Aktualisieren und Löschen für alle Entitäten und alle Ausführungsberechtigungen zur Laufzeit.
Superuser
Wenn Sie das Extension SDK für die Erweiterungsentwicklung verwenden und auf eine gesicherte Ressource zugreifen müssen, auf die der Benutzer, der die Anforderung stellt, möglicherweise keinen Zugriff hat, können Sie den Superuser- oder Systembenutzer-Kontext mithilfe der entsprechenden Factory-Methoden generieren. Sie müssen sicherstellen, dass der Sicherheitskontext nur zum Zugreifen auf die gesicherten Ressourcen verwendet wird, die für die ordnungsgemäße Funktionalität erforderlich sind.
Systembenutzer
Weitere Informationen finden Sie unter Systembenutzer.
Richtlinien für das Benennen von Benutzern
PTC empfiehlt dringend Folgendes:
Schließen Sie keine sensiblen Informationen in Benutzernamen ein.
Für hochsensible Anwendungsfälle sollten Sie gemäß OWASP-Empfehlungen willkürlich zugewiesene oder zufällige Benutzernamen verwenden, anstatt sie aus benutzerdefinierten öffentlichen Daten abzuleiten.
Berechtigungen für Nicht-Administratoren konfigurieren und Fehlermeldungen debuggen
Nicht-Administratoren haben keine Standardberechtigungen. Sie können nichts anzeigen, bis ihnen dies explizit von einem Administrator erlaubt wird. Befolgen Sie diese Tipps, um neue Benutzer zu konfigurieren und Fehlermeldungen zu debuggen, wenn bestimmte Aktionen eingeschränkt sind:
Neue Benutzer müssen in der ComposerUser Benutzergruppe in ThingWorx platziert werden. Dies ermöglicht es dem Benutzer, sich bei Composer mit Aufrufberechtigungen für den Laufzeitdienst anzumelden.
Wenn ein Benutzer andere Aktionen ausführen können soll, diese jedoch eingeschränkt sind, kann ein Administrator mithilfe des Anwendungsprotokolls debuggen. Suchen Sie nach Fehlermeldungen, die angeben, dass eine Entität fehlt oder dass eine andere Funktion nicht autorisiert werden kann. Im Folgenden finden Sie Beispiel-Fehlermeldungen:
Entity Not Found : [CurrentSessionInfo]] gibt an, dass ein Administrator dem Nicht-Administrator Sichtbarkeitsberechtigungen zum Anzeigen der CurrentSessionInfo-Ressource gewähren muss.
Not authorized for ServiceInvoke on GetDaysRemainingInLicense in LicensingSubsystem] gibt an, dass eine Laufzeitberechtigung zum Aufrufen von Diensten für den GetDaysRemainingInLicense-Dienst im Untersystem für die Lizenzierung für diesen Nicht-Administrator fehlt.
Alle Benutzerentitäten, die von einer bereits vorhandenen Version von ThingWorx (vor 8.4.0) migriert werden müssen, müssen manuell zur Benutzergruppe ComposerUsers hinzugefügt werden. ThingWorx migriert nicht importierte Benutzerentitäten automatisch in die ComposerUsers-Benutzergruppe.
Benutzererweiterungen
Ein Benutzer kann über eine beliebige Anzahl von Eigenschaften verfügen, die als Benutzererweiterungen bezeichnet werden. Benutzererweiterungseigenschaften werden in Konfigurationstabellen gespeichert. (Es handelt sich um stark typisierte ZEICHENFOLGEN.) Aus diesem Grund ist es nicht möglich, eine Infotable-Eigenschaft im Data Shape der Benutzererweiterungen hinzuzufügen und dann einen Wert in dieser Infotable für den Benutzer festzulegen. Am häufigsten werden Konfigurationstabellen zum Speichern von Anmeldeinformationen und Hostinformationen für eine externe Ressource verwendet. Konfigurationstabellen sollten nicht zum Speichern dynamischer Daten verwendet werden, die häufig aktualisiert werden.
* 
Da die Konfigurationstabelle der Benutzererweiterungen ein eindeutiger Typ von Konfigurationstabelle ist, die keine einfache DataShape-Struktur verwendet, gibt es Dienste, die nicht verwendet werden können, um sie zu ändern. Diese Dienste sind SetConfigurationTable, SetConfigurationTableRows und SetMultiRowConfigurationTable.
Um die Konfiguration für Benutzererweiterungen zu ändern, bearbeiten Sie die zugehörige Dingform unter Modellierung > Dingformen > Benutzererweiterungen.
Wenn Sie das Zurücksetzen des Passworts für Benutzer zulassen, sind die folgenden Benutzererweiterungseigenschaften erforderlich:
firstName
lastName
emailAddress
Benutzerberechtigungen für Dienste
Dienste sind explizit so konzipiert, dass der Benutzer, der den Dienst initiiert, keine Berechtigungen benötigt. Beispielsweise können Benutzer ihre eigenen Passwörter ändern. Sie können nicht verhindern, dass ein Benutzer einen Dienst für sein eigenes Konto verwendet.
Spracheinstellung
Im Feld Sprachen kann ein Administrator, der die Namen verfügbarer Sprachen kennt, eine sortierte kommagetrennte Liste eingeben (beispielsweise ca,es,hu,fr-CA) oder in einer Liste der verfügbaren Sprachen auswählen. Die erste aufgelistete Sprache ist die bevorzugte Sprache für den Benutzer. Wenn für einen Benutzer keine Spracheinstellungen festgelegt sind, werden die Lokalisierungstabellen Standard und System verwendet.
Der angezeigte Wert (Übersetzung) eines Lokalisierungs-Tokens wird durch die Spracheinstellungen des Benutzers, die im System konfigurierten Lokalisierungstabellen und die Übersetzung für das Token bestimmt, die in den angegebenen Lokalisierungstabellen vorhanden ist.
Beispiel: Die Spracheinstellung eines Benutzers ist fr,pt,ru,hi (Französisch, Portugiesisch, Russisch, Hindi). Das System ist mit Lokalisierungstabellen für es (Spanisch), fr-CA (kanadisches Französisch), it (Italienisch),pt-BR (brasilianisches Portugiesisch), ru (Russisch) und die Standardsprache (vermutlich Englisch) konfiguriert. Das System sucht nach einem Wert für ein angegebenes Token. Das System sucht zuerst nach einer Lokalisierungstabelle fr, die vorhanden ist. Allerdings ist das Token nicht in der Lokalisierungstabelle fr enthalten. Daher wechselt das System zur Lokalisierungstabelle pt. Es gibt keine Lokalisierungstabelle pt im System. Daher fährt es zu ru fort. Das System findet die Lokalisierungstabelle ru und das Token. Das Token hat einen Wert, daher wird dieser Wert in der Benutzeroberfläche angezeigt.
War dies hilfreich?