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サーバに読み換える。

sessionStateのmodeの初期値をStateServer?にしている理由

  • StateServer?、SQLServerなどのモードを使用するには、
    Sessionに格納するオブジェクトが、[Serializable]にマークされている必要がある。
  • InProc?で開発を進めてしまうと、[Serializable]でない、オブジェクトをSessionに格納し、
    運用中の切替ができなくなることを想定し、Open棟梁のテンプレートでは、StateServer?を既定値にしている。
  • 選択
    • 本番運用環境で、クラスタリングなどが必要になり得るようなら、開発時は、mode="StateServer?"の設定がオススメ。
    • そのようなことが無いと言い切れる場合は、mode="InProc?"に変更してもトラブらない。

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 アプリケーションにアクセスがなかった場合、
    上ワーカープロセスが強制的にシャットダウンされ、セッションの状態が破棄されてしまう可能性があります。
  • また、セッションの状態が失われる条件が、以下サイトにまとまっていますので、合わせてご紹介いたします。

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();
 }

ログ出力機能

ログ出力フォーマットをカスタマイズ可能か?

可能です。

  • ログ出力フォーマットはカスタマイズ可能レイヤであるベースクラス2で定義されています。
  • 以下のケースで、上記処理を案件ごとにカスタマイズして下さい。
  • 例外固有のプロパティをログ出力する場合
  • 例外のダンプをする場合(Exception.ToString?(), Objectダンプ部品

ログ出力機能に於いて、1系 ⇔ 2系と言ったローリングを実現可能か?

ログ出力機能は、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/CS/Frameworks/Infrastructure/Public/Log/LogIF.cs#L116

リッチ クライアント

リッチ クライアントの定義ファイルの保存先に、ユーザ毎に異なるディレクトリを指定可能か?

  • リッチクライアント(WindowsForms?、WPF、ClickOnce?、XBAP、ターミナルサービス)の場合、環境変数を使用してデータ保存先を選択できます。
  • 具体的には、リソースローダ部品のパスに"%USERPROFILE%?AppData?"と指定すればOKです(USERPROFILEはログイン ユーザ毎に異なる環境変数値)。

通信制御機能

プロキシ経由やプロキシ認証をサポートしているか?

  • サポートしています。
  • プロキシへのURLやCredentialsをXML定義ファイルに指定可能です。
  • また、これらをAPIから直接指定することも可能です。

Windows認証を使用したSSOをサポートしているか?

  • サポートしています。
  • ケルベロス認証をサポートしていますので、ベース クライアント セキュリティ モデルに於ける
    ダブル~トリプル ホップも可能です(ただし、ベース クライアント セキュリティ モデルは通常推奨しない方式です)。

TCP/IPなどの通信プロトコルはサポートしているか?

  • サポートしています。
  • サービス インターフェイス、サービス プロキシを追加開発することで対応可能です。
  • 同様に、他の未サポートのプロトコルも追加開発により対応可能です。

テスト

(Open棟梁の)テストに関するいろいろ。

負荷テストのポイント

脆弱性対策のポイント

テスト自動化について

NuGet導入、NuGet登録

NuGet導入後のデバッグ方法

NuGetからローカルに切り替える。

その他

.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前提の開発も、あまりお勧めしません)


トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2018-07-30 (月) 16:33:20 (20d)