none
VisualStudio2012で開発中のWebサイトが、ページ遷移でセッション変数を維持できない RRS feed

  • 質問

  • ASP.NET4.0で開発中のあるWebサイトの話です。

    同じ開発端末上のVisualStudio2012で、幾つかのWebサイトを構築しましたが、今回だけページ遷移前に格納したセッション変数を得られない状況に陥っています。

    まだサーバにディプロイしていない状態、すなわち開発端末上のデバッグモードで動作させての話です。

    具体的にいうと、ログオンする初期画面で格納したSession("StaffID")が、Response.Redirectで遷移したページ側で拾えない=Nothingとなっています。遷移方法はResponse.Redirect("menu.aspx", False)としています。

    他の構築サイトと異なる点は、データセットをApp_Code中に定義した点でしょうか...。(ODP.NETプロバイダの接続文字列から作成したクエリ結果)

     

    他の構築サイトのWeb.configと比較し、そう違いがないように思いますが、何が原因と考えられるでしょうか?ヒントを頂けたら幸いです。

    2015年4月13日 12:14

回答

  • レスが遅くなりました。

    セッション ID の授受はクッキーを使って行われているようで、どうにも原因がつかめませんが、マイクロソフト公式解説書「プログラミング ASP.NET 4」の 17.3.2 章の「セッション状態が失われる理由」に書いてあったことを紹介しておきます。

    まず、sessionState 要素の mode 属性が InProc の場合(デフォルト・・・質問者さんのケースではこれですよね?)、ワーカープロセスのリサイクルやアプリケーションの再起動で失われます。(これは今回のケースでの原因としては考えにくいですが)

    次はアンチウィルスソフトの影響です。一部のアンチウィルスソフトは、web.config ファイルや Global.asax ファイルに変更されたという印をつけることがあるそうです。「元ページ」から「遷移先ページ」に遷移する際にそのようなことが起こるかどうかはわかりませんが、起こるとするとセッション状態が失われることはあり得ますね。

    その他、Bin や App_Code フォルダといった特別なフォルダの内容が更新されたりした場合も同様にセッション状態が失われることになるそうです。

    他の回答者の方がレスされていますが、Application.Start イベントが発生しているかどうかでそれが分かるかもしれません。

    また、開発マシンを変えるとか、サーバーで試してみるとかでも確認できるかもしれません。

    【追伸】

    Gloabl.asax の Application_Start メソッド内にブレークポイントを設定してもそこで止まらないことがありますので注意してください。詳しくは以下の記事を見てください。

    Application_Start のデバッグ
    http://surferonwww.info/BlogEngine/post/2011/08/26/How-to-stop-at-breakpoint-set-in-the-Application_Start-method.aspx

    • 編集済み SurferOnWww 2015年4月15日 13:24 追伸追加
    • 回答としてマーク saya24 2015年4月16日 1:22
    2015年4月15日 13:17
  • 原因がわかって良かったです。

    自分もマ○フィーがそういうことをするという情報を得られたことは収穫でした。

    > それにしても、この事象は非常にまずく、方針を変えざるを得ない状況でしょうか。

    取りあえずは、運用環境の Web サーバーに問題のアンチウィルスソフトが入っていなければ(多分入ってないと思いますが)、方針を変えるまでの必要はなさそうに思います。

    開発マシンでは、Web アプリの開発する際にアンチウィルスソフトを無効にするというのが面倒かもしれませんが。

    一般ユーザーの PC のアンチウィルスソフトは今回の問題とは関係ないので、今のままで良いのではと思います。


    もし、方針を変えるところまで考えるのであれば、ASP.NET 標準のフォーム認証に切り替える方向で検討されてはいかがですか?(何らかの理由で、ASP.NET 標準のフォーム認証という選択肢を捨てて独自認証にしたのでなければ)

    ASP.NET 標準のフォーム認証はセッション状態を使いませんし(暗号化された認証チケットをクッキーでやり取りします)、実装するのに自分では一行もコードを書かずに済みますし、それより何より、当たり前ですが ASP.NET との親和性が抜群です。


    【追伸】

    対症療法的かもしれませんが、セッション情報がシリアル化できるものであれば、その格納場所を現在の InProc(ワーカープロセスのメモリに保持)ではなく、StateServer または SQLServer(ワーカープロセスの外に保持)という手段もあります。

    詳しくは以下のページを見てください。

    セッション状態モード
    https://msdn.microsoft.com/ja-jp/library/ms178586(v=vs.100).aspx

    #商用に使うのであれば、InProc モードは論外という意見もあるようです。

    • 編集済み SurferOnWww 2015年4月16日 3:52 追伸追加
    • 回答としてマーク saya24 2015年4月16日 4:08
    2015年4月16日 3:28

すべての返信

  • 質問に書いてあることを読む限り、そういうことはあり得ないので、たぶん質問に書いてないどこかに問題があるのだと思います。

    前にもお願いしたと思いますが、掲示板に書いてあること以外に何も知りえない回答者に、どういう情報を提供すれば回答者が質問者さんの状況を的確に理解でき、タイムリーに的を得た回答ができるかよく考えて質問を書いていただければと思います。

    問題を再現できる必要最小限のコードをアップするなど、回答者の方でも問題を再現するとか推定できるような情報を提供できませんか。

    #以前のように、レスが付いているのに何ヶ月も放置しておくことがないようお願いします。

    2015年4月13日 14:07
  • いつもお世話になっております。

    セッション変数を次ページで得られない状況と関係があるのかわかりませんが、怪しげな部分を全て記載させて頂きます。掲載すべき点の的を絞れず少々広範囲になってしまったこと、ご容赦ください。

    -当該開発端末のGACに2つのOracleCleintが存在する-

    当該開発端末に従来から10gのOracleCleientがインストールされていましたが、昨今11gのOracleClientを追加でインストールしました。11gのOracleCleintをインストールする際、優先的に利用するOracleCleintは従来からの10gと宣言しています。(この操作は11gのOUIで対応した。)

    この11gのOracleClientは.NETの開発パッケージを含むODTwithODAC1120320_32bitでした。このインストールを行ったことで、あるOracleDBServerとの接続文字列をプロジェクトへ新設し、この接続を活かし、サイト内のAPP_Codeに一つのデータセットを作りました。事前に、Binフォルダへ11gのOracleClientからのOracleDataAccess.dllをコピペ配置した上です。

    -このプロジェクトに限りVS2012のデバッグ実行がビルド時に失敗することがある、ソリューションのビルド時も同様。-

    決まって失敗するわけはなく、4回に1回ぐらいの割合??でしょうか。出るエラーの内容はいつも同じです。ReportViewerを貼り付けたページから発せられているよう、こちらで使用のrdlcに上記データセットを利用しています。ReportViewerの使用にあたっては11.0のWebFormsと10.0のcommonを事前に参照設定しています。

    エラー 1 'ReportDataSource' は、名前空間 'Microsoft.Reporting.WebForms' では不適切です。 

    エラー 2 'ReportDataSource' は、名前空間 'Microsoft.Reporting.WebForms' では不適切です。 

    エラー 3 'ReportDataSourceCollection' は、名前空間 'Microsoft.Reporting.WebForms' では不適切です。 

    エラー 4 'ReportDataSource' は、名前空間 'Microsoft.Reporting.WebForms' では不適切です。 

    エラー 5 'LocalReport' は、名前空間 'Microsoft.Reporting.WebForms' では不適切です。 

    エラー 6 'ReportViewer' は、名前空間 'Microsoft.Reporting.WebForms' では不適切です。 

    エラー 7 'ReportViewer' は、名前空間 'Microsoft.Reporting.WebForms' では不適切です。 

    エラー 8 'ReportViewer' は、名前空間 'Microsoft.Reporting.WebForms' では不適切です。 

    エラー 20 'ReportViewer' は、名前空間 'Microsoft.Reporting.WebForms' では不適切です。 

    エラー 21 'ReportViewer' は、名前空間 'Microsoft.Reporting.WebForms' では不適切です。

    エラー 22 'ReportDataSource' は、名前空間 'Microsoft.Reporting.WebForms' では不適切です。 

    -ブラウザ依存の問題か一応見極めを行いました-

    IEとFireFox双方で、Localhostのサイトへのアクセスを確認し、双方遷移されたページ側でセッション変数は得られませんでした。(初期のログオンページに戻る)

    抜粋ですが関係すると思われる部分のVBのソースです。

    ===========ログオンページのクリックイベントソース===========

    Protected Sub btnLogon_Click(ByVal sender As Object, ByVal e As System.EventArgs)

            Dim result As New AuthenticationResult
            result = IsAuthenticated(txtUserID.Text, txtPassword.Text)
            If Not result.IsSuccess Then
                lblErr.Text = result.MessageString
                Return
            Else
                Len = result.MailAddress.Length
                Pos = result.MailAddress.IndexOf("@")
                Session("StaffID") = result.MailAddress.Remove(Pos, Len - Pos)
                Session("StaffName") = result.LoginUserName
                If Not CheckUser(Session("StaffID")) Then
                    lblErr.Text = "当システムの利用を許可されていません。"
                    Return
                End If
                System.Diagnostics.Debug.Print("この場面では入ってます【StaffName①】⇒" & Session("StaffID"))
                Response.Redirect("menu.aspx", False)

            End If

    End Sub

    ===========遷移先ページのLoadイベントソース===========

    <script runat="server">
        Public Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
           
            System.Diagnostics.Debug.Print("ここでは消えてます【StaffName②】⇒" & Session("StaffID"))
            If Session("StaffID") = Nothing Then
                Server.Transfer("logon.aspx")
                Exit Sub
            End If
            Label1.Text = Session("StaffName")
        End Sub

    </script>

    ご見解を頂けますと幸いです。

    2015年4月14日 6:20
  •             Response.Redirect("menu.aspx", False)

    関係あるかないかわかりませんが、こうするならそのあとに、

    Context.ApplicationInstance.CompleteRequest()

    も必要だと思います。

    セッション系の動作と関係あるかはまた別の話ですが。

    2015年4月14日 6:45
  • ちなみにセッションの設定はInProc(デフォルト)でしょうか?

    開発環境は、開発WebサーバかIIS ExpressかIIS(本物)か、どれあたりを使っているでしょうか?

    セッション変数が消えるパターンで多いのは予期しないアプリケーションの再起動です。

    あとは、うーん、普通のRedirectの流れではあんまり起こらないですねえ…

    ※変なページ制御をしていると、リクエストの前後関係とかで問題が発生したりというパターンもあるんですが

    2015年4月14日 6:52
  • ご支援をありがとうございます。

    >開発環境は

    開発Webサーバの認識です。

    ちなみにVS2012の画面上部にWebサイトというメニューがあります。この中の、ASP.NET構成を選択すると、ASP.NET開発サーバ:ポートXXXXXというアイコンが右下のタスクバー内に現れてきます。

    このアイコンを右クリックすると、"Webブラウザで開く"という選択が行えるのですが、この結果はいつも Server Too Busyという文言のみの白い画面表示になります。

    2015年4月14日 7:32
  • Oracle データベースにあるユーザー情報を元に独自の認証方式を組み込んだシステムということのようですね。

    そうであれば、その認証システムを開発した人に聞くのが一番早いと思うのですが、そうできない事情があるのでしょうか?

    質問者さんが開発したということであれば、掲示板に書いてあること以外何も知りえない第三者より、質問者さんのほうがシステムに関する深い知識をお持ちのはずで、質問者さん自身で解決する話ではないかと思うのですが。


    • 編集済み SurferOnWww 2015年4月14日 8:58 誤字訂正:意外 ⇒ 以外
    2015年4月14日 8:50
  • いつもお世話になっております。

    >Oracle データベースにあるユーザー情報を元に独自の認証方式

    接続文字列で確立したOracleデータベースとの認証は行っておりません。

    If Not CheckUser(Session("StaffID")) Then
        lblErr.Text = "当システムの利用を許可されていません。"
        Return
    End If
    System.Diagnostics.Debug.Print("この場面では入ってます【StaffName①】⇒" & Session("StaffID"))
    Response.Redirect("menu.aspx", False)

    とありますが、この CheckUser(Session("StaffID")) という関数はMSのSQLServerへログオンされたIDの存在を確認しにいっています。この認証部分について言及しなかった理由は、この関数の動作後のDebug.Printで

    セッション変数が格納されていることは確認済みのためでした。しかしながら

    Response.Redirect後のmenu.aspxのLoadイベントの最初で、再度Debug.Printを実施すると、同セッション変数がNothingになっている、というのが悩んでいるところです。

    当初OracleCleintについての記載をしなかったのは、話を複雑化してしまうかなぁと思ったためでした。

    2015年4月14日 9:22
  • > 接続文字列で確立したOracleデータベースとの認証は行っておりません。

    了解しました。でも、独自認証システムを開発して実装したのには変わりないのですよね?

    そうであれば、私の先のレス「その認証システムを開発した人に聞くのが一番早いと思うのですが、そうできない事情があるのでしょうか? 質問者さんが開発したということであれば、掲示板に書いてあること以外何も知りえない第三者より、質問者さんのほうがシステムに関する深い知識をお持ちのはずで、質問者さん自身で解決する話ではないかと思うのですが。」についてはどうなんでしょう。


    #問題を見つける際には、あやしそうなところの影響を少しずつ排除しながら(すなわち、コードをどんどん削っていって)、問題を再現できる必要最低限のコードにしてみるのが良いと思います。お試しください。

    #また、デバッガの使い方は分かるでしょうか? Debug.Print など使わなくても、デバッガでステップ実行しながら期待通りの値が得られているかを調べられます。それをやってなければ、是非やってみてください。


    【PS】
    セッションを有効にするための設定はきちんとされていると思っていていいのですよね? 例えば、セッション ID の授受にクッキーを使う設定になっているのにブラウザがクッキー拒否設定になっているとかいう初歩的なミスはないと思っていていいのですよね?
    • 編集済み SurferOnWww 2015年4月14日 14:40 PS 追記
    2015年4月14日 9:37
  • いつもお世話になっております。

    >独自認証システムを開発して実装したのには変わりないのですよね?

    >そうであれば、私の先のレス...

    >すなわち、コードをどんどん削っていって

    仰るとおりと思いましたので、認証部分はとってしまいました。すなわち、現在のソースはこのようになりました。

    なお、この認証部分(関数)を開発したのは私ですが、ステップ実行で関数後のセッション変数が維持されていることは確認済みでしたので、調査の焦点にあてなかった、というのが私の考えでした。確かに現在の調査上不要なので取ってしまって正解だと思いました。

    -遷移する元のページのボタンクリックイベント-

     Protected Sub btnLogon_Click(ByVal sender As Object, ByVal e As System.EventArgs)
            Session("StaffID") = "Maverick"
            System.Diagnostics.Debug.Print("セッション変数の【StaffName①】⇒" & Session("StaffID"))
            Response.Redirect("menu.aspx", False)
      End Sub

    -遷移先ページのロードイベント-

    Public Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
           
            System.Diagnostics.Debug.Print("セッション変数の【StaffName②】⇒" & Session("StaffID"))
            If Session("StaffID") = Nothing Then
                Server.Transfer("logon.aspx")
                Exit Sub
            End If
            Label1.Text = Session("StaffName")
    End Sub

    【PSに関して】

    開発端末ノブラウザはIEですが、「自動Cookie処理を上書きする」はOffとなっています。

    >例えば、セッション ID の授受にクッキーを使う設定になっているのに

    ここでいう設定は現在のコーディングということでしょうか?特段何も設定していないです。WebConfigにcookieless="true"の記述はありません。セッション変数維持のために対応しておくことがあるようでしたら、ご指摘頂けますと幸いです。

    なお、余談ですがcookieless="true"をWebConfigに記述してデバッグを実行すると、URLのサイト名の後ろがくるくると変化して、最終的に、初回ページさえ表示できない事象となりました。(WebConfigはもとに戻しました、すぐ)

    2015年4月15日 2:04
  • なお、余談ですがcookieless="true"をWebConfigに記述してデバッグを実行すると、URLのサイト名の後ろがくるくると変化して、最終的に、初回ページさえ表示できない事象となりました。(WebConfigはもとに戻しました、すぐ)

    クッキーを使う場合と同じ現象とは限りませんが、これを見る限りではアクセスのたびにセッションが再作成されてしまっているような感じですね。

    ※URLにくっつくセッションIDって再利用されないんでしたっけ?うろ覚え(安全性で考えると再利用されない気はしますが)

    とりあえず、遷移先で、セッションが新規かも確認して出力してみましょう(IsNewSessionだったかな?)。

    可能性としては、

    ・binフォルダやWeb.configへの書き込みなどによるアプリの想定外の再起動(ログ出力先をbinにしてしまっていたとか)

    ・Global.asaxのどこかで何か余計なことしている

    などがあるかなという感じです。

    --追記

    経緯や状況からいって多分ないはずですが、マシン名に_を使っていてクッキーがうまく保持できていなとかないですよね?

    • 編集済み なちゃ 2015年4月15日 2:35
    2015年4月15日 2:33
  • > -遷移する元のページのボタンクリックイベント-
    ・・・略・・・
    > -遷移先ページのロードイベント-

    「元のページ」がコードに書かれている login.aspx で、「遷移先ページ」が menu.aspx という理解でいいのですよね?

    であれば、「遷移先ページ」の、

    > If Session("StaffID") = Nothing Then

    にブレークポイントを設定してデバッグ実行してみたらどうなるでしょうか?

    「遷移する元のページのボタンクリック」で、そのブレークポイントで止まりますよね? そこからステップ実行したとき If の条件すなわち Session("StaffID") = Nothing が True になって「元のページ」に Transfer されるということですか? (何故、Server.Transfer を使っているのか謎ですが、とりあえずそれは置いといて)

    ということであれば、先の私のレスの【PS】に書いた、

    > セッションを有効にするための設定はきちんとされていると思っていていいのですよね?

    が疑問です。非常にプリミティブな話ですが、まずはセッション ID の授受が正しく行われているかどうかから調べた方がよさそうですね。

    web サーバー側は web.config の sessionState 要素でおこないます。

    sessionState 要素 (ASP.NET 設定スキーマ)
    https://msdn.microsoft.com/ja-jp/library/vstudio/h6bb9cz9(v=vs.100).aspx

    質問者さんが web.config に何も設定してなければ、デフォルトの値になっているはずです。(詳しくは上の記事を参照)

    その場合は、ASP.NET_SessionId という名前のクッキーを使ってセッション ID の授受が行われます。

    最初の要求に対する応答で、ブラウザが応答ヘッダに設定されたクッキーを受け取るはずです。以下のようになります。

    Set-Cookie: ASP.NET_SessionId=xxx...x; path=/; HttpOnly

    ブラウザが一旦クッキーを受け取ったら、ブラウザを閉じない限り、その後は毎回どのページを要求しても同じ名前/値のクッキーを要求ヘッダに含めて web サーバーに送信するはずです。

    Fiddler2 などのキャプチャツールを使って確認してください。

    2015年4月15日 4:13
  • 引き続きのご支援をありがとうございます。

    >とりあえず、遷移先で、セッションが新規かも確認して出力してみましょう(IsNewSessionだったかな?)。

    遷移先ページのLoadイベント内で Session.IsSessionを確認させて頂きました。(If文で)

    Trueでした。ページが遷移しただけで、セッションが変わっている??ということでしょうかね。

    BinフォルダにはコピペでOracleDataAccess.Clientを配置しています。一時的に消して様子を見たいところですが、これがないと、App_Code内のDatasetを生成できずビルドができない事態に陥ると思われ、消すに至っておりません。

    --追記に対し、

    開発端末である自身の端末名、ホスト名でよろしいでしょうかね??アンダースコアは入っておりません。

    VS2012で幾つかのWebサイトを構築済みですが、それらは同開発端末のデバッグが支障なく動作しております。そのどれもがそう差がない仕様で、セッション変数にログイン時の利用者IDを控える方式をとっていますから、今回だけその仕様が機能しないのは謎なのです...

    2015年4月15日 6:41
  • いつもお世話になっております。

    >「元のページ」がコードに書かれている login.aspx で、「遷移先ページ」が menu.aspx という理解でいいのですよね?

    そのとおりです。

    >そこからステップ実行したとき If の条件すなわち Session("StaffID") = Nothing が True になって「元のページ」に Transfer されるということですか? 

    全くそのとおりです。

    只今、Fiddler2のダウンロード&インストールを完了したところです。

    ちょっと難しそうですが、これを使い検証を継続します。まずはご報告まで

    • 回答の候補に設定 なちゃ 2015年4月16日 0:37
    2015年4月15日 6:46
  • いつもお世話になっております。

    Fiddler2のキャプチャ画面を添付します。ちょっとマシン名とかサイト名とか入っていてコッパずかしいですが。

    この結果から私が思うに、login.aspxとmenu.aspxでSessionIDは変わっていないのかなぁ、と思いましたが如何でしょうか?お手数おかけしますが添付の画像、オレンジの枠内をご確認いただけましたら幸いです。

    2015年4月15日 8:44
  • > オレンジの枠内をご確認いただけましたら幸いです。

    それを見る限りセッション ID は同じ(セッション ID の授受は問題なさそう)ですね。

    今ちょっと時間がないので、後でまた考えてみます。

    2015年4月15日 9:08
  • Global.asaxのApplication_StartとApplication_Endイベントにもログ出力なりブレークポイントなりを仕掛けて、リダイレクトのタイミングで実行されていないか確認してみてください。

    もし実行されている場合、アプリが再起動しています。

    2015年4月15日 9:30
  • もう一つ、

    Response.Redirect("menu.aspx", False)

    これを

    Response.Redirect("menu.aspx")

    にしても再現するか確認してみてください。

    もし再現しない場合、Login.aspxページ内の処理で何か余計なことをしている可能性があります。

    その場合、

    Response.Redirect("menu.aspx", False)
    Context.ApplicationInstance.CompleteRequest()

    として再現するかも確認してみてください。

    2015年4月15日 9:33
  • レスが遅くなりました。

    セッション ID の授受はクッキーを使って行われているようで、どうにも原因がつかめませんが、マイクロソフト公式解説書「プログラミング ASP.NET 4」の 17.3.2 章の「セッション状態が失われる理由」に書いてあったことを紹介しておきます。

    まず、sessionState 要素の mode 属性が InProc の場合(デフォルト・・・質問者さんのケースではこれですよね?)、ワーカープロセスのリサイクルやアプリケーションの再起動で失われます。(これは今回のケースでの原因としては考えにくいですが)

    次はアンチウィルスソフトの影響です。一部のアンチウィルスソフトは、web.config ファイルや Global.asax ファイルに変更されたという印をつけることがあるそうです。「元ページ」から「遷移先ページ」に遷移する際にそのようなことが起こるかどうかはわかりませんが、起こるとするとセッション状態が失われることはあり得ますね。

    その他、Bin や App_Code フォルダといった特別なフォルダの内容が更新されたりした場合も同様にセッション状態が失われることになるそうです。

    他の回答者の方がレスされていますが、Application.Start イベントが発生しているかどうかでそれが分かるかもしれません。

    また、開発マシンを変えるとか、サーバーで試してみるとかでも確認できるかもしれません。

    【追伸】

    Gloabl.asax の Application_Start メソッド内にブレークポイントを設定してもそこで止まらないことがありますので注意してください。詳しくは以下の記事を見てください。

    Application_Start のデバッグ
    http://surferonwww.info/BlogEngine/post/2011/08/26/How-to-stop-at-breakpoint-set-in-the-Application_Start-method.aspx

    • 編集済み SurferOnWww 2015年4月15日 13:24 追伸追加
    • 回答としてマーク saya24 2015年4月16日 1:22
    2015年4月15日 13:17
  • BinフォルダにはコピペでOracleDataAccess.Clientを配置しています。一時的に消して様子を見たいところですが、これがないと、App_Code内のDatasetを生成できずビルドができない事態に陥ると思われ、消すに至っておりません。

    binフォルダへの書き込みとは、こういったdllの配置のことではなくて、アプリケーション実行中にファイルを作成したり書き込んだりという意味です。

    他にもフォルダを作成したりとかファイルを(App_Data)以外に大量作成したりとか細かくはいろいろありますが。

    いずれにしても、再起動が走っていればApplication_Startが実行されるので確認できます。

    ※Application_Startでブレイクポイントが効かない場合って何かなと思いましたが、IIS(本物)にアタッチする場合の話ですね。

    2015年4月16日 0:40
  • いつもご支援をありがとうございます。

    >レスが遅くなりました。

    とんでもないです、時間を割いて頂きまして申し訳ない気持ちです。遅くまでありがとうございます。

    >次はアンチウィルスソフトの影響です。

    手っ取り早く検証できるこの疑いから晴らそうと思い、マ○フィーを止めてのデバッグ実行を試しました。

    すると...ズバリ正解でした。

    ウィルスソフトの動作を無効にしただけで、セッション変数が維持され、Logonページへ戻ってくることが無くなったのです。ひとまずお礼を。

    それにしても、この事象は非常にまずく、方針を変えざるを得ない状況でしょうか。同事象の事例・回避策がないかこの後調べてみます。とにかく会社のどの端末にもこのウィルスソフトは入っていますから。

    取り急ぎご報告まで

    2015年4月16日 0:54
  • どのファイルが触られているのか、わかりやすく更新日時などではわからないですかね?

    ※Web.config、Global.asax、App_Code内の何か、bin何の何か、辺りが候補ではありますが

    ウィルススキャンで例外設定できるならそれがいいと思います(Webアプリなのでサーバの設定だけでいいはず)。

    特定のアプリでだけ発生するというのは若干気にならなくもないですね、微妙なところですが。

    そのアプリからのファイルアクセスで、何かを誘発している可能性はあると思います。
    ただ、この辺は、ファイルアクセスしているを細かく調査しないとわからないですし、無駄骨の可能性もそれなりにあるので、ウィルススキャン側で例外設定するのが回避策としてはいいでしょう。

    2015年4月16日 2:07
  • 原因がわかって良かったです。

    自分もマ○フィーがそういうことをするという情報を得られたことは収穫でした。

    > それにしても、この事象は非常にまずく、方針を変えざるを得ない状況でしょうか。

    取りあえずは、運用環境の Web サーバーに問題のアンチウィルスソフトが入っていなければ(多分入ってないと思いますが)、方針を変えるまでの必要はなさそうに思います。

    開発マシンでは、Web アプリの開発する際にアンチウィルスソフトを無効にするというのが面倒かもしれませんが。

    一般ユーザーの PC のアンチウィルスソフトは今回の問題とは関係ないので、今のままで良いのではと思います。


    もし、方針を変えるところまで考えるのであれば、ASP.NET 標準のフォーム認証に切り替える方向で検討されてはいかがですか?(何らかの理由で、ASP.NET 標準のフォーム認証という選択肢を捨てて独自認証にしたのでなければ)

    ASP.NET 標準のフォーム認証はセッション状態を使いませんし(暗号化された認証チケットをクッキーでやり取りします)、実装するのに自分では一行もコードを書かずに済みますし、それより何より、当たり前ですが ASP.NET との親和性が抜群です。


    【追伸】

    対症療法的かもしれませんが、セッション情報がシリアル化できるものであれば、その格納場所を現在の InProc(ワーカープロセスのメモリに保持)ではなく、StateServer または SQLServer(ワーカープロセスの外に保持)という手段もあります。

    詳しくは以下のページを見てください。

    セッション状態モード
    https://msdn.microsoft.com/ja-jp/library/ms178586(v=vs.100).aspx

    #商用に使うのであれば、InProc モードは論外という意見もあるようです。

    • 編集済み SurferOnWww 2015年4月16日 3:52 追伸追加
    • 回答としてマーク saya24 2015年4月16日 4:08
    2015年4月16日 3:28
  • 念のため補足しておきます。

    ログイン状態をセッションに保存するのはやめてForm認証チケットを使う方法や、セッション状態をInProcではなく外に持つようにするのは、それぞれ望ましい方法なので、可能であればやる方が望ましいです。

    が、それはそれとして、いずれにしてもアプリケーションがしょっちゅう再起動する状態のままでは、実用環境では厳しいのが普通です(そりゃまあ頻度にもよりますけどね)。

    アプリケーションの起動自体にそれなりにリソースを消費しますので、パフォーマンス的にも影響が大きい(特に頻度が高い場合)のと、アプリケーション再起動中は一時的に複数リクエストが複数AppDomainで同時実行されるため、アプリのつくりがきちんとしてないといろいろ影響があったりします。

    もし、ウィルススキャンで除外設定をできるのであれば、Global.asax、Web.config、binフォルダ内、辺りをそれぞれ除外設定して、どこを外すと再現しなくなるか確認してみましょう。

    ※Webのアプリフォルダ全体を除外するとかは、あまりお勧めしません(この辺は条件にもよるのですが)


    • 編集済み なちゃ 2015年4月16日 4:27
    2015年4月16日 4:26
  • ありがとうございました。

    >ASP.NET 標準のフォーム認証に切り替える方向で検討されてはいかがですか?

    検討致します。大したシステムじゃないのですが、これを機会に勉強して取り組んでみたいと思います。お恥ずかしい話Grobal.Asaxさえないですが、これも私の怠慢さが故の話でした。

    いずれにせよ、今回もお時間を頂きましてありがとうございました。

    同一開発端末で幾つかのサイトを同じ仕様で構築済みですから、ウィルスソフトが干渉する何かの要因がこのプロジェクト側にあるのだと思います。

    2015年4月16日 8:53
  • お世話様でした、なちゃ様

    >ログイン状態をセッションに保存するのはやめてForm認証チケットを使う方法や、セッション状態をInProcではなく外に持つように>するのは、それぞれ望ましい方法なので、可能であればやる方が望ましいです。

    ごもっともな意見です。これから研究してまいります。また何かの機会でご支援頂けましたら幸いです。お時間を頂きましてありがとうございました。

    2015年4月16日 8:56