  |
はてなキーワード: robots.txtとは
ttp://archive.is/
↑ここ。
ここを使えば、
例えばこういうブコメ（http://b.hatena.ne.jp/entry/www.akitashoten.co.jp/news/201）で、
kyo_ju 出版
で？弁護士は誰がついてんの？/ちなみに魚拓を取ろうとしたらrobots.txtによりキャッシュが禁止されている、だそうです。2013/08/21
こんな恥ずかしいコメント（と、それに星つける恥ずかしい人達）に対して、
rgfx
魚拓禁止ですかそうですか http://archive.is/fgwwT 2013/08/22
前編はこちら
http://anond.hatelabo.jp/20120926165407
中編はこちら
http://anond.hatelabo.jp/20120926165533
基本的な機能とデザインが出来てきたら、細かな機能や説明ページなどの静的コンテンツも作っていきます。
８割程度出来たと思ったら、一度サーバーにアップロードして動作チェックしてみます。
たいていは上手く動作するはずですが、途中で一度チェックしておいた方が出来上がってから不具合を修正するよりは効率的です。
僕ははじめCORESERVERを使っていましたが、メールが送信できない不具合に遭遇して時間を取られました。
結局はCORESERVERとgmailの相性が悪いせい、という事で最後はさくらに移転しました。
あと、何となく動いているのが確認できたら、
このタイミングでGoogle AdsenseやAmazonアソシエイト、Ａ８やバリューコマースのアフィリエイトサイトに申し込みましょう。
特にアドセンスは申請してから使えるようになるまで１週間とかかかります。
２０１２年現在、アドセンスを含むアフィリエイトは期待するほど儲かりません。
でも、色んなWebサイトで見かけるこれらの広告の表示方法を学ぶことで、Webサービスに対する理解も深まりますし、
あと、全然儲からなくてもサイトにこれらの広告を表示しておくと、社会と繋がっている雰囲気が出て活況感が高まったり、
自分のサイトがちょっと立派に見えてテンションが上ったりします。
それぞれのプログラムの使用方法は検索すると出てきますが、敢えて本でおすすめはこの２冊。どちらも基礎です。
アフィリエイトで<得する>コレだけ!技 BEST100
サーバーに最新のファイル一式をアップロードして、入念に動作チェックをします。
core.phpのsession idをデフォルトの状態から違うものに変更したか、
全てのコントローラーのデバッグツールキットはOFFになっているか、
CakePHP本体は公開フォルダと別の階層にアップロードしているか、
htaccessの設定は間違っていないか、
などを確認します。
URLのwww付きとwwwなしはどちらかにリダイレクトさせて１つに統一できているか、
存在しないURLにアクセスされた時のエラーページに余分な情報が表示されていないか、
検索エンジン用のrobots.txtを用意、
ファビコンを設定する、
アクセス解析を設定する、Google Analyticsに登録しコードをサイトに埋め込む。
http://www.google.com/intl/ja/analytics/
Google先生に挨拶する。Google ウェブマスターツールに登録し、必要な情報を入力、Analyticsと紐付ける。
https://accounts.google.com/ServiceLogin?service=sitemaps
http://developers.facebook.com/docs/reference/plugins/like/
https://twitter.com/about/resources/buttons
その他、mixi、Google+などのボタン類も必要ならつけましょう。
全部出来たら、完成です。
Ｗｅｂサイトは作っただけでは（本当に）誰もアクセスしてくれません。
Webサービスを作ったそのあとに、「自分でもできる低コストなWeb PR方法」
http://blog.8bit.co.jp/?p=1944
こちらもチェック。
作ったwebサービスをPRできる！webサービスのリンク集サイトまとめ
http://smkn.xsrv.jp/blog/2011/11/web-service-linksite/
リリースした直後はGoogleのインデックス数も少なく、検索エンジンからのアクセスは期待できません。
検索エンジンからの流入は１ヶ月とか、時間が経つにつれ少しづつ増えてくるので気長に待ちます。
自サイトの情報のチェックはＳＥＯチェキ！とコメポンが便利。（作者のロプロスさん様様）
Ｋｏｍｅｐｏｎ！
それから、ステップ１１で紹介した本にも出ててますがフェレットも便利。
Ferret
５００円で客観的に評価してもらえるこちらも活用すると良いでしょう。
※2012年9月26日現在、このサイトは僕はまだ利用していませんが気になっています。
ホームページ評価.com
■最後に
ここまでやってみると、Ｗｅｂ開発の一連の流れが分かった気がしてきます。
初めて作ったサイトはしょぼくても、ひと通りやってみる事で
Ｗｅｂサービスの開発者としての入り口には立ったな、位には思えるはずです。
ここまでの知識をベースに、
ＳＥＯをがんばるもよし、
アドセンスやＡ８などのアフィリエイトで稼ぐしくみ作りをするもよし、です。
この記事を読んでアクションしたら、僕と同じようにアウトプットして、
そのリザルトをシェアしてトゥギャザーするオポテュニティをテラユビキタスｗ
１つ気をつけたいのは、
開発したサイトのサーバーの種類とか、CakePHPで作ってるとか、そのバージョンは1.3だとか、
そのサイトの詳細仕様は安易にこういう記事に書かないようにしましょう。
悪意のあるハッカーに攻撃の糸口をプレゼントする事になってしまいます。
この本も参考になります（まだやるか）
有益な情報をネット上に提供して下さっているWeb業界の皆さん、
それにいち早く辿り着けるはてなブックマーク、
皆さん、に感謝。
ツイッターはじめました
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
ブコメには「Googleが勝手に盗んだのにこっちがオプトアウトしなきゃいかんとは何事だ」というものが多いが、それらは問題を根本的に誤解している。
(もしかすると総務省、ストリートビュー車の無線LAN傍受でGoogleに指導。再発防止策と日本語で周知を要求 -- Engadget Japaneseの件と混同している人がいるのかもしれない。これはビーコン信号ではなく通信内容そのものを傍受していたという話で、基本的には別件である――但し、法解釈によっては同じ問題ともなり得るし、根底に共通している部分はある。これは論点がズレるので、ここでは完全に別件として扱う)
そもそもの問題は、Wi-Fiの仕様において、Wi-Fi機器のMACアドレスが強制タレ流しになっていることにある。これは例えばSSIDステルスの設定でも止めることはできない。
つまり、あくまでGoogleは垂れ流されている情報を集めたに過ぎないということである。垂れ流されているものなら勝手に集めてもいいのかという論点はあり得るが、その点についてはGoogleだけを責めても全く意味がない。誰であれ収集は可能だからだ。「しかし、他の誰がそんなことをするのか？」との反駁には「はい、PlaceEngineがしています」が答えになる。仕組みは全く同じだ。PlaceEngineは、Googleのような巨大企業でなくてもこの技術を商用レベルにまで持って行けるということを既に証明している。
つまり、この問題は「GoogleのDBから削除してもらう」だけでは全く解決しない。
(追記: どうもこの節の表現は誤解を招いたようだ。「できるからやってもいい、Googleは悪くない」という意味ではない。その議論があること、今後も必要なことは承知の上で、そもそも「できる」こと自体が根本的な問題であり、しかも各国の現行法において確実に違法な行為ではないということが重要だ。何度でも言うが、Googleを憎んでも問題は全く解決しない。あくまでここでは問題の本質を理解することと、現実的で効果的な解決方法について考えたい――もちろん、GoogleやAppleやMSなどを相手取って世界中で訴訟を起こす、というのも一つの手だろう。今のところ強制力を持ちたいなら勝訴の判例を作るしかないし、勝訴すれば抑止力を備えた最強の解決手段になる。どうぞ。)
(a) 「申し出のあったMACアドレスは削除し、今後も登録しないようにする」という対応
技術的にはすぐにでも対応可能。ただし、本人以外の手によって無差別に大量のアクセスポイントを削除するという妨害行為を防止できないかもしれない。
PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して、そのような手段が用意されていることを周知しなくては問題は解決したといえず、十分な周知は困難と思われる。
新たなアクセスポイントを購入するごとに削除手続きをする必要があることについて納得しない者が、「私のものは登録するな」という主張で争ってきたら対応できない。
(b) 「SSIDステルス設定にしているアクセスポイントは、登録拒否の意思があるとみなして、登録しない仕組みとし、また、既に登録されているものは次回検出時に自動的に削除されるようにする」という対応
技術的には容易に可能。しかし、そのような仕様であることを周知しなくてはならない。PlaceEngineを利用していない人（PlaceEngineの存在さえ知らない人を含む）に対して周知しなくては問題は解決したといえない。
(c) 「暗号化設定されているアクセスポイントは登録せず、他は削除する」という対応
暗号化していないアクセスポイントは特定の相手方に対してのものではないとみなすことで、電波法59条の問題をクリアできるかもしれない。
しかし、これを採用すると登録アクセスポイント数が減ってしまい、位置の測定制度が低下する。
(d) 所有者の同意を得たアクセスポイントしか登録せず、他は削除する」という対応
まず、ブコメで要求されているような「オプトイン」の仕組みは(d)だが、これは実現性に乏しいと考えられる。どうやってオプトインするんだという問題もあるわけだが、そもそも「誰でも収集できる」のだから、個別にオプトインなど根本的に不可能であるし、無意味でもある。例えGoogleが独自にオプトイン方法を用意したとしても本質的な問題は全く解決しないばかりか、ユーザに「Googleでオプトインしなければ安心」という誤解を与えかねないという懸念もある。
(b)や(c)についてはサービスプロバイダ側の設計の問題であり、ユーザは関与することができない。
今回Googleが提案した方法は、(a)の改良型(あるいは(a)～(c)のハイブリッド)というべきものである。再掲。
Google が公表したオプトアウトの方式は「アクセスポイントの所有者に対して、名称 (SSID) を末尾が " _nomap " で終わるように変更することを求める」もの。たとえば SSID が " Jitaku_AP " だった場合、無線LAN機器の設定から " Jitaku_AP_nomap " に変更することになります。
オプトアウトという意味では、(b)のSSIDステルス法も同様である。それよりも_nomapが優れているのは、これが「うちのAPをマッピングしないでくれ」という明確な意思表示となるからだ。
SSIDステルスや暗号化をオプトアウトフラグとして扱うかどうかは単に実装に期待するしかないが、_nomapがデファクトになれば、万一オプトアウトが実装されずにマッピングされた際「俺は一般的に合意されている方法でマッピング拒否の意思表示をしていたぞ！」と法的に主張できる可能性がある。Wi-Fiの規格に変更を加えるものでもなく、この用途以外に意味を持たないことから、デファクトとして広まりやすいだろう。確かにSSID変更が困難なケースは考え得るが、しかしこれ以上に簡単な代案は私には考えられない。
解決しない。
ここに挙げたどの方法を採ろうとも、原理的に「サービスプロバイダのマナー」程度にしかなりようがないからだ。オプトインですら、である。robots.txtを無視するクローラを根絶することができないことにも似ている。そしてそれは、Googleの責任ではないし、Googleに責を負わせても全く意味がない。
最初に述べた通り、そもそもの問題は「Wi-Fi機器がMACアドレスをタレ流しにしている」ことであり、これはWi-Fiの仕様改訂で対応しないとどうしようもない。また、対応したとして、新方式へ完全に置き換わるまでには気が遠くなるほどの長い時間が必要だろう。WEPすら未だに根絶できないというのに。
また、Wi-FiはMACアドレスをタレ流しているぞ、これは防げないぞ、という啓蒙ももっと必要だろう。一般ユーザには何のことやらさっぱりわからないと思うが、それでも啓蒙しないよりはマシである。
一つ付け加えるなら、個人的には、デファクトとなり得るオプトアウト方法を提示したGoogleさんはもうちょっと褒められてもいいと思う。これはAppleやPlaceEngineが今までしてこなかったことだ。
ちなみに、Google Location Serverでは既に「2つ以上のMACアドレスがDBとマッチしないと位置情報を返さない」などの様々な対策を実施済のようである。これにより、もしMACアドレスやSSIDが漏れたとしても、その所在地をこんな方法で正確に掴むことは困難になっている。PlaceEngineは知らない。
もう一つ。この問題は、Wi-Fiだけに起こりうる問題ではない。ひろみちゅ先生は本来この問題をRFIDの普及によって起こりうる問題として予測していたそうである。この辺りもっと知りたい方はgoogle:高木浩光 PlaceEngineとかして勝手に読んでください。
PlaceEngineより、Googleの提唱する_nomap方式のオプトアウトに準拠する旨のリリースが出た。
PlaceEngineデータベースにおける無線LANアクセスポイント(AP)情報の取り扱いについて
Google社から、Google Location Service のWi-Fi位置情報データベースから無線LANアクセスポイント情報を削除するためのオプトアウト方法（SSIDに"_nomap"文字列を追記する方法）が公開されました。
PlaceEngine サービスにおいても、Google社のオプトアウト方法に準拠する形でPlaceEngine位置推定データベースから該当するAP情報を削除する運用を実施する予定です。具体的な実施時期や運用方法については、別途お知らせします。
また、PlaceEngineサービスにおいては、以前より、主にモバイルルーターなどに対応するため、オプトアウト(削除)したいMACアドレスをサポート窓口へ送付して頂く方法などをとっておりましたが、こちらについても引き続き運用していきます。（「位置推定の改善」をご参照ください）
これこそがまさにGoogleの狙った効果だ。素早くデファクトになり得る。すると次の段階として、Wi-Fi機器の製造者が設定画面に「☑位置情報サービスからオプトアウトする(SSID末尾に_nomapを付加する)」のような項目を用意することが標準化する、などといった流れに進むことも期待できそうだ。これには一層の啓蒙活動が必要になるが、十分に現実的な範囲だ。
そして、「Wi-Fiだけの問題ではない」と書いた通り、あっさり同種の別問題が持ち上がってきた。今後、この手の問題はゴロゴロ出てくるだろう。そもそもどこまでが許される範囲でどこからが許されないのかといった大枠の議論も含め、どんどん問題にして世界中で合意やルールを形成してゆく必要がある。先は長い。
高木氏が「異常」と言っているのは、一番目の選択肢が変なURLだけになっていること。
でも決して「検索サイトが変な結果を意図的に表示させた」わけではない。
技術的にはやろうと思えばrobots.txtの記述を無視して収集できるし、
でもしない。robots.txtで「しないでください」と書いてあるから。
（昔は無視して収集する検索サイトはたまにあった。今は知らないけど）
http://takagi-hiromitsu.jp/diary/20101024.html#p01
高木氏はrobots.txtが修正されることにより、「検索サイトで正常に閲覧できる」ようになった、
と書いています。また、「/robots.txt によってすべてのクローラを排除していたため、図1の「ビフォー」のように異常な検索結果になっていた。 」とも。
検索サイトってそんなに偉いんでしょうかねぇ、と思っただけ。
どのことなのかわからないけれど、「使え」って話じゃなくて「変」って話じゃなかったっけ？
robots.txtはサイトの意思表示なんだけど、それ（意思表示）が変って事なら図書館側の問題だよね。
あと、googleにとっては岡崎市立中央図書館なんて努力する程のものではないでしょう。
図書館側がどうこうするつもりもなく、よほどの苦情もなければ、特別トップに出す必要性もないし。
そんなもんだよ。
Googleの検索結果で表示がおかしい、という指摘があり、robots.txtを使え、というような話があったと思う。
でもGoogleの検索結果の表示がおかしいのなら、それはGoogleの問題じゃないの？
Googleが実質、検索サイトの標準なのかもしれないけど、Googleの検索結果の表示でトップに表示されないのは図書館側の問題というのはおかしい気がする。
Googleのサービスは色々なサイトを探し回って何かしらの基準で順番に表示させているわけだけど、その表示順で上位に行くために、図書館のＷＥＢサービスで準備しないといけない、というのは本末転倒ではないの？
企業のＷＥＢサイトで検索結果の上位に表示されたい、という企業側の思惑はあるだろうけど、公共機関については検索サイト側が努力するべきことじゃないの？
そろってるっつーかなんつーか・・・
ログイン周りなんて、フレームワーク使わなくても、４時間かかるかどうかだよ・・・セッション周り慣れている人という前提なら。
問題なのはページ数が増えたときにすべてのページに間違いなく確実に同じ処理を入れることで
それが複数人のプログラマになっても、守られること。
そうなるとフレームワークの出番ってはなし。
あとは、それこそセッションハイジャックやらセキュリティ対策が時間がかかる。
今回問題なのは、そんな、慣れている人なら、そもそも、いわれなくても入っている。最初に入れておく一般的機能がまったくはいっていないこと。
robots.txtすらおかれていないこと。普通管理画面以下は、万一に備えて、robtos.txtを置く。という知識もないこと。
そして一番問題なのは PCソフト販売会社がその程度の、セキュリティー知識もない会社に発注するほど、セキュリティー知識がないこと。
コレだとすると、発注側にノウハウが無いので、今後も、セキュリティーの向上は見込めない。
こう言っちゃ何だが、ユーザーは訴訟を起こすべきだし、PCソフト販売会社はさっさと、別なまともな会社に頼むか、
しかしなぁ、
世の中には、パスワード一覧をEXCELファイルで作っちゃって、まちがってメールで関連先に送付しちゃって大問題っていう
それでいて、操業停止になるくらい、ユーザーが離れるわけでもないんだぜ？
そりゃぁ、セキュリティーなんて向上しないし、みんな無視するよなぁ
安かろう悪かろうで、そういう業者に発注するからそういうことになるんだが・・・
真面目にセキュリティーに取り組んでる奴がバカをみる・・・
嫌な時代だよな。
ちなみにな・・・
http://mag.wb-i.net/2010_04_02.html
対処策が・・・
１．metaタグの挿入（noindex,nofollow,noarchive）
２．USER_AGENTよるSpiderの排除
なんつーかな。
そもそも、セッション持って、外部から見られないように対策すべきであって、クロールされなきゃ良いって問題じゃないと思うんだが？
それにmetaタグよりrobots.txt使えば早いのに・・・とか、突っ込みどころ満載。
これを無しで販売したそのマインドがすばらしいし
それを購入した方のマインドもすらばらいい。
起きるべくして起きた事件としかいいようがない。
つーか、こんな初歩の初歩にひっかかるようじゃ、
真面目な攻撃食らったら簡単に個人情報吐き出しそうだな・・・このプログラム。
SQLインジェクションに感染したりして・・・ｗ
をぉ！ こんなところに（笑）
http://www.google.com/robots.txt
User-agent: Kids Disallow: /tricks Allow: /treats
