japan.internet.comThe Internet & IT Network
RSS
  • ニュース
  • コラム
  • リサーチ
  • ヘッドライン
  • 特集
  • ブログ
  • プレスリリース
  • 専門チャンネル
  • イベント
  • ランキング
  • ニュースメール
2009年7月4日
文字サイズ文字サイズ小文字サイズ中文字サイズ大
LinuxTutorial2001年4月14日 00:00

セキュリティと Apache:初級必読本 3

海外海外internet.com発の記事
  • このエントリーを含むはてなブックマーク
  • この記事をクリップ!
  • Buzzurlにブックマーク
  • Yahoo!ブックマークに登録
  • newsing it!
  • この記事をokyuuへインポート
tutorial logo
保護領域:アクセス制御される領域

Web の任意制御メカニズムで保護された領域は、それが 1 つのドキュメントでもサーバー全体であっても、保 護領域 (realm) と呼ばれる。サーバーはクライアントの証明情報をチェックする際に保護領域の名前を提供する ので、クライアントはどの証明情報を送信すればよいかが分かる。

保護領域の名前は、Apache の設定ファイルで AuthName 指示子によって指定する。引数は 1 つ、 つまり保護領域の名前だけだ。

メモ: Apache の古いバージョンでは、「AuthName」キーワード に続く行末までの部分はすべて保護領域の名前として解釈されていたが、この方式だと文字列中に引用符 (") が埋め込 まれた場合に問題があった。実際の HTTP プロトコルでは保護領域が引用符で囲まれるからだ。そこで Apache の新し いバージョンでは、指示子が 1 つの引数のみを受け付けるようになった。"This is my realm" のように、複数の単 語を使う場合には、文字列全体を引用符記号で囲む必要がある。

保護領域の名前は、適用される URL と暗黙的に関連付けられ、その下位の URL も同じ保護領域の一部となる。た とえば <URL:http://foo.com/a/> が保護領域「Augh」に属する場合、 <URL:http://foo.com/a/b/c/foo.html> も保護領域「Augh」に属することになる。

暗黙的な関連付けによって、たとえば <URL:http://foo.com/a/foo.html> と <URL:http://foo.com/b/foo.html> が別々のステートメントで保護領域「Foo」にあると宣言され た場合、これらは同じ「Foo」という名前をもつが異なる保護領域に属することになる。2 つとも「Foo」とい う同じ保護領域に属するように設定できるのは、それらの URL の上位 (この場合 <URL:http://foo.com/>) が同じ場合だけだ。

このような規則により、保護領域内のはじめて訪れるドキュメントへのアクセスを要求する際には、クライアントは 常に認証用のプロンプトを表示する。名前が同じだが異なる保護領域を訪れた場合でも同様だ。

AuthName 指示子には、上位のディレクトリから継承される場合を除いて、デフォルト値がない。

クライアント/サーバー認証のハンドシェイク
なんらかの任意アクセス制御のもとで、クライアント ソ フトウェアから、あるドキュメントに初めてアクセスする際、エンドユーザーが知らない間に裏側で多くのやり取りが 行われている。最初のアクセス時には、クライアントは対象となるリソースが保護されていることを知らないので、そ の要求に証明情報は含まれていない。サーバーが要求を受け取ると、それはアクセス確認に関するすべての承認フェー ズを通り、証明情報 (この時点では存在しない) がリソースへのアクセスに有効な値と一致しないので、サーバーは「 not authorized」ステータスを返すことになる。

「not authorized」という応答を受け取ると、通常、クライアントは証明情報を送らなかったことに気づいて、エ ンドユーザーにその入力を促すポップアップ ダイアログを表示するだろう。このダイアログ ボックスには、ドキュメ ントが属している保護領域の名前が表示され、ユーザーにユーザー名とパスワードを要求する。これらの情報が入力さ れると、クライアントは再度同じ要求を行い、それには今回初めて証明情報が含まれる。ここまでで、サーバーへの要 求は 2 度行われたことになるが、エンドユーザーには最初に行われた要求はまったく見えないので、それが行われたか どうかも分からないだろう。

証明情報を含んだ 2 度目のアクセス要求に対して「not authorized」ステータスを受け取った場合、クライアント は最初の要求時とは異なった応答をする。おそらくクライアントはユーザーに「これらの証明情報は承認されませんで した。再度試みますか?」と通知するだろう。最初の要求時には証明情報を送らなかったので、このようには通知されな いはずだ。

エンドユーザーがダイアログに何も入力せずにキャンセル ボタンを押すと、クライアントは通常、「not authorized」ステータスと共にサーバーが送信したエラーページを表示して、指示待ちの状態に戻るだろう。

次は Apache のセキュリティ処理フェーズ >>

関連テーマ
このエントリーを含むはてなブックマーク この記事をクリップ!
BuzzurlにブックマークBuzzurlにブックマーク Yahoo!ブックマークに登録
この記事をokyuuへインポート
最新トップニュース
データメーション
【データメーション】
中国が「Green Dam」フィルタ規制を撤回(7月1日)
Graphic Design Forum
【Graphic Design Forum】
Chris Dickman(6月25日)
プライバシー ジャパン・インターネットコム版
【プライバシー ジャパン・インターネットコム版】
グーグル・ストリートビューの問題について総務省の見解(6月23日)
エンジニアの独り言
【エンジニアの独り言】
システムを「使う」時代のエンジニアに求められるもの(6月2日)
最新ハイテク講座
最新ハイテク講座
電気は家庭でつくる時代へ!燃料電池「エネファーム」(7月3日)
アクセス解析で見るWebマーケティング
アクセス解析で見るWebマーケティング
決定力を探るアクセス解析(7月3日)
百式のネットビジネス研究
百式のネットビジネス研究
ファーストフードを高級っぽく盛り付けて紹介している「Fancy Fast Food」(7月3日)
週刊-サイト別アクセス状況データ
週刊-サイト別アクセス状況データ
ビデオリサーチインタラクティブ調査(月間インターネットオーディエンスデータ)(7月2日)
成約率、反応率を上げる Web 文章術
成約率、反応率を上げる Web 文章術
言葉がダイレクトにキャッシュを生む(7月2日)
不況時代の Web ビジネス最適化講座
不況時代の Web ビジネス最適化講座
アクセス解析エキスパートここだけの話、Web コンシェルジュの“勉強法”こっそり教えます(7月2日)
「Webからの脅威」―その傾向と最新対策
「Webからの脅威」―その傾向と最新対策
不正プログラムの分類(7月1日)
DevX
DevX
JavaScriptとDOMによる動的なWebページの作成(6月30日)
エンジニア転職ノウハウ開発室
エンジニア転職ノウハウ開発室
今のままで大丈夫?3匹の子ブタ的キャリア危険度診断(6月30日)
アイレップの SEM フロンティア
アイレップの SEM フロンティア
Web サイトは「無駄な穴のたくさん開いたじょうご」〜サイト成果向上の基本的な考え方(6月30日)
Copyright 2009 Japan Internet.com K.K. All Rights Reserved.http://www.internet.com/