「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
ASP.NET †
ASP.NETのweb.config、app.configへの変更の反映タイミングが解らない。 †
反映には、IISの再起動が必要です。
- web.configが変更されると、自動的にIISの再起動がかかり、直ちに変更が反映されます。
- しかし、app.configの変更ではIISが再起動しないので、iisresetコマンドを使用して手動で変更を反映する必要があります。
- ※ ASP.NET開発用Webサーバを使用している場合は、上記IISをASP.NET開発用Webサーバに読み換える。
Forms認証ログイン前にJSファイルなどを参照できない。 †
- Forms認証で、左記現象が発生することを確認しました。
- これを回避するには、web.configのセクションに、以下の定義を追加する必要があります。
<!--
JavaScript ファイルを認証対象外にする
-->
<location path="Framework/Js">
<system.web>
<authorization>
<allow users="*"/>
</authorization>
</system.web>
</location>
予期せぬSessionタイムアウトが発生する。 †
- IIS では、特定のワーカープロセスのアイドル状態が続くと自動的にそのワーカープロセスがシャットダウンされるようです。このワーカープロセスのアイドルタイムアウトの既定値は 20 分です。
- 従って、ASP.NET の画面操作後、20 分以上、誰からもその Web アプリケーションにアクセスがなかった場合、上ワーカープロセスが強制的にシャットダウンされ、セッションの状態が破棄されてしまう可能性があります。
- アイドルタイムアウトの設定は、IIS 管理ツールで行います。
- また、セッションの状態が失われる条件が、以下サイトにまとまっていますので、合わせてご紹介いたします。
ASP.NETから共有フォルダにアクセスできない。 †
共有フォルダへのアクセス権付与が必要です。
- ADを導入してる場合、マシンアカウントにアクセス権を付与できます。
- また、IISのワーカープロセスのアカウントを変更することで対応可能です。
上記を実施できない場合は、ASP.NETの偽装か区間偽装を推奨します。
余談：
- ネットワークドライブは、偽装アカウントで認識されていないことがある。
- サービスアカウントはログインしないこともあるので。
ASP.NETからEXE起動したプロセスにアクセス権が無い。 †
- 偽装アカウントからEXEを起動した場合、EXEの実行アカウントは偽装アカウントになりません。
- EXEの実行アカウントは偽装アカウントにする場合、以下のように処理を実装する必要があります。
bool ret;
string cmdNotepad = Environment.GetEnvironmentVariable(
"SystemRoot", EnvironmentVariableTarget.Process) + @"\system32\notepad.exe";
// 通常起動
Process.Start(cmdNotepad);
// 偽装起動
// ・ASP.NET偽装や、ImpersonateValidUserの偽装レベルはSecurityImpersonationなので、これに合わせる必要がある。
// ・独自偽装の、偽装レベルは、SecurityImpersonation、SecurityDelegationどちらでも良いが、双方を合わせる必要がある。
// ・実行アカウントには、「プロセス レベル トークンの置き換え」セキュリティ・ポリシー設定が必要になる。
ret = IdentityImpersonation.CreateProcessAsImpersonationUser(cmdNotepad, "");
偽装方式 †
ASP.NETの偽装 †
- ベース クライアント セキュリティ モデルでの偽装
- <identity impersonate="true" />
- 特定のユーザ アカウントを偽装
- <identity impersonate="true" userName="accountname" password="password" />
区間偽装のサンプル †
try
{
// コードの特定部分を実行するときのみ、任意のユーザを偽装する。
// 偽装して
ii = new IdentityImpersonation();
ret = ii.ImpersonateValidUser("x", "", "x");
// 偽装アカウントでの処理
// 存在チェック
this.lblElse.Text
+= string.Format("、偽装後（任意のユーザ「{0}」を偽装）：", WindowsIdentity.GetCurrent().Name)
+ ResourceLoader.LoadAsString(@"c:\test.txt", Encoding.GetEncoding(CustomEncode.UTF_8));
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
}
finally
{
// 偽装解除
ret = ii.UndoImpersonation();
}
ログ出力機能 †
ログ出力フォーマットをカスタマイズ可能か？ †
可能です。
ログ出力フォーマットはカスタマイズ可能レイヤであるベースクラス２で定義されています。
以下のケースで、上記処理を案件ごとにカスタマイズして下さい。
- 例外固有のプロパティをログ出力する場合
- 例外のダンプをする場合（Exception.ToString?(), Objectダンプ部品）
ログ出力機能に於いて、１系 ⇔ ２系と言ったローリングを実現可能か？ †
ログ出力機能は、log4netの機能を使用しておりますので、
log4netの類似機能（MaxSizeRollBackups?、CountDirection?）で代替下さい。
ログ出力機能に於いて、ユーザ毎に異なるファイル出力が可能か？ †
- リッチクライアント（特にターミナルサービス）の場合、log4netの機能を使用し、ログイン ユーザ毎にログ出力先を変更できます。
- 具体的には、ファイル出力のアペンダ設定に<param name="File" value="${USERPROFILE}?Log?ACCESS" />と記述すればOKです（USERPROFILEはログイン ユーザ毎に異なる環境変数値）。
ログ出力のコントロールが可能か？ †
フィルタでコントロール †
log4netの仕様を確認すると、以下のようになっているようなので、
Loggerのlevelにフィルタ設定すれば、一番性能的に良いと思います。
- Loggers ---> Logger ---> (level) ---> Appenders ---> Appender ---> (level) -> Output
└-> RootLogger ---> Appender ---> (level) ---> Output
プログラムからコントロール †
プログラムからコントロールする場合は、
LogIFの「ログ レベル情報取得インターフェイス」を使用してください。
https://github.com/OpenTouryoProject/OpenTouryo/blob/develop/root/programs/C%23/Frameworks/Infrastructure/Public/Log/LogIF.cs#L116
リッチ クライアント †
リッチ クライアントの定義ファイルの保存先に、ユーザ毎に異なるディレクトリを指定可能か？ †
- リッチクライアント（WindowsForms?、WPF、ClickOnce?、XBAP、ターミナルサービス）の場合、環境変数を使用してデータ保存先を選択できます。
- 具体的には、リソースローダ部品のパスに"%USERPROFILE%?AppData?"と指定すればOKです（USERPROFILEはログイン ユーザ毎に異なる環境変数値）。
プロキシ経由やプロキシ認証をサポートしているか？ †
- サポートしています。
- プロキシへのURLやCredentialsをXML定義ファイルに指定可能です。
- また、これらをAPIから直接指定することも可能です。
Windows認証を使用したSSOをサポートしているか？ †
- サポートしています。
- ケルベロス認証をサポートしていますので、ベース クライアント セキュリティ モデルに於ける ダブル～トリプル ホップも可能です（ただし、ベース クライアント セキュリティ モデルは通常推奨しない方式です）。
TCP/IPなどの通信プロトコルはサポートしているか？ †
- サポートしています。
- サービス インターフェイス、サービス プロキシを追加開発することで対応可能です。
- 同様に、他の未サポートのプロトコルも追加開発により対応可能です。
テスト †
（Open棟梁の）
その他 †
.Net Framework ClientProfile? で動作＆コンパイルできない。 †
Client Profileはサポートしていません。
- 理由
- Client Profileは4.5でドロップされるようなので。
- Client Profileでは存在しないサーバサイドAPIを多数使用しているため。
.NET Framework Client Profile
http://msdn.microsoft.com/ja-jp/library/vstudio/cc656912.aspx
.NET Framework 4.5 以降では、Client Profile が中止され、
完全な再頒布可能パッケージのみが使用できます。
今まではdefect（欠陥）か？とも考えていましたが、
上記理由で、今後のClient Profileへの対応予定はありません。
（また、Client Profile前提の開発も、あまりお勧めしません）
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
