16

イベント ハンドラーの一部として実行されるコードがあり、新しい TOM.NET セッションを作成する必要があります (再利用できませんsubject.Session)。このイベント ハンドラーは、多くの Tridion プロセス (TcmServiceHost、COM+、Publisher、TcmTemplateDebugHost、IIS アプリケーション プール) に読み込まれ、これらのプロセスは次の可能性があります。

  • Tridion にアクセスできる ID の下で実行されます (たとえば、COM+ アプリケーションは、Tridion 管理者である MTSUser の下で実行されます)。
  • Tridion へのアクセス権はないが、Tridion ユーザーの偽装が許可されている ID で実行されます (たとえば、TcmServiceHost は、Tridion 偽装ユーザーとして構成された NetworkService として実行されます)。

この TOM.NET コードを使用して、両方のケースに対応しようとしています。

Session session = null;
try
{
    session = new Session();
}
catch (AccessDeniedException ex)
{
    // this process doesn't have TCM access, so impersonate a user that does
    session = new Session("Administator");
}
if (session != null)
{
    var item = session.GetObject(id);
    ...

これは、コードが Tridion にアクセスできるプロセスで実行されているかどうかを確認する正しい方法ですか (「管理者」をハードコーディングしたという事実を無視して)? コードは機能しますが、「Tridion へのアクセス権がある」チェックを実行するためのより効率的な方法があるのだろうか?

注: コア サービスを使用して Tridion にアクセスするときに同じ疑問が生じるため、ここで使用するのに TOM.NET が適切な API であるかどうかという問題ではありません。

4

4 に答える 4

6

私はこのコードを使用しません。例外のキャッチは遅く、現在、システムにアクセスできない人に（管理者）アクセスを許可しています。これは大きなセキュリティホールです。

代わりに、現在のユーザーが誰であるかを調べて、彼がなりすましユーザーであるかどうかを判断します。APIがない場合は、Tridion.ContentManager.configファイルから偽装ユーザーを直接読み取ることができます（私はチェックしていません）。

var isImpersonationUser = IsImpersonationUser(WindowsIdentity.GetCurrent());
var session = isImpersonationUser ? new Session("Administrator") : new Session();
var item = session.GetObject(id);

または、イベントコード用に個別に構成することもできます。または、コードが一般的であることを気にしない場合は、ハードコーディングすることもできます。

于 2012-05-02T12:35:34.683 に答える
2

まず第一に、これは素晴らしい質問/トピックです。

あなたはすべてのTridionプロセスで機能する一般的なものを「構築」しようとしていると思います。私の意見では、ベストプラクティス（R＆D /あなた）に基づいてセッションオブジェクトを作成するべきではなく、 Sessionオブジェクトにアクセスし、可能な場合は使用可能なセッションを再利用します。

たとえば、テンプレートとイベントシステムでご存知のように、セッションにアクセスできるので、セッションを再利用する必要があります（ユーザーが許可されていないことを実行したい場合を除き、その場合は偽装する必要があります）。

別のプロセスでセッションを利用できない場合は、コアサービスを使用する必要があります。

ですから、あなたの質問に対する私の答えは、TOM.NETを使用しないことです。アプローチを変更し、コアサービスを使用して構築します。コアサービスでは、以前に構成した特定のユーザーになりすますことができます。そして、あなたのコードはより一般的で、「どこでも」実行されます（ただし、トースターでは実行されません）。

ここであなたが特定しようとしていること、「一体誰が私の現在のプロセスを実行しているのか」を理解していますか？それに応じて偽装することができます、

残念ながら（AFAIK）、プロセスを実行しているIDが誰であるかを確認し、それに応じて偽装するためのコードを作成する必要があります。これには注意が必要です。そのため、TOM.NETAPIの代わりにコアサービスを使用することをお勧めします。

これが理にかなっていることを願っています。

于 2012-05-02T13:59:30.073 に答える
2

このコードは非常に効率的であるように思えますが、セッション オブジェクトを作成できるかどうかを確認しても、CMS で実際に実行したいアクションをコードが実行できるとは限りません。

また、そのようなコードは大きなセキュリティの脆弱性を生み出し、プロセスがアクセス許可を持っていない場合に、より高いレベルのセキュリティにフォールバックできるようにしているようです。また、CMS 内のアイテムを変更している場合、そのなりすましにより、変更を引き起こした可能性のある個人の実名が表示されないことにも注意してください。偽装しているユーザーとして保存されます。

于 2012-05-01T17:29:04.073 に答える
1

TDSE.Impersonate() メソッドが最初に実装されたときは、呼び出し元のスレッド ID が偽装ユーザーではない場合、意図的にサイレントに失敗するように設計されていました。これにより、たとえば、今日の GUI の ASP コードが盲目的になりすましを試みることができました (REMOTE_USER ヘッダー IIRC に基づく)。要点は、あなたがなりすましユーザーでなければ、わかりました。

これを COM API でテストしたところです (.NET API が一貫していることを確認するのはあなたに任せます)。私の結果 (Tridion 2011 SP1) は次のとおりです。

1)。受託者であり、なりすましを行わないなりすましユーザーは、自分自身になります。2)。トラスティで偽装する偽装ユーザーは、偽装した人になります (通常、そのようなユーザーを作成しないことをお勧めします)。3)。偽装を呼び出した非偽装ユーザーは、自分自身のままです。

明らかに、プロセス ID が偽装ユーザーであるかどうかに大きく左右されます。おそらく、NETWORK SERVICE の使用を避け、TcmServiceHost の ID を明示的に作成して、そのようなユーザーが偽装するかどうかをきめ細かく制御できるようにすることを好むシナリオがあるかもしれません。

それで...プロセスが偽装者として実行されているかどうかを明示的にテストする必要がありますか? 単純になりすましを試みて、結果を受け入れるほうがよい場合があります。当初の考え方には確かにこの意図が含まれていましたが、その後、事態はより複雑になったと思います。

この分野で予想される動作について疑いの余地がないことが非常に重要であるため、質問に対して+1。

于 2012-05-02T22:58:33.083 に答える