ユーザー
ThingWorx の各ユーザーを定義しなければなりません。
ユーザー名は電子メールアドレスでも構いません。ユーザー名に、以下の文字を含むことはできません。
& (アンパサンド)
: (コロン)
* 
ThingWorx 8.4.7 以降ではユーザー名にコロンを使用できますが、基本認証システムを介してログインすることはできず、Active Directory はコロン文字が含まれているユーザー名をサポートしていません。その他の形式の認証 (フォームログインやカスタム認証システムなど) はサポートされています。
/ (スラッシュ)
+ (プラス記号)
詳細については、エンティティの名前付けを参照してください。
ユーザーは任意の数のグループに属することができ、権限とアクセス許可のほぼすべての組み合わせを割り当てできます。Thing とは異なり、ユーザーはサービス、イベント、またはサブスクリプションを持ちません。
Mashup Builder の「ユーザー」タブで、現在のユーザー (ログインしているユーザー) のプロパティにアクセスできます。これらのプロパティは、ランタイムではマッシュアップ内でも使用できます。リソースサービスライブラリを使用して、ランタイムでユーザーを作成および複製できます。
デフォルトのユーザー
デフォルトのユーザー
詳細
管理者
「管理者」はデフォルトのユーザーアカウントで、削除できません。「管理者」には、すべてのエンティティに対する作成、読み取り、更新、および削除のアクセス許可、およびすべてのランタイム実行アクセス許可が付与されています。
SuperUser
拡張機能の開発に Extension SDK を使用していて、リクエスト元のユーザーにはアクセス許可が付与されていない可能性があるセキュアリソースにアクセスしなければならない場合は、適切なファクトリメソッドを使用して、スーパーユーザーまたはシステムユーザーのコンテキストを生成できます。セキュリティコンテキストの使用は、正しい機能のために必要なセキュアリソースにアクセスする目的のみに限る必要があります。
システムユーザー
詳細については、システムユーザーを参照してください。
ユーザーのネーミングに関するガイドライン
以下の推奨事項に従うことを強くお勧めします。
ユーザー名に機密情報を含めないでください。
機密性の高いユースケースの場合は、OWASP の推奨事項に従って、ユーザー定義のパブリックデータからユーザー名を派生させるのではなく、任意に割り当てられたユーザー名またはランダムなユーザー名を使用することを検討してください。
非管理者ユーザーのアクセス許可の設定とエラーメッセージのデバッグ
非管理者ユーザーには既成ではアクセス許可が付与されていません。これらのユーザーは、「管理者」が明示的に許可するまで、何も表示されません。新規ユーザーを設定し、特定の操作が制限されている場合にエラーメッセージをデバッグするには、以下のヒントに従います。
新規ユーザーは ThingWorx の ComposerUser ユーザーグループに配置する必要があります。これにより、そのユーザーは Composer にログイン可能になり、ランタイムサービス呼び出しのアクセス許可が付与されます。
ユーザーに必要なその他の操作が制限されている場合、「管理者」ユーザーはアプリケーションログを使用してデバッグできます。エンティティが欠落してる可能性や、その他の機能を承認できないことを示す、エラーレベルメッセージを探します。以下にエラーメッセージの例を示します。
Entity Not Found : [CurrentSessionInfo]] は、「管理者」が非管理者ユーザーに CurrentSessionInfo リソースを表示するための表示アクセス許可を付与しなければならないことを示しています。
Not authorized for ServiceInvoke on GetDaysRemainingInLicense in LicensingSubsystem] は、その非管理者ユーザーにはライセンスサブシステム上の GetDaysRemainingInLicense サービスに対するランタイムサービス呼び出しのアクセス許可がないことを示しています。
既存のバージョンの ThingWorx (8.4.0 より前) からマイグレーションしたユーザーエンティティは、ComposerUsers ユーザーグループに手動で追加する必要があります。インポートされたユーザーエンティティは ComposerUsers ユーザーグループに自動的にマイグレーションされません。
ユーザー拡張機能
ユーザーは、ユーザー拡張機能と呼ばれるいくつかのプロパティを定義できます。ユーザー拡張機能のプロパティは、コンフィギュレーションテーブルに保存されます (これらはすべて厳密に型指定された文字列です)。このため、インフォテーブルプロパティをユーザー拡張機能のデータシェイプに追加してから、そのインフォテーブルでユーザーの値を設定することはできません。コンフィギュレーションテーブルの最も一般的な用途としては、外部リソースの資格証明やホスト情報が保存されます。コンフィギュレーションテーブルを使用して、頻繁に更新される動的データを保存しないでください。
* 
ユーザー拡張機能のコンフィギュレーションテーブルは、単純なデータシェイプ構造を使用しない特別なタイプのコンフィギュレーションテーブルなので、修正に使用できないサービスがあります。このようなサービスには SetConfigurationTableSetConfigurationTableRowsSetMultiRowConfigurationTable があります。
ユーザー情報のコンフィギュレーションを修正するには、「モデリング」 > 「Thing Shape」 > 「ユーザー情報」で Thing Shape を編集します。
ユーザーに対してパスワードのリセットを許可する場合は、次のユーザー機能拡張プロパティが必要です。
firstName
lastName
emailAddress
サービスのユーザーアクセス許可
サービスは、そのサービスの開始者であるユーザーにはアクセス許可を要求しないように、明示的に設計されています。たとえば、ユーザーは自分のパスワードを変更できます。ユーザーが独自のアカウントのサービスを使用できないようにすることはできません。
言語プリファレンス
「言語」フィールドでは、使用可能な言語の名前を知っている管理者が、順序付きのコンマ区切りリスト (たとえば、ca,es,hu,fr-CA) を入力するか、使用可能な言語のリストから選択できます。リストの先頭にある言語は、ユーザーの優先言語です。ユーザーに言語プリファレンスが設定されていない場合は、「デフォルト」および「システム」ローカライズテーブルが使用されます。
ローカライズトークンの表示値 (翻訳) は、ユーザーの言語プリファレンス、システムで設定されているローカライズテーブル、および指定されたローカライズテーブルに存在するトークンの翻訳によって決まります。
ユーザーの言語プリファレンスは、たとえば、fr,pt,ru,hi (フランス語、ポルトガル語、ロシア語、ヒンディー語) です。システムには、es (スペイン語)、fr-CA (カナダフランス語)、it (イタリア語)、pt-BR (ブラジルポルトガル語)、ru (ロシア語)、およびデフォルト (多くの場合、英語) のローカライズテーブルが設定されています。システムは、指定されたトークンの値をサーチします。システムは最初に、fr ローカライズテーブルを探します。このテーブルは存在しますが、トークンが fr ローカライズテーブルに含まれていません。このため、システムは pt ローカライズテーブルに進みます。システムに pt ローカライズテーブルはありません。このため、ru に進みます。システムは ru ローカライズテーブルとトークンを検出します。トークンには値があるので、その値が UI に表示されます。
これは役に立ちましたか?