8

RunWithElevatedPrivileges私は、SharePointの使用は疫病のように避けるべきだと強く感じていますが、正確な理由について他の人を説得する必要があります。これが私が持っているものです。

  • 昇格された特権を持つ新しいスレッドを生成します
  • 渡されたデリゲートが戻るまで、他の操作をブロックします
  • セキュリティの問題（おそらくエンドユーザーによる高レベルの特権で実行されます）
  • その他？
4

4 に答える 4

15

昇格する理由は2つのカテゴリに分類されます。

  1. コードは、現在のユーザーが権限を持っていないSharePointで操作を実行する必要があります。これは、セキュリティの状況をよりよく理解する必要があることを示す「万が一の場合」の手段としてではなく、SharePointセキュリティを使用しているときに常に実行する必要があります。
  2. コードは、アプリケーションプールIDがアクセスできるが、現在のユーザーはアクセスできない外部リソース（サーバーファイルシステム、データベース、ファイル共有など）にアクセスする必要があります。

前者の場合、 SPSiteの偽装を使用する方がはるかに優れています。後者は私が今までRWEPを使用した唯一の理由です。

明確にするために、RWEPは新しいスレッドを生成しません。代わりに、Win32 APIを使用して現在のスレッドのIDをプロセスIDに戻し（偽装をオフにして）、昇格されたコードを実行し、偽装をオンに戻して現在のユーザーに代わって作業を再開します。これにはいくつかの意味があります。

  1. スレッドが偽装されていない場合、RWEPは何も実行しないため、タイマージョブ、Visual Studioワークフロー、コンソールアプリケーション、およびstsadm（機能レシーバー）を介して実行されるコードでは役に立ちません。
  2. CodeToRunElevatedに新しいSPSiteを作成すると仮定すると、SharePointへのアクセスは、アプリケーションプール（SHAREPOINT \ system）の権限で実行されます。このアカウントには、現在のWebアプリケーションへのフルアクセス権がありますが、SPFarmプロパティの変更やSSPへの変更などを行うためのファームレベルのアクセス許可は必要ありません。
  3. CodeToRunElevatedの実行境界を越えてID対応オブジェクト（SPSiteやその子など）を使用すると、非常にファンキーな動作や競合状態が発生する可能性があります。すべての意図と目的のために、これはサポートされていないと考えてください。

また、Alexが述べたように、SPSiteの子は、SPSiteから権限を継承します。SPSiteは、作成時に権限が設定されます。したがって、SPContext.Current.Siteは、CodeToRunElevated内で参照している場合でも、現在のユーザーのアクセス許可で動作します。代わりに、昇格されたブロック内に新しいSPSiteを作成して使用する必要があります。

要約すると、SharePointの外部でアプリプールを偽装するためのRWEP、SharePointの内部でアプリプールを偽装するためのSPSiteの偽装。

于 2009-10-06T19:01:31.227 に答える
4

1）RWEPの実質的な使用は、コードの臭いの良い兆候です。考えずに簡単に悪用される可能性があり、深刻なセキュリティ問題につながります。多くの開発者は、ユーザーが「内部」で間接的に与えられている力で何ができるかについて考えていません。

ほんの一例です。アプリケーションページでの悪意のあるリクエストを防ぐために、RWEPを使用する前にValidateFormDigestを呼び出すことが重要です。

2）SPWebおよびSPSiteオブジェクトは、RWEPのコンテキストで作成する必要があります。これは初心者の開発者にとって忘れがちであり、多くのフラストレーションにつながります。

この制限は、RWEPデリゲートが終了する前に、すべての作業とこれらのオブジェクトによって作成されたオブジェクトを使用して終了する必要があることも意味します。これはもう1つのよくある間違いです。

Keith Dahlbyは、これらの問題を回避するための拡張メソッドを作成し、より堅牢で読みやすいコードを提供しています。

于 2009-10-06T14:49:56.287 に答える
2

RWEPには、他のすべてと同様に、長所と短所があります。

エンドユーザーがRWEPを実行していることを懸念している場合は、そのコードがすでにGACにインストールされているため、おそらくすでに大きな問題が発生しています。

場合によっては、それに固執する必要があります。管理者権限を持たないユーザーがドキュメントワークフローを実行していると考えてください。このユーザーが承認（または拒否、関係ありません）した後、ワークフローエンジンはそのSPListItem特権を再定義できるはずです。

于 2009-10-06T14:37:17.640 に答える
0

私はそれを使用し、それが非常に便利な機能であることがわかりました。私の見解では、ユーザーに自分のコードを実行させ、そのコードにユーザーが通常は実行できないことを実行させることを選択しています。何かをロックダウンしても、ユーザーが非常に制御された方法でアクセスできるようにすることができます。

于 2009-10-06T14:47:07.707 に答える