ビジネス ロジックの一部に CSLA.NET を使用する ASP.NET MVC 4 アプリケーションがあります。読み取り/書き込みのアクセス許可は、アプリケーション プール ID および .NET 偽装ユーザーと同じアカウントであるドメイン アカウントによって AD を介して処理されます。ローカル マシンでテストすると、検証は完全に実行されます。アプリケーションがテスト環境 (dev または qa) の 1 つにデプロイされると、パーミッションを指しているように見える例外を受け取ります。アセンブリで使用されているユーザー名が実際に正しいユーザーであることを確認しましたが、適切な権限がないため、どのフィールドの値も設定できませんでした。
誰もが前にこのようなことを経験しましたか?
編集：
Web サーバーはステートレスであるため、通常、ページ間またはサービス要求間で何も覚えていません。これには、ユーザーの ID とロールが含まれます。
ASP.NET フォーム セキュリティ (または同様のもの) を使用している場合、ユーザー名は .NET 認証 Cookie トークンを使用してサーバー上で自動的に再作成されますが、それはユーザー名だけです。
ポストバック/リクエストごとに、サーバー上に完全なプリンシパル/ID オブジェクトを再作成する必要があります。
これを行う最も簡単な方法は、global.asax ファイル (多くの場合、認証要求イベント内) を使用することです。これを行う方法を示すサンプルが CSLA のダウンロードにあり、「CSLA 4 の使用」電子ブック シリーズで説明しています。
また、優れた ASP.NET の書籍では、プリンシパルの復元について説明しています。これは、Web 開発の問題ほど CSLA の問題ではないためです。