- PR -

BASIC認証をクリアしたい

1|2|3|4 次のページへ»
投稿者投稿内容
田中
ベテラン
会議室デビュー日: 2002/05/08
投稿数: 54
投稿日時: 2005-05-18 11:44
最近TOMCAT+Strutsで開発を始めたばかりですがBASIC認証のことを教えて下さい。

制限領域を設けてそこへのアクセスはBASIC認証を必要としますが、ログアウトボタンを押したら先程の認証を無効としたいのですがやり方がわかりません。

BASIC認証はTOMCATのBasic認証を使用していて、ユーザ情報はDB(Oracle)に管理しています。
書籍などにはBASIC認証で制限をかける方法はありますが、解除する方法がありません。

よろしくお願いします。
Edosson
ぬし
会議室デビュー日: 2004/04/30
投稿数: 675
投稿日時: 2005-05-18 11:51
BASIC認証はセッションに対してかけられています。
ですので、ログアウトボタンとクリックしたときに、
セッションを破棄するようにすればいいです。
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-05-18 12:26
Web のことは良く知らないんですが・・・。

引用:
BASIC認証はセッションに対してかけられています。

HTTP にセッションなんてありましたっけ？ HTTP はセッションレスだから各アプリケーションサーバで Cookie やら URL やらを駆使して擬似的にセッションを作っているのだと思っていました。

HTTP 自体にはセッションという概念がないので、認証の継続も当然ありません。最初に認証すると、それがある程度持続するのは、ブラウザが気を利かせて Authorization: ヘッダを送り続けてくれているからじゃないでしょうか。サーバーが WWW-Authenticate: ヘッダを送ってくるたびに認証ダイアログが出てきたら大変だもんね。つまりブラウザ依存なんだと思ってました。

間違ってたらｽﾏﾝ。
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-05-18 12:36
んっと。
ちょいと長くなることをお詫びいたします。

まず前提であるBasic認証そのものの説明を簡単にしたいと思います。

普通のPageにアクセスを試みると、大抵の場合は200番のリターンコード
（問題なくOK）が帰ってきます（いやまぁ厳密にはほかにいくつかあるの
ですがその辺は調べてみてください）。
で、Basic認証が必要なPageにアクセスを試みると、サーバ（この場合は
Tomcatですかね）は200ではなく401を返します。
この401ってぇのをブラウザが把握すると、ブラウザは「そっかぁ。IDと
パスワードが必要なんだぁ」って認識をして、ユーザに入力を促します。
# Basic認証である、という把握は、「WWW-Authenticate: Basic realm="ほにゃらら"」
　ってなやつの"Basic"の部分で判断します
入力された後、ブラウザは「入力されたIDとパスワード」を、以下の手順で
処理して、もう一度サーバにリクエストを送ります。
コード:
  文字変数 = ID ＋ ':' ＋ パスワード;
  文字変数 = Base64のencode(文字変数);

  // 出力部分
  print "Authorization: Basic " + 文字変数 + CRLF;

これで、サーバが適宜認証をして以下略、となります。

で。
Basic認証ってこれだけしか機構がないです。
「でも、一度認証が通れば別の認証が必要なPageにいってももうIDと
パスワードは要求されないからちゃんとセッション処理されてるんじゃないの？」
正しい質問ですが誤った推測です。
Basic認証は「毎回認証を求める」のが正解です。で、そーゆー「面倒な部分は」
ブラウザが肩代わりをしてくれているだけです。
つまり「Basic認証が必要なPageを閲覧するとき、ブラウザは"毎回、IDと
パスワードを送出している"」訳です。

以上を踏まえまして。
もし「TomcatのBasic認証」というものが通常のBasic認証と同様のものだとすれば、
原則的には「ログアウト概念は存在しない」ことになります。
まぁ、小細工を弄してという方向性もあるのですが。
もしある程度のレベルの認証が必要であれば、出来れば違う認証方式にした
ほうがいいと思います。
# っていうか「毎回平文でIDとパスワードが流れる」ってどうよ？ とか思います :-P

何かのお役に立てばよいのですが。
がるがる
ぬし
会議室デビュー日: 2002/04/12
投稿数: 873
投稿日時: 2005-05-18 12:42
どもでし。がるです。
こっちはきっちりと余談です(笑

引用:

HTTP にセッションなんてありましたっけ？ HTTP はセッションレスだから各アプリケーションサーバで Cookie やら URL やらを駆使して擬似的にセッションを作っているのだと思っていました。

んっと。ものすごく厳密なレベルで話をすると
・HTTP1.1で、クライアントとのTCP/IPレベルでの接続を維持する機能
は一応あるです。で、そーゆーのを指して「HTTPにはセッションがある」とか
いう人がたま〜〜にいます。
ただ、そのセッションは飽くまで「TCP/IPレベルでの接続のつながり」な
だけで、セッションIDが取れてそれがCGIで使えて…とかって事はぜんぜん
ないです。
HTTPdの設定ひとつで「途中でぶつっと切られる」事もままありますし(笑

というわけで、未記入さんの発言は正しいと思うです。

引用:

HTTP 自体にはセッションという概念がないので、認証の継続も当然ありません。最初に認証すると、それがある程度持続するのは、ブラウザが気を利かせて Authorization: ヘッダを送り続けてくれているからじゃないでしょうか。サーバーが WWW-Authenticate: ヘッダを送ってくるたびに認証ダイアログが出てきたら大変だもんね。つまりブラウザ依存なんだと思ってました。

うふふふふ。
…ぢつは、どっかの携帯端末（もう古かったと思います）が、
「毎回認証ダイアログを出す」という、世にも奇妙な仕様になっていたことが
あります(笑

確かにブラウザ依存なのですが。あの機種でテストをしていたときは、
しみじみと「通常のブラウザの偉大さ」に感じ入ったものです。

いじょ。雑談でした。
未記入
ぬし
会議室デビュー日: 2004/09/17
投稿数: 667
投稿日時: 2005-05-18 13:28
引用:
HTTP1.1で、クライアントとのTCP/IPレベルでの接続を維持する機能は一応あるです。

Connection: Keep-Alive ですね。たしかに、クライアント/サーバーの両方を自分で完全に支配できるならセッション管理に使えそうですね。実際は、クライアントもサーバーも相手がいつ Connection: close を送ってくるか分からないので、セッション管理に使うのは至難の技。というかもともとソケット接続のオーバーヘッドを減らすために実装されたものですからね。
Edosson
ぬし
会議室デビュー日: 2004/04/30
投稿数: 675
投稿日時: 2005-05-18 13:30
書き込みしたものかどうか迷ったのでありますが・・・。

私の生半可な書き込みでスレ汚し失礼しました。
勉強して出直してきます。m(_ _)m
skulker
ベテラン
会議室デビュー日: 2004/06/08
投稿数: 67
投稿日時: 2005-05-18 14:27
サーブレット仕様のJ2EEセキュリティの項では、ログインは規定されていますが、ログアウトについては規定されていません。なのでブラウザを閉じる以外にポータブルなログアウトの方法はありません。
商用アプリケーションサーバだとログアウトの独自APIが提供されていたりしますが、Tomcatはどうだったか。
TomcatはHttpSessionを無効化すると認証情報も一緒に消えるような実装だったような。

サーブレット仕様とTomcatのマニュアル見てみたらどうでしょう。
1|2|3|4 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）