japan.internet.comThe Internet & IT Network
Twitter
RSS
  • ニュース
  • コラム
  • リサーチ
  • ヘッドライン
  • 特集
  • ブログ
  • プレスリリース
  • 専門チャンネル
  • イベント
  • ランキング
  • ニュースメール
2009年11月22日
文字サイズ文字サイズ小文字サイズ中文字サイズ大
事業仕分けによる次世代スーパーコンピューターの開発予算削減について、どうお考えですか?
賛成
反対
どちらとも言えない
投票締切 11/30 12:00
LinuxTutorial2001年4月14日 00:00

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

海外海外internet.com発の記事
  • Post to Twitter
  • Post to Facebook
  • このエントリーを含むはてなブックマーク
  • この記事をクリップ!
  • 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 のセキュリティ処理フェーズ >>

関連テーマ
  • プリンター用
  • 記事を転送
  • Post to Twitter
  • Post to Facebook
  • このエントリーを含むはてなブックマーク
  • この記事をクリップ!
  • BuzzurlにブックマークBuzzurlにブックマーク
  • Yahoo!ブックマークに登録
  • newsing it!
  • この記事をokyuuへインポート
最新トップニュース
Graphic Design Forum
【Graphic Design Forum】
流動的媒体と静的媒体に関する見解(11月18日)
「IT の耳」
「IT の耳」
【書評】『Hyper-V スタートアップバイブル』――仮想化についてのすぐれた解説書(11月20日)
百式のネットビジネス研究
百式のネットビジネス研究
世界でもっともパワフルな iPod のスピーカー「Wall of Sound」(11月20日)
週刊-サイト別アクセス状況データ
週刊-サイト別アクセス状況データ
ビデオリサーチインタラクティブ調査(月間インターネットオーディエンスデータ)(11月19日)
海外ソーシャルウェブに学ぶ成功の秘訣
海外ソーシャルウェブに学ぶ成功の秘訣
ゲーム業界を襲う世界的な激震。ソーシャルゲーム急成長のインパクト(11月19日)
今さら聞けない初歩からのアクセス解析
今さら聞けない初歩からのアクセス解析
サイトリニューアル前のアクセス解析活用法(11月19日)
成約率、反応率を上げる Web 文章術
成約率、反応率を上げる Web 文章術
文章力を磨き、キャッシュを生み出す Web サイト に(11月19日)
「Webからの脅威」―その傾向と最新対策
「Webからの脅威」―その傾向と最新対策
新たな対策技術:スパムフィルタリングと E-mail レピュテーション(11月18日)
ROI向上のための戦略的WebPR
ROI向上のための戦略的WebPR
「戦略的 WebPR」のしかけ方〜WebPR の効果測定手法とは〜(11月18日)
スマートにソーシャルウェブを構築しよう
スマートにソーシャルウェブを構築しよう
社員力を生かすソーシャルメディアポリシー(11月17日)
DevX
DevX
Erlangを使った並列処理プログラムの作成(11月17日)
Copyright 2009 Japan Internet.com K.K. All Rights Reserved.http://www.internet.com/