私は、他のデータベースのデータに基づいていくつかのアナウンスを作成するというお客様のリクエストを受けています。ほとんどの場合は簡単ですが、新しい要素は入力データで指定されたユーザー（ログイン）によって作成される必要があります。 私はリストのWebサービスを使ってアナウンスを追加するつもりでしたが、作成権限を得るためにはなりすましを使わないでください。偽装を使用せずにクリエイターとして正しいユーザーを割り当てる方法はありますか？特定のユーザーのアナウンスリストに要素を追加します
これはあなたが探している答えではないかもしれませんが、SharePointサーバー上のGACでコードを実行していると、偽装は非常に簡単です。多くの人が気づいていないパスワードを知る必要はないので、これがあなたが偽装をしたくない理由だったと仮定して引き続き説明します。それを行う方法は次のとおりです。
SPSiteで使用する一般的なコンストラクタを使用してSharePointに接続し、適切なSPUserオブジェクトを見つけることができます。これを実行すると、そのSPUserのUserTokenプロパティを取得できます。その後、SPSiteコンストラクタを再度使用する必要がありますが、SPUserTokenを提供するオーバーロードを使用してください。 SharePointで行うことは、偽装を介して行われます。高い特権で実行する必要はありません。
これで言いましたように、私はコードを推測しようとします。ユーザーがサイトに少なくとも1回訪問していない場合、適切なはUserTokenを導出することから、利用可能なユーザメタデータが存在しない、答えのコードのコメントで示唆したように
// Just determine the user token for a particular user
SPUserToken userToken = null;
using (SPSite tempSite = new SPSite("http://sharepointurl"))
{
using (SPWeb tempWeb = tempSite.OpenWeb())
{
// I think this next line works, but I'm going from memory
// I believe the user needs to have already logged into the site at least once
SPUser user = tempWeb.AllUsers["username"];
userToken = user.UserToken;
}
}
// Now do whatever we want impersonating that user
using (SPSite site = new SPSite("http://sharepointurl", userToken))
{
using (SPWeb web = site.OpenWeb())
{
// Do whatever you want here
}
}
これをアーカイブする方法はありません。
ただし、この回避策が役立つ可能性があります。私はこれを決してテストしなかったことを認めなければなりません。あなたの問題をどのように解決するかということだけです。
これを試すことができます。管理者ユーザーまたはRunWithElevatedPrivileges（）を使用して新しいアナウンスを作成します。その後、RunWithElevatedPrivileges（）メソッドを再度使用して、発表者の実際の作成者であるべきユーザーに「作成者」フィールドを設定します。このようにして、「編集者」フィールドにのみ「間違った」ユーザーが表示されます。
これは非常に洗練された解決策ではありませんが、うまくいく可能性があります。 ;私はちょうど私の要件は、SharePointに監査証跡を回避するために、実際にあったことを私は確信して、私は別の解決策を考え出したことが
:-)行うことができないことを願っていることを実現）
：私は追加新規ユーザまたはグループフィールドをアナウンスメントリストに追加し、ADユーザログオンをこのフィールドにコピーします。以前に「作成者」フィールドを使用したレポートまたはビューでは、新しいフィールドが使用されるようになりました。
実際のユーザーがアナウンスメントリストに新しい要素を入力する状況はどうですか？それはログインしたユーザーで新しいフィールドを更新しません！
私が考えることができる唯一の解決策は、リストにListItem Addトリガを追加することです。新しい要素が追加されると、新しいフィールドに値が含まれているかどうかを確認します。そうでない場合は、ログインしたユーザーのIDで新しいフィールドを更新します。そうすれば、新しいフィールドには常に有効なユーザーIDが含まれているはずです。
私はこれがエレガントな解決策ではないことを知っていますが、当面は私が考えることができる最高のものです。
：それはのようなものでなければなりません。それは面白そう今
SPUser alice = web.EnsureUser(@"MYDOMAIN\alice");
SPList userInfo = web.SiteUserInfoList; //metadata storage of user info
SPListItem item = userInfo.GetItemById(alice.ID);
item["About Me"] = "I am Alice from Mel's Diner";
item.Update();
：
は、SharePoint 2010を使用すると、SPWebクラスから利用できるEnsureUser方法でユーザーの訪問を、（このスニペットは、ユーザーが作成され、また自分のプロフィールビットを微調整）をシミュレートすることができます。私はそれを試して元に戻す – Kasper
カーク、私は唖然としています。あなたが提案したアイデアは素晴らしいですが、最初は監査証跡の有効性が無効になっているため、これを大きな脆弱性と見なしました。 2番目の考えで私は、この「悪用」を使うためには、敵対的なコードがシステムの中核にアクセスしなければならないことに気付きました。 – Kasper
はい、私もこの抜け穴があったことを知ったときに驚いていました。あなたが言うように、あなたのコードは特定のコードアクセスセキュリティレベルを持っていなければなりません（もちろん、GACは仕事をしています）。もう一つ興味深いのはSPListItem.SystemUpdate（）です。 –