実データに対するロボット避け (robots.txtの追加)†
- ページ: BugTrack
- 投稿者: Ratbeta
- 優先順位: 低
- 状態: 却下
- カテゴリー: その他
- 投稿日: 2004-10-24 (日) 17:19:08
- バージョン:
メッセージ†
attachディレクトリ以下が間違って検索ロボットに登録されないようにするために、
robots.txtを設置する必要があると思われます。
robots.txtの例 :
User-agent: *
Disallow: /attach/
Disallow: /backup/
Disallow: /cache/
Disallow: /counter/
Disallow: /diff/
Disallow: /image/
Disallow: /lib/
Disallow: /plugin/
Disallow: /skin/
Disallow: /trackback/
Disallow: /wiki/
関連 : BugTrack/143など。
See Also†
ちょっと確認: robots.txt†
- とほほのＷＷＷ入門: robots.txt とは？
- No Need Robot Club ロボット型検索エンジンへの対応方法
コメント†
- これはつまり添付された画像も(イメージ)検索の対象外になるということですか？ --
- 関係ありません。直接アクセスに関しては、1.4.4に含まれている.haccess を理解する環境(Apache) であれば、既に禁止されていますね。attach/index.html をデフォルトのページとして扱う多くのWebサーバーであれば、たとえ.htaccessが無効であっても、どのようなファイルが存在するのか探索することができません。refプラグインでインライン展開しているものや、ref/attachプラグインが表示する一覧のリンクからattachプラグインの機能で画像を表示させたような場合は(index.php/pukiwiki.phpを経由して画像を取り出すので)この設定は無関係です。 -- henoheno
- このrobots.txt を添付した場合、意味があるのは PukiWiki をWebサイトのルートに設置した場合のみの様ですね。(robots.txtを置く場所もそうでなければなりませんから、それはそうですが・・・ (^^; )ちょっと検討させて下さい。 -- henoheno
- うーん、18:35:54さんに解説したような現状の状態や、上に書いたような robots.txt の意味合い(や制限事項)を踏まえると・・・本当に必要なのかな？ -- henoheno
- 必要だと感じる理由は、例えば閲覧認証されたページがあって、htaccessが効いていない場合に、検索サイトからその内容が覗き見出来る可能性がある…といったことです。 -- Ratbeta
- そうでしょうか。そもそも閲覧させたくないデータについて、Webサーバーの公開ディレクトリの下に、何もせずに(確認および対処せずに)放置するべきではありません。従来から、Apacheであればhttp.confや.htaccessでアクセス権を調整したり、IISであればディレクトリの権限を調節するような形でアクセス制限を行うことは可能です。PukiWiki 1.4.4 で .htaccess を添付しているのは(YukiWiki と同様に)一つのサービスですが、それ以上のものではありません。直接アクセスに対して一番良い対策は、データ類をWebサーバーから見えない場所に(直接アクセスできない場所に)格納することです。そしてですね (^^; robots.txt については、「アクセス制限」と言えるほどの強度がありません。何か説明の方向が変な方に行っていませんか？ (^^; -- henoheno
- 1.4.3までは attach/ ディレクトリ以下のデータを露出させてしまっていましたが、1.4.4移行はそれも全てラッピングしてしまっているので、通常の利用の範囲では(robotによるアクセス含む) もはや attach/ を含む実データのパスが露出する事が無いことも補足しておきますです。これがまだ何か露出している様であれば、検索エンジン避けになるというご意見もわかるのですが (^^; -- henoheno 2004-10-24 (日) 21:54:09
- 変な方向に進んでいる…のは確かにそうですね (^^; どちらにしても、htaccess非対応環境では中身が覗けてしまう…のは問題だと思います。 -- Ratbeta
- えーと robots.txt の話ではなくなっていますが (^^; それに対しては、下でも触れていますが、そもそも自分あるいはサーバー会社が使用している技術を確認して適切なアクセス権限をかけて安心するか、そもそも露出させる必要が無いデータを露出させないことです (^^; -- henoheno 2004-10-24 (日) 22:24:11
- 何らかの訴訟問題となった場合には、設置していればそのディレクトリへのアクセスの禁止を宣言していたということで損害賠償の場合に有利になるでしょうけど... それが必要な場合には、設置するぐらいのスキルは設置者に必要かと.. ただ、.htaccessが有効でないサイトもありますので、.htaccessに関しても含めて どこかに注意書きがいるかも。 -- merlin
- 関係ないでしょう。robots.txt の存在理由や、それに記述する内容は「お願い」であって、禁止措置ではありません。それを無視したアクセスがあったとして、管理者が絶対にアクセスを防ぐための決定的な措置を行ったと証言してもその有効性は疑わしいものです。また、管理者が取るべき措置を誤ったことによる損害は管理者およびその雇用者のものです。.htacces については、今まで散々Apache限定と繰り返し述べており、今後もそうするでしょうから問題ないと思います。robot.txtの有効性についてもこのページがケアする事になると思います。 -- henoheno 2004-10-24 (日) 21:30:44
- 法律問題は結構微妙になるし、完全該当の判例があるかどうかはわかりませんが、いちおう関連がありそうなのを eBay vs BE. あと apacheでもレンタルサーバによっては、.htaccessを置けない所もあります。-- merlin
- ざっと拝見しました。これは著作物に関する争いで「eBayは公開しているデータ(eBayおよびその顧客の著作物が含まれる)をプログラムによってクロールされる事を望んでいない(そのためにrobots.txtも設置してある)。なのにBEが(robots.txtも無視し)Webクローラーを使ってeBayに極端な負荷をかけた。それだけでなく、IPアドレス遮断のような対策を取っても、積極的にproxyを使ってそれ回避してeBayにとって迷惑な行為を行い続けたので取り急ぎ止めさせてくれ」というものの様ですね。その中で「YahooやGoogleはrobots.txtを尊重している」という補足があると。それだけですね。話の主題は robots.txt ではない様です。ちょっと目が疲れました (^^; -- henoheno 2004-10-24 (日) 22:19:22
- 多分最初の/を除ければルート以外でもOKなはずです(ちなみにrobots.txtは必ずしもルートで無くてはならないということはありません)。 -- Ratbeta
- 外部からやってくるWebロボットに依存します。そもそもrobot.txtを見ないものもありますが、多くは(見たとしても)サイトルートでしょう。 -- henoheno 2004-10-24 (日) 21:27:29
- まあ、ロボットにはピンからキリまで居ますからね…。robots.txtを読まないものも中には有りますし。確か定義上はサイトのルートから徐々に階層を掘り下げて見ていく必要があるはず。 -- Ratbeta
- 既存の実ディレクトリに */index.html に meta タグを足す、というのもちょっと考えてみましたが、意味が無い気がします (^^; -- henoheno
- 確かに、それだとなんとなく無駄な気がします (^^; まあ、index.htmlが登録されないようにするにはそれも必要かもしれませんが、必要なのはディレクトリ全体の隠蔽ですからね…。 -- Ratbeta
- *1 robots.txt自体の論議はロボットが守ってこそ意味がある*2ので、ほとんど意味ないです。（むしろ、負荷や権利にみたらアンテナのほうが迷惑） -- みこ
- 結局のところロボット対策というのはアクセス制限以外にありません。ちなみに、好みとしては index.html ではなく index.php にして HTTP 302 でトップページにジャンプするというほうがロボット対策にもなり、わたしは好みです。（xoopsは javascriptで history.back() をおこなってますね・・・ロボット対策にはなりませんが (^^;） -- みこ
- 302で移動させるのはいいと思いますが、DirectoryIndexにindex.phpが設定されていない場合は無意味になってしまうので、どちらかといえば現状のままの方がいいと思います。 -- Ratbeta
- そうですね＞アクセス制限。 メーリングリストの過去ログを検索エンジンからブロックするために、ベーシック認証(ダイアログにはアカウントとパスワードが表示される)を使う事例もありますね。 -- henoheno
- 結論としては、却下とさせて下さい。要求と機能に取り違えがあります。また、そうでなくとも、配置すべき場所はPukiWikiの配布ディレクトリの中ではありません。robots.txt を使用するかどうか、またその内容は管理者の設計に強く左右されるため、内容を決定することもできません。 -- henoheno
robots.txtについて†
- robots.txt はその名前の通りに、検索エンジンのインデックス構築を主な目的とする「ロボット」による、公開情報の無作為なアクセス行為や、検索エンジンからのユーザー流入による被害を減らすために設けられます。 -- henoheno
- ロボットによるサーバー負荷の影響(集中)を低くする
- 検索エンジンを経由して流入するかもしれない誰かによる影響を低くする (いたずら、トラフィックそのもの、etc)
- 検索エンジンにゴミを渡さない
- 上記からもわかる通り、robots.txt がカバーする物件は「公開されている著作物」です。非公開の著作物の流出を妨げるための技術ではありません。ベーシック認証、ダイジェスト認証、アクセス制限などの技術などになり代わるものではなく、それらを補強するものでもありません。 -- henoheno
本来のケースについて†
- さて、robots.txt を本来の使途通りに、PukiWikiのために使おうとするならば、以下の様なサイト構成になるはずです。 -- henoheno
- 1) robots.txtをサイトの最上位ディレクトリに配置します。
- 2) 検索エンジンから隠したいPukiWikiを何らかのディレクトリの下に配置します。
- 3) robots.txtには2のディレクトリを丸ごと無視するように記述を加えます。
サイト構成の例:
/index.html
/pukiwiki.php
/robots.txt
/open_but_hates_google/pukiwiki.php <= 検索エンジンから隠したいPukiWiki
/just_my_hobby/pukiwiki.php
/robots.txtの中身の例:
User-agent: *
Disallow: /open_but_hates_google/
- このようにすることで、検索エンジンのロボットは open_but_hates_google ディレクトリをインデックスに入れない様にしてくれる「かもしれません」。なお、該当ディレクトリは公開の物件ですから、いつの時点でも他のサイトからリンクされることがありますし、人の流入は常にありえます。「非公開」という状態ではありません。 -- henoheno
- 以上の検討結果から、「セキュリティ対策としてrobots.txtを用いるべきである／それは有効である」、「置き場所としてPukiWikiの配布パッケージのルートが適当である」、また「robots.txtの中身が一意に定まる」という主張を却下します。 -- henoheno
この件に関するコメント†
- なお、attach/ディレクトリに関しては上記コメントにて述べた通りです。 -- henoheno
- 本来の状況をどうやって説明するべきか考えていたら、妙にしすてまちっくな文になっていしましましたよ (^^; 疑問等あれば、随時このページ(上のコメントの方)で続けて下さい。 -- henoheno
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
