またも、Webサーバ内部の改造です。

　工房では、工房にアップされているすべての画像への直リンクを禁止しています。

　具体的には、「.htaccess」に、以下のように記述しています。

　「Referer」の値をチェックして、Refererがセットされていない場合（＝直リンクされている場合）、または工房のドメイン以外の場合（＝自分のページに勝手に表示している場合）には、アクセスさせないようにしています。

＃こうすると、セキュリティーソフトを入れていて、Refererを出力しないような設定をしている場合には、画像が表示されなくなってしまいますが、まぁ、そういうヒトは、そういうヒトということで。

　ただし、その一方で、Googleなどの画像検索クローラーがやってきた場合には、アクセスさせたい訳です。

　上記のように、ホスト名を指定して許可すればいいのですが、Googleのようなクローラーであっても、ホスト名が得られず、IPアドレスしか分からない場合があります。

　このような場合、そのIPアドレス毎に許可してやればいい訳ですが、クローラーのIPアドレスは、アクセスの度にコロコロ変わることがほとんどです。

　そこで、クローラーのIPアドレスを含むサブネット全体を、丸ごと許可してやることにします。

＃ちょうど、スパム対策の逆の手法ですね。

　では、どのようにクローラーのIPアドレスを取得するかというと、.htaccessに、以下のように設定します。

　これは、HTTPのステータスコードに基づき、クライアントエラーが発生した場合には、“error.phpを呼び出す”という設定になります。

　1行目は、エラーコード403（Forbidden）で、リソースへのアクセスを拒否された場合に、2行目は、エラーコード404（Not Found）で、リソースが見つからなかった場合に、それぞれerror.phpを呼び出すことになります。

　これを受けて、error.phpでは、以下のようなHTMLを出力します。

　あたかも、Apacheとまったく同じ挙動をするように偽装していますが、実は、裏ではしっかりアクセスログを取っています。

　以下、そのソース（一部）です。

　このスクリプトによって集められたIPアドレスを逆引きし、Googleなどのクローラーであった場合には、そのサブネットを得て、アクセス許可リストに追加していきます。

　逆に、直リンクしたり、自分のページに勝手に表示したりしている場合には、アクセス拒否リストに追加していきます。

　また、ある一定時間以内に、ある一定回数以上のアクセスがあった場合には、Webサーバへのアタックと見なして、アクセス拒否リストに追加したりできます。

　実際のエラーログの一部です。

　IPアドレスを逆引きすると、Googleが取得したサブネットからのアクセスであることが分かります。

　これらより、.haccessには、上記のように設定しました。

　このように、HTTPのステータスコードを取り込み、エラーログを解析することにより、「クローラーには優しく、不届きなヤカラには厳しい」対処を取ることができます。

　今日も、湾岸道路がヒュンヒュンうるさいと思ったら、

　5シリーズ（E39）のM-Sportが、インターセプトされてました。0xF9D0

　その横を、7シリーズとX3が、“駆け抜けて”いきます。

　気持ちよく飛ばせる湾岸道路などは、くれぐれも気を付けましょう。

　雨上がり、羽田空港方向には、きれいな虹が。0xF9CF

　藤本壱さんが開発された、「ブログに記事を書いたことをFacebookに投稿するプラグイン」を導入し、改造してみましたので、ご紹介します。

　オリジナルのプラグインの導入方法は、こちらまたはこちら（小粋空間さん）をご覧ください。

　このプラグインは非常に有効で、MovableTypeにブログの記事（またはウェブページ）を投稿すると、自動的にFacebookのウォールにアップしてくれます。

　自動投稿されたイメージは、上記のようになります。

　とても便利なプラグインなのですが、Facebookに投稿される画像は、プラグインの設定時に指定した、固定的なものとなります。

　記事の内容によっては、その記事に関連する画像を設定して、ウォールにアップしたい場合があります。

　ということで、さっそく改造してみました。0xF9F8

　ファイルを所定のフォルダにアップし、最初に管理画面にアクセスすると、上記のようなメッセージが表示されるので、「アップグレード開始」を押下します。

　アップグレード（データベースの設定変更）が正常に終了すると、上記のようなメッセージが表示されます。

　ブログ記事の新規編集画面を開くと、右下に、上記のような項目が追加されています。サムネイル画像のURLを設定できるようになっています。

　サムネイル画像の初期値は、プラグインの設定時に指定したものが、そのまま入っています。

　過去に投稿した記事についても、編集画面を開き、「Facebookに公開」のチェックボックスを入れて再投稿すれば、その時点でウォールにアップしてくれます。

　改造後のイメージは、上記のようになります。

　記事に応じて画像を変えることで、一目でその記事の内容を推定することができ、訴求力をアップすることができます。

　以下、改造のポイントです。

　まずは、「config.yaml」の変更点です。

　サムネイル画像のURLを格納するフィールドを、「fb_thumbnail」とします。

　このフィールドを、ブログの記事（mt_entry）毎に紐付けるため、上記、4行目のように宣言します。

　ここで、fb_thumbnailには、「meta」という属性を設定しています。

　これは、過去のすべての記事（mt_entry）にfb_thumbnailを確保するのではなく、プラグインを導入した以降に投稿した記事（または、必要に応じて編集した過去の記事）に対してのみ、fb_thumbnailを確保するようにするためです。
（内部的には、「mt_entry_meta」にfb_thumbnailが追加されます）

　つづいて、「Plugin.pm」の変更点（一部）です。

　記事の編集画面で呼び出される関数（edit_entry）です。

　サムネイル画像のURLを設定するため、<input>タグを追加しています。

　ブログ記事を新規編集する場合には、変数「$fb_thumbnail」に、プラグインの設定時に指定した値を代入し、これをデフォルト値としています。

　過去に投稿した記事を編集する場合には、デフォルト値は同じですが、mt_entryのmetaフィールド「fb_thumbnail」に値が格納されていた場合（＝過去に編集した際に設定していた場合）には、$fb_thumbnailにその値を代入しています。

　今回は<input>タグを使って、サムネイル画像のURLを直接設定するようにしましたが、同じ編集画面内の「ブログ記事アイテム」から、その記事に紐付けられた画像をドラッグ＆ドロップできるようにすれば、もう少し便利になるかと思います。

　が、とりあえずは、基本機能の実装ということで・・・。0xF9C7

　これまで、MTと連携する外部関数は、いくつか書いてきましたが、MTのプラグインを作成するのは、初めての挑戦でした。著名な藤本壱さんが書かれたソースを解析してみて、とても勉強になりました。