none
画面遷移について RRS feed

  • 質問

  • ASP.NETで開発しています。

    ログイン画面⇒一覧画面⇒詳細画面の構成のWebアプリです。

    Application_OnBeginRequestを利用して、ユーザーによる途中ページへの直接アクセスを防ぐようにしています。

    詳細画面などのURLを入力して直接アクセスしようとするとログイン画面に遷移するようにしています。

    ご意見をいただきたいのですが、ある条件の場合(例えば、URLの最後に識別文字列を設定など)にURLを入力して

    直接アクセスした場合にログイン画面で認証後に一覧画面をジャンプして詳細画面に遷移したいと考えています。

    実現方法についてご教授お願い致します。

    2011年11月21日 7:28

回答

  • WebFormで、ASP.NET標準のForm認証を利用しているでしょうか?

    この場合、認証が必要なページにアクセスしようとしたときに、認証が通ってなければログイン画面が表示されますが、このときクエリ文字列で元々アクセスしようとしたURLを保持しています。
    で、ログイン画面で認証が行われれば、標準でその元のアクセスしようとしたページが表示されます。

    何をいいたいかというと、標準のForm認証を使っているのであれば、何も考えることなく詳細画面のURLを開こうとするだけで質問されている遷移が行われる、ということです。

    このあたり、独自に認証を組み込んでいるのであれば、それに沿った仕組みを実装することになります。
    例えば識別のための文字列が設定されている場合はログイン画面に遷移するとき元のURLをクエリ文字列に持つようにして、認証後に該当のURLに遷移する、とかいった実装をすればいいのではないでしょうか。

     


    あおい情報システム株式会社 小野修司(どっとねっとふぁん)
    • 回答としてマーク 山本春海 2011年12月2日 7:52
    2011年11月21日 9:58
  • > SurferOnWwwさんが言われているようにASP.NET に関係なくIEのバ
    > ージョンによって違うというこなのでしょうか?

    そうです。

    前にも書きましたが、「IE8」「セッション」「共有」でググると参考
    になるページが多々見つかるので、それを読んでください。

     

    • 回答としてマーク yukimai 2011年12月2日 0:04
    2011年12月1日 12:37

すべての返信

  • WebFormで、ASP.NET標準のForm認証を利用しているでしょうか?

    この場合、認証が必要なページにアクセスしようとしたときに、認証が通ってなければログイン画面が表示されますが、このときクエリ文字列で元々アクセスしようとしたURLを保持しています。
    で、ログイン画面で認証が行われれば、標準でその元のアクセスしようとしたページが表示されます。

    何をいいたいかというと、標準のForm認証を使っているのであれば、何も考えることなく詳細画面のURLを開こうとするだけで質問されている遷移が行われる、ということです。

    このあたり、独自に認証を組み込んでいるのであれば、それに沿った仕組みを実装することになります。
    例えば識別のための文字列が設定されている場合はログイン画面に遷移するとき元のURLをクエリ文字列に持つようにして、認証後に該当のURLに遷移する、とかいった実装をすればいいのではないでしょうか。

     


    あおい情報システム株式会社 小野修司(どっとねっとふぁん)
    • 回答としてマーク 山本春海 2011年12月2日 7:52
    2011年11月21日 9:58
  • 既定の Forms 認証の動作は小野さんが書かれたとおりですが、

    > Application_OnBeginRequestを利用して、ユーザーによる途中ページへ
    > の直接アクセスを防ぐようにしています。

    で実装したものが、

    > 直接アクセスした場合にログイン画面で認証後に一覧画面をジャンプし
    > て詳細画面に遷移したいと考えています。

    というやりたいことを妨げているということでしょうか?

    回答者は、質問者さんが「直接アクセスを防ぐ」方法をどのように実装した
    のか何も知らないのですから、「ある条件の場合」はそれを回避するのに適
    切な方法を考えて、質問者さんが期待する解決法を提案するのは無理です。

    そもそも認証方式すら書いてないし・・・

    どのような情報を提供したら、回答者が状況を理解して、適切な回答ができ
    るか、よく考えて質問していただけたらと思います。

     

    2011年11月21日 12:07
  • SurferOnWwwさんと同じようなことを書きますが、

    認証方式は何をお使いでしょうか? 小野@どっとねっとふぁんさんが挙げておられますが、ASP.NET標準のForm認証はよく使われる方法かと思います。また「Application_OnBeginRequestを利用して」とありますから、HTTP標準のBASIC認証もしくはDigest認証などを実装されているのでしょうか。
    認証方式によってページのハンドリングが異なりますので、回答できません。

    それに加えて、HTTP、プロトコル自身を理解されていますでしょうか? ページ遷移などについてです。(一覧画面から詳細画面への)通常のページ遷移とおっしゃられている「途中ページへの直接アクセス」との違いを具体的に説明できますか?

    2011年11月22日 0:52
  • 返信ありがとうございます

    認証方式はForm認証を使っていますが、DBに入っているユーザー名、パスワードを使って認証をしています。

    一般的な利用シーンとしてはログイン画面⇒一覧画面(業務選択画面)⇒詳細画面(業務詳細画面)として

    利用されると考えています。

    例えば、承認回送ルートのある業務で、利用者が、ある業務の詳細画面でデータを更新した際に、更新したデータを

    承認者に確認してもらおうとした場合に、対象業務の詳細画面のURLを教えて直接アクセスした場合には、ログインした

    後には業務一覧画面を経由せずに詳細画面に遷移したいと考えています。

    小野@どっとねっとふぁんさんが記載されていますように、

    「標準のForm認証を使っているのであれば、何も考えることなく詳細画面のURLを開こうとするだけで質問されている遷移が行われる、ということです。」

    なのですが、ログイン画面を経由せずに直接、詳細画面が表示される挙動になる場合があるので、Application_OnBeginRequest

    を使用してログイン画面を表示させるようにしていますし、完全ではありませんが、不正アクセスの防止策にもなるかと思っています。

     

     

    2011年11月22日 3:04
  • 依然としてどういう状況になっていて何がしたいのか理解できませ
    ん。失礼ながら、質問者さんご本人も分かってなくで、明確な説明
    ができないような感じがします。

    「直接アクセスを防ぐ」方法をどのように実装したのか、説明でき
    ないでしょうか?

     

    2011年11月22日 13:11
  • ログインした画面(セッション)がある IE で対象のページを表示しようとしたり、ログインしている期間(クッキーやセッションの有効期間)が十分に長いと、ログインページをすっ飛ばすことはあります。
    Jitta@わんくま同盟
    2011年11月23日 0:12
  • > ログイン画面を経由せずに直接、詳細画面が表示される挙動になる場合があるので、

    Jittaさんが書いていますが認証チケットが存在する状態なら正しい動きですね。

    もし本当に何らかの問題がある状態なら、なぜその問題が発生するのかを確認するべきです。
    とりあえずほかの方法でその場を回避したとして、その回避方法が確実に正しいのか、抜けがないのか、ということを検証できますか?
    できているならいいですが、上記の挙動がなぜ発生しているか確認できていない状態では自分の実装が間違いないことに自信は持てないように思うのですが。。。

    で、今問題になっていることはなんでしょう。
    独自に実装している場合の考え方も前の投稿で書いているのですが、その方法は検討されたのでしょうか?
    まだやりかたがわからない、ということでの質問であれば、どのように独自の実装をしていて、なにをどうしたいかもっと具体的に記述してください。


    あおい情報システム株式会社 小野修司(どっとねっとふぁん)
    2011年11月23日 0:59
  • Jittaさんが書かれている通り、ログインページが表示されないのは以前に認証したセッションが有効だったのでしょう。「(一覧画面から詳細画面への)通常のページ遷移とおっしゃられている「途中ページへの直接アクセス」との違いを具体的に説明できますか?」と質問したのもその辺りの動作原理がわかっているかを確認するためです。

    web.configのforms要素でセッションの有効期限が意図通りの設定になっているか確認するといいでしょう。そうすればログイン画面を経由せずに詳細画面が表示されることはなくなります。

    次にログイン画面の入力後、直接、詳細画面が表示されてしまう件については、Application_OnBeginRequestなど無茶な方法は使わない方がいいです。たぶん、FormsAuthentication.RedirectFromLoginPageメソッドを使っていると思いますが、それの代わりにFormsAuthentication.SetAuthCookieメソッドを呼んだ上で一覧画面にリダイレクトしてやれば済むことです。
    # でいいのかな…?

    2011年11月23日 1:17
  • Jittaさん、佐祐理さんの指摘がちょっと微妙に見えたので。

    ASP.NETの標準のForm認証では認証チケットはクッキーを利用して実現されます。
    で、セッションもクッキーベースで実現されますが、認証チケットとは別管理です。

    独自の認証機能をセッションを利用して構築しているのであればセッションの設定を、標準のForm認証を使っていた場合の話であれば認証チケットについてきちんと理解するようにしてください。


    あおい情報システム株式会社 小野修司(どっとねっとふぁん)
    2011年11月24日 0:48
  • 質問者さんからの最初の返答に「認証方式はForm認証を使っています」とあります。その上で、どのあたりが微妙なのかもう少し詳しく説明していただけますでしょうか?

    セッションと認証チケットがサーバー側で関連付けられていないからこそ、認証チケットもクッキーで管理されているのでは…と思いました。(セッション自身が認証済みという扱いなら認証チケットは不要なような…) 結局、ログイン画面が表示されるかどうか=認証済みかどうか=認証チケットが有効かどうか、とつながりませんか?

    # 動作確認せず言っているので間違っていたら指摘してください。

    2011年11月24日 1:00
  • 返信ありがとうございます

    HTTPヘッダー情報を取得しました。

    Global.aspxに記述したApplication_OnBeginRequestを全てコメントアウトして、リダイレクト先のURLを直接入力しました。

    その際にはログイン画面が表示され認証後に業務一覧画面をジャンプして遷移先である詳細画面を表示されました。

    新規にブラウザを立ち上げてリダイレクト先のURLを直接入力したところログイン画面が表示されずに遷移先の詳細画面が表示されました。

    その時のセションIDは同じでした。ということは同じブラウザ上では既に認証されているということなんでしょうか?

    それは通常の挙動ということでしょうか。

     

    2011年11月24日 2:51
  • 質問者さんからの最初の返答に「認証方式はForm認証を使っています」とあります。その上で、どのあたりが微妙なのかもう少し詳しく説明していただけますでしょうか?

    > ログインページが表示されないのは以前に認証したセッションが有効だったのでしょう。

    この文章だと認証チケットの話かセッションオブジェクトの話かわかりにくくなってないかな、と思って。
    セッションオブジェクトと認証チケットが別のもの、という認識がきちんとできている方なら言いたいことを正しく読み取れると思いますが、元質問者の方はそうではなさそうだったので。


    あおい情報システム株式会社 小野修司(どっとねっとふぁん)
    2011年11月24日 4:54
  • > 新規にブラウザを立ち上げてリダイレクト先のURLを直接入力したところログイン画面が表示されずに遷移先の詳細画面が表示されました。

    認証チケットとしてのクッキーは永続するように発行することができます。
    標準のログインコントロールを使っている場合は永続化はチェックボックスにチェックを入れることで有効になったかと。
    そのように認証チケットが発行されていればこのような動作になって当然かと思います。

    #認証チケットがいつまで有効だったかは調べればわかるはずですが期間は相当長かったはず。

    > その時のセションIDは同じでした。

    何度も書いてますが、セッションと認証チケットは別に管理されていますので、認証の状態とセッションIDはなんの関係もありません。


    あおい情報システム株式会社 小野修司(どっとねっとふぁん)
    2011年11月24日 4:59
  • 小野さんが指摘されているように、フォーム認証 cookie を永続化したようで
    すね。

    フォーム認証 cookie を永続化すると、50 年のデフォルトで 30 分(注)の有効
    期限を持つクッキーがクライアントの HDD 上に作成されます。そのため、
    ブラウザをいったん終了してもアクセスできるようになります。

    (注)authentication の forms 要素の timeout 属性に設定した時間

    以下のページの「認証トークンを永続的な Cookie に格納するかどうかを制御す
    るには」のセクションを参考に、フォーム認証 cookie を永続化しないようにし
    てはいかがでしょうか。

    方法 : ASP.NET ログイン コントロールの高度な機能を使用する
    http://msdn.microsoft.com/ja-jp/library/ms178340.aspx


    • 編集済み SurferOnWww 2011年11月25日 12:23 誤り訂正
    2011年11月24日 14:21
  • それってweb.configで制御できませんか? そう思ってURLを挙げました。

    ASP.NET V1.1 の場合、永続的な Cookie は timeout 属性の設定に関係なくタイムアウトしません。一方、ASP.NET V2.0 の場合、永続的な Cookie は timeout 属性に従ってタイムアウトします。

    とありますけど。ついでに「既定値は"30"(30 分) です。」

    2011年11月25日 1:21
  • 永続的なcookieの有効期限について2つ話がでてきちゃいましたね。

    50年と30分。

    最近調べて50年になってたような気がしますが。。。
    もしかするとFrameworkのバージョンによって異なる部分かもしれません。


    あおい情報システム株式会社 小野修司(どっとねっとふぁん)
    2011年11月25日 2:23
  • 永続的 cookie の有効期限が 50 年というのは、Microsoft 発行の文書で
    もあちこちで目にするので(例えば下記)、信じて疑わなかったのですが、
    どうやら間違い(修正漏れ?)のようです。

    Login.RememberMeSet プロパティ
    http://msdn.microsoft.com/ja-jp/library/system.web.ui.webcontrols.login.remembermeset.aspx

     [次回のために保存] チェックボックスをオン(Login.RememberMeSet を
    true)に設定してログインすると、Set-Cookie: ヘッダーに expires が
    指定されますが、それは 50 年先ではなく、timeout に設定した時間だけ
    先の時間になりました。

    というわけで、"ASP.NET V2.0 の場合、永続的な Cookie は timeout 属性
    に従ってタイムアウトします。" が正しいようです。

    なお、認証クッキーの中にある認証チケットの有効期限、slidingExpiration
    がどう働くのか等は未確認です。

    2011年11月25日 12:17
  • > なお、認証クッキーの中にある認証チケットの有効期限、slidingExpiration
    > がどう働くのか等は未確認です。

    上記の件につき検証してみました。

    認証クッキーの有効期限(Set-Cookie: ヘッダーの expires の設定)と認証クッ
    キーの中にある認証チケットの有効期限は同じでした。

    slidingExpiration も期待通り動く(有効期限が延長されたクッキーが発行され
    る)のを確認しました。

    要するに、ログインの際 [次回のために保存] チェックボックスをオンするのと
    しないのとでは、Set-Cookie: ヘッダーに expires が追加されるか否かだけで
    した。

    以下のページの Community Content にコメントしましたので、何か反応がある
    かもしれません。

    Login.RememberMeSet Property
    http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.login.remembermeset(v=VS.100).aspx#CommunityContent

    2011年11月26日 4:14
  • 返信が遅れました。

    たくさんのご意見ありがとうございます。

    永続化の設定は以下のように記述していますのでしていません。

    FormsAuthentication.RedirectFromLoginPage(TextBox_UserID.Text, False)

    因みにWeb.configには以下のように記述しています。

      <authentication mode="Forms">
       <forms name="XXXXX" loginUrl="Login.aspx" protection="All" timeout="120" requireSSL="false" path="/">
        <credentials passwordFormat="Clear">
         
        </credentials>
       </forms>
      </authentication>

    ためしにtimeout="120を1に変更して実行してみますと必ずログインページが表示され認証後にリダイレクト先が表示されます。

    それは正しい動きなのでしょうか。

     

    2011年11月29日 5:06
  • それは正しい動きなのでしょうか。

    小野@どっとねっとふぁんさんがさらっと「で、ログイン画面で認証が行われれば、標準でその元のアクセスしようとしたページが表示されます。」という言葉で書かれています。この動作が標準の動作です。(そしてこの動作を変えたいというのが質問内容ですよね?)

    それに対しては私の回答を参照してください。具体的なメソッド名を挙げています。

    2011年11月29日 5:48
  • 返信ありがとうございます。

    元々Application_OnBeginRequestメソッドを使用して途中アクセスを防止しようとしていましたが、

    皆さんのご意見を基に検討しApplication_OnBeginRequestメソッドを使用しないようにしました。

    URL直接入力によってダイレクトに画面遷移しようとすると、一番最初はログイン画面が表示され、

    その後クエリ文字列を基に遷移先画面へ遷移します。

    しかし同じクライアント上で新たにブラウザを立ち上げて直接入力すると、ログイン画面が表示されずに

    ダイレクト表示されます。それはWeb.configに設定しているtimeoutの設定値による一度認証されて

    いるのでダイレクト表示されていることなのかを確認させていただきたかったのです。

    質問当初に逆戻りのような質問になってしまい大変申し訳ありませんがご教授お願いします。

    2011年11月29日 7:21
  • > しかし同じクライアント上で新たにブラウザを立ち上げて直接入
    > 力すると、ログイン画面が表示されずにダイレクト表示されます。


    それ、具体的にブラウザは何で、どのような操作をしてますか?

    使っているブラウザの種類やバージョンと「新たにブラウザを立ち
    上げ」という操作によりますが、最初にログインしたブラウザを閉
    じないで、それとは別に画面を開くと、画面は別でもセッションは
    共有になる場合があります。

    即ち、「新たにブラウザを立ち上げて直接入力」しても、そのブラ
    ウザから同じ認証クッキーをサーバーに送信するので、ログイン画
    面はスキップされます。

    結局、ASP.NET とは関係のないブラウザの操作の問題じゃなかった
    のですか?


    そうでなければ、ASP.NET 標準の Forms 認証を使っている限りは、
    認証クッキーに有効期限を設定した以外に理由は思い当たりません。

    > 永続化の設定は以下のように記述していますのでしていません。

    とのことですが、念のため、応答ヘッダーをキャプチャツールで見
    て、認証クッキーに有効期限が設定されてないか確認してください。

    [ログイン]ボタンのクリックで login.aspx にポストバックがか
    かり、サーバーからリダイレクト指示が返ってきます。その応答ヘ
    ッダーに認証クッキーが含まれているはずです。Set-Cookie: を見
    て expires の設定がないか確認してください。

     

    2011年11月29日 12:31
  • ブラウザはIE8です。

    IEのキャプチャツールで確認はしたのですが、ログイン画面→一覧画面→詳細画面に遷移した

    場合と同じクライアント上でブラウザを立ち上げ直接入力してログイン画面が表示された時の

    セションIDは同じではありませんでした。

    その状態から再度、同じクライアント上でブラウザを立ち上げ直接入力してログイン画面が表示された時の

    のセションIDはリダイレクト時と同じセションIDでした。

    認証クッキーはまだ確認はしていません。

    リダイレクトして一度ログイン認証が完了していて再度、同じブラウザ上でリダイレクトした場合には

    一度認証しているのでセションIDが同じということもあるのでログイン画面を経由せずにリダイレクト

    先の画面が表示されるのでしょうか。

    2011年11月29日 14:38
  • キャプチャツールで確認しました。

    expires = -1 でした。

    SurferOnWwwさんが記載されているように正しい挙動ということでしょうか?

    使っているブラウザの種類やバージョンと「新たにブラウザを立ち
    上げ」という操作によりますが、最初にログインしたブラウザを閉
    じないで、それとは別に画面を開くと、画面は別でもセッションは
    共有になる場合があります。

    即ち、「新たにブラウザを立ち上げて直接入力」しても、そのブラ
    ウザから同じ認証クッキーをサーバーに送信するので、ログイン画
    面はスキップされます。

    2011年11月30日 8:25
  • 前にログインしたブラウザを閉じてない、ということでいいですか?
    であれば正しい動きではないかと思います。

     


    あおい情報システム株式会社 小野修司(どっとねっとふぁん)
    2011年11月30日 11:29
  • > expires = -1 でした。

    それは間違いないですか? ASP.NET 標準の Forms 認証の場合はそのよ
    うにはなりません。「永続化」した場合は以下のようになり、「永続化」
    しない場合は expires=...; が存在しないはずです。

    Set-Cookie: .ASPXAUTH=...; expires=Wed, 30-Nov-2011 13:21:29 GMT; path=/; HttpOnly


    > SurferOnWwwさんが記載されているように正しい挙動ということでしょうか?

    ASP.NET 標準の Forms 認証ではない独自の違う実装をしているとする
    と、何が正しいのかは分かりません。

    標準であるとすると、ブラウザのアドレスバーに直接匿名アクセスが許
    可されてないページの URL を入力して、ログイン画面をスキップして
    直接アクセスできるのは、有効な認証チケット(認証クッキーは認証チ
    ケットの入れ物)がブラウザからの要求と一緒にサーバーに送られるか
    らです。

    例外はありません。セッション ID は関係ありません。

    「永続化」すると、認証クッキーはクライアントの HDD に書き込まれ
    るので、ブラウザを閉じて再度ブラウザを立ち上げてアクセスしても
    認証クッキーはサーバーに送られます。

    「永続化」しない場合は、認証クッキーはブラウザのメモリにしか保
    持されていません。なので、ブラウザを閉じれば認証クッキーは消え
    ます。

    逆に、ブラウザを閉じなければ認証クッキーは消えません。要求のた
    びに送られ続けます。(ただし、中身の認証チケットが有効かどうか
    は別の話で、timeout の設定によります)

    IE8 は、IE6/7 と違って、別プロセスでもセッションは共有されます。
    そのあたりは、「IE8」「セッション」「共有」でググると参考になる
    ページが多々見つかるので、それを読んでください。

    IE8 を起動してログインした後それを開いたまま、例えばデスクトッ
    プのアイコンをダブルクリックしてもう一つ IE8 を起動すると、どち
    らの IE8 から要求をかけても認証クッキーは送られます。(「ファイ
    ル」→「新規セッション」で開いた場合は例外)

    そして、timeout で設定した時間以内なら、どちらの認証クッキーも
    有効です。

    有効な認証クッキーを受信すれば、ユーザーは認証済みと判断されるの
    で、ログイン画面がスキップされるのは当たり前です。

    IE8 を起動してログインした後それを閉じると認証クッキーは消えます。
    それから再度 IE8 を起動してアクセスすると、今度はログイン画面が
    スキップされることはないはずです。

     

    2011年11月30日 13:46
  • 返信ありがとうごございます

    IE7/8/9で検証してみました。

    IE7では同じクライアント上で複数ブラウザを立ち上げて直接URLを入力して画面表示しても

    ログイン画面が最初に表示されました。(セションIDは全て別ID)

    IE8ではブラウザを立ち上げていた状態で新規にブラウザを立ち上げて直接URLを入力した場合は

    ログイン画面が表示、その後、ブラウザを立ち上げて直接URLを入力した場合に前回と同じセションIDが同じで

    ログイン画面がスキップされました。

    IE9ではブラウザを立ち上げていた状態で新規にブラウザを立ち上げて直接URLを入力した場合は

    前回と同じセションIDが同じでログイン画面がスキップされました。

    SurferOnWwwさんが言われているようにASP.NET に関係なくIEのバージョンによって違うというこなのでしょうか?

    2011年12月1日 1:17
  • > SurferOnWwwさんが言われているようにASP.NET に関係なくIEのバ
    > ージョンによって違うというこなのでしょうか?

    そうです。

    前にも書きましたが、「IE8」「セッション」「共有」でググると参考
    になるページが多々見つかるので、それを読んでください。

     

    • 回答としてマーク yukimai 2011年12月2日 0:04
    2011年12月1日 12:37