6

プラグイン コンテキスト内には、2 つのユーザー ID があります。

  1. InitiatingUserId実際にプラグインを起動したユーザーの ID を返します。
  2. UserIdこれは、プラグインが実際に実行されているユーザーのユーザー ID を返します。(これは、プラグインの登録時に指定されたユーザー、または呼び出しユーザーとして実行するように登録されている場合は呼び出しユーザーです)

しかし、私は 3 番目のユーザー ID に関心があります。これは、呼び出しを実行した OrganizationServiceProxy の偽装されたユーザー ID です。

CRM システム管理者 AD アカウントで実行されている ASP.Net Web サイトがあり、CRM に対して行われるすべての呼び出しは、偽装を使用して、現在サイトにログインしているユーザーの CRM ユーザー ID を検索するとします。

これは、選択と更新に最適です。ユーザーは、自分が権利を持っているものを表示/更新することしかできません。しかし...特定のエンティティの更新時にトリガーされるプラグインを作成する場合、プラグイン内からAsp Webサイトで偽装されたユーザーのユーザーIDを検索するにはどうすればよいですか?

4

3 に答える 3

3

状況に関する私の理解では、偽装されたユーザーのユーザー ID を取得できますが、認証されたユーザーは取得できません。以下にいくつかのシナリオを示します (UR11 および UR12 でテスト済み)。

  1. ユーザー Aとして CRM に認証され、ユーザー Bになりすます。プラグインは、特定のユーザーを偽装するために登録されていません (つまりImpersonatingUserId、プラグインのステップがnull(プラグイン登録ツールから、「ユーザーのコンテキストで実行」が「呼び出し元のユーザー」に設定されます) に設定されます)。例は、 User AOrganizationServiceProxyとして認証された場合です。ユーザー Bです。 proxyService.CallerId
    • PluginContext.UserId=ユーザー B
    • PluginContext.InitiatingUserId=ユーザー B
    • createdonbehalfby(またはmodifiedonbehalfby) =ユーザー A
  2. ユーザー Aとして CRM に認証され、ユーザー Bになりすます。プラグインはUser Cになりすますために登録されています。(つまり、プラグイン ステップの ImpersonatingUserId がユーザー C に設定されます (プラグイン登録ツールから、「ユーザーのコンテキストで実行」がユーザー C に設定されます))。例はUser AOrganizationServiceProxyとして認証され、はUser Bです。 proxyService.CallerId
    • PluginContext.UserId=ユーザー C
    • PluginContext.InitiatingUserId=ユーザー B
    • createdonbehalfby(またはmodifiedonbehalfby) =ユーザー A

シナリオ＃1は、動作が異なることをぼんやりと覚えているので、少し混乱します。これは、CallerIdプロパティが設定されると、シナリオ 2 とは異なる場所で偽装が発生することを意味する必要があります。ただし、シナリオ 2 では、期待どおりの結果が得られていることがわかります。

この結果を生成するために使用した手順は次のとおりです。

  1. コンソール アプリケーションと参照Microsoft.Xrm.Sdkを作成し、Microsoft.Crm.Sdk.Proxy. OrganizationServiceProxy認証されたユーザーがUser Aである新しいオブジェクトをインスタンス化します。をUser BCallerIdを表す Guid に設定します。

  2. 次のように、最初の機会に例外をスローするだけの非常に単純なプラグインを作成します。

    throw new Exception(string.Format("Initiating Id: {0}, User Id: {1}", 
    context.InitiatingUserId, 
    context.UserId));
于 2013-05-27T17:07:27.043 に答える
-1

この同じ問題は CRM 2013 にも関連しており、おそらく同じ解決策があります。

プラグインが呼び出し元ユーザーのコンテキストで実行するように登録されているシナリオを考えると、プラグイン実行コンテキストの InitiatingUserId と UserId の値はどちらも同じになります。

これは、クライアントが CallerId をオーバーライドして接続を確立した場合でも当てはまります。この場合、両方の値は、認証されたユーザーの ID ではなく、指定された CallerId 値を表します。

では、プラグイン内で実際の呼び出し元の ID を取得するにはどうすればよいでしょうか? ポスト フェーズは簡単です。実行後のイメージで createdonbehalfby または modifiedonbehalfby をチェックするだけです。これらの値はどこにも存在しないため、操作前はそれほど明白ではありませんが、トリックは単純です。

プラグイン内で、UserId が NULL である新しい IOrganizationService を確立します。context.UserId または context.InitiatingUserId ではなく、null だけです。次に、そのサービスを使用して WhoAmI 要求を実行すると、応答には、指定された CallerId の ID ではなく、サービス呼び出しを実行した認証済みユーザーの GUID が含まれます。

IOrganizationServiceFactory には、実際にはこの値 (AdministratorId) を含むプライベート フィールドがありますが、プライベートであるため読み取ることができないため、代わりにこの回避策は追加のオーバーヘッドを犠牲にして機能します。

于 2015-01-20T00:15:40.020 に答える