japan.internet.comThe Internet & IT Network
Twitter
RSS
  • ニュース
  • コラム
  • リサーチ
  • ヘッドライン
  • 特集
  • ブログ
  • プレスリリース
  • 専門チャンネル
  • イベント
  • ランキング
  • ニュースメール
2009年11月9日
文字サイズ文字サイズ小文字サイズ中文字サイズ大
ソニーがPSPの新モデル「PSP go」を発売。あなたは買いましたか?
買った
買っていないが欲しい
欲しいと思わない
他のPSP製品を持っているのでいらない
投票締切 11/16 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へインポート
最新トップニュース
プライバシー ジャパン・インターネットコム版
【プライバシー ジャパン・インターネットコム版】
認証がオンラインビジネスの鍵である理由(11月4日)
百式のネットビジネス研究
百式のネットビジネス研究
絵本を読む声を録音して送ることができる「A Story Before Bed」(11月9日)
アウンコンサルティングのモバイルSEO
アウンコンサルティングのモバイルSEO
検索エンジンはなぜ検索結果を常にリニューアルしているのか(11月9日)
週刊-サイト別アクセス状況データ
週刊-サイト別アクセス状況データ
子供とケータイについて考える〜授業にケータイを活用した取組み〜(ビデオリサーチインタラクティブコラム)(11月9日)
不況時代の Web ビジネス最適化講座
不況時代の Web ビジネス最適化講座
こんな話良く聞きます、お客様のよくある失敗談(11月6日)
海外ソーシャルウェブに学ぶ成功の秘訣
海外ソーシャルウェブに学ぶ成功の秘訣
私のおすすめツィート術 〜 何をつぶやけばいいかわからない人から、効率的にツールを使ってツィートしたい人まで(11月5日)
成約率、反応率を上げる Web 文章術
成約率、反応率を上げる Web 文章術
アクショントリガーの法則を用いて、完成度を高める(11月5日)
「Webからの脅威」―その傾向と最新対策
「Webからの脅威」―その傾向と最新対策
新たな対策技術:URL フィルタリングと Web レピュテーション(11月4日)
スマートにソーシャルウェブを構築しよう
スマートにソーシャルウェブを構築しよう
「Twitter」と「2ちゃんねる」、イザというとき役に立つのはどちら?(11月4日)
ROI向上のための戦略的WebPR
ROI向上のための戦略的WebPR
「戦略的 WebPR」の実践メソッド(5)〜ネットを活用した戦略 PR のしかけ方〜(11月4日)
エンジニア転職ノウハウ開発室
エンジニア転職ノウハウ開発室
景気は悪いまま!だからエンジニアよ、立ち上がれ(11月3日)
Copyright 2009 Japan Internet.com K.K. All Rights Reserved.http://www.internet.com/