2006年07月25日

掲示板SPAM戦記ふたたび

すっげー久しぶりにここ書きます、Jackです。

今日は会社が休みなのですが、昼過ぎに起きて掲示板見たら、SPAMの大量爆撃くらって一ページ目から人間の書き込みが完全に追い出されている事態に遭遇しました。

さすがにちょっと頭に来たので、久しぶりに対策取りました。

今回採用したのは
「入力してはいけないフィールドを用意する」
という一見よくわかんない方法です。

掲示板を開くと、入力フォームの下のほうに「ここは入力しないでください」というテキストフィールドがあります。ここに入力されると投稿を受け付けません。

そして、ソースを見るとわかりますが、このフィールドの名前が「mail」になってるんですね。動的にフォームを解析したSPAMエンジン(っていうのか?)は、ここをメールアドレス入力欄だと解釈して値を設定するわけです。本物のメールアドレス入力欄はぐちゃぐちゃな文字列で名前つけてます。

たぶん、こいつでまた当分は平和になれます。

これで実に4通りものチェック処理が追加されてしまいました

A.パラメータが不正なもの
うちの掲示板の元になったスクリプトの入力パラメータを固定的に投げてくるものに対応する。

B.大量のURLを含むもの
6個以上に設定、数百以上URLを含んだ書き込みがよくあるので、これがないと掲示板が使い物にならなかった。

C.タイトルなし、または「None」の禁止
たまたま多かったタイプにこういう書き込みがあったからで、これが一番その場しのぎな対処だったかも、けっこう効果はあったけど。

D.入力禁止フィールド(偽メール入力欄)の追加
今回やった奴です、本当はこのチェックだけでABCのほとんど全てをカバーできるはずですが、なんとなくタイプ別にログとっているので、他のチェックも残して、このチェックを一番最後に回しています。

ちなみに、今さっきDの対策を行ってから、この記事を書いている間にもうタイプA、B、Dそれぞれに一件ずつ引っかかっています。

・・・これじゃ、掲示板なんてもう、まともに使えないんじゃないだろうか・・・最近はメールも、以前のようにメールアドレス公開するとまともに使えない(週に数回だけ家に帰る私は帰るたびに数百通のSPAMを受信するハメになる、いくらフィルタがあっても苦痛だ)し、なんていうか、ネットワークはSPAMに押し潰されつつあるような、そんな気がしてならない。

まあ、もうしばらくたったらログ集計してそれぞれの件数でも数えてみたりするかー。
posted by Jack at 16:09| Comment(4) | TrackBack(0) | Web系 | 更新情報をチェックする

2006年05月21日

【開発室】嫌な予感がする・・・

久しぶりに開発室からの投稿です。

サイトのトップページとかから見て違うブログに飛ぶと驚かれそうなのでタイトルに開発室と明記しておきました。

しかし、最近色々不可解なことが起こってるんですよね・・・
いや、怪奇現象とかじゃないよ

うちの掲示板、なんかspam系な書き込みですぐいっぱいになります。
まあ、これは以前から続いていたことです。

ところが・・・今度はなんと、作品の感想にspam書き込みが来るんですよ!
そんなバカな・・・
何故これがバカな、と驚くことになるのか説明しよう。これまで私は以下のような推測で掲示板にspam書き込みが届くものだと思っていた。

1.spam書き込みは自動化されたプログラムによって行われているはず。

2.自動化できるのは、うちの掲示板プログラムがネット上で沢山使われているフリーウェアで、仕様が広く知れ渡っており、この掲示板に対応するだけでネット上の多くの掲示板に対応できる。つまり、対応するコストに結果が見合うからである。

3.そして掲示板spamプログラムはネット上を同じプログラムの掲示板を求めてさまよい歩き、見つけたものに対して書き込みを自動的に行う。

ところが今回、Jack's Roomの感想にspam書き込みが入ったのだ。

うちの感想のプログラムは私がうちのサイトのためだけに書いた「一品モノ」である。

一品モノのプログラムに対して、個別に書き込み機能を実装していては手間がかかりすぎるので、まずそんなことはしないだろう。

一品モノに対応する簡単な方法として、人力で書き込むことが考えられる。ふつうに人力でうちのサイトにたどり着いて書き込む限りは未知のプログラムであろうと関係ない、ただ入力項目を手で埋めて書き込むだけだ。

ただし、人力はコストがかさむし、書き込まれた結果がうまく表示できていないことからも人力による書き込みではないと思われる。

すると、考えられる方法がもうひとつ。

htmlを読み込んで、内容を解析してあてずっぽうにデータを送信しているのではないか?

プログラムがhtmlを解析したところで、それが掲示板のようなプログラムの入力画面なのか、なにかのメール送信フォームなのか、検索条件の入力なのか、完全には解らない。でも、なんとなくで判断して当てずっぽうに書き込んでしまうのなら、ある程度まで推測できるだろう。

フォーム中にテキストエリアが存在するなら、多分そこが本文であり、そこに宣伝文を書き込めば画面にもっとも効率的に表示されることが推測される。

その他の入力項目は必須チェックにひっかかる場合があるのでとにかく何かを入力してやれば、大抵は突破できるだろう。

さらに、フォームのソースからhiddenで送信されている値を読み出して同じように送信してやれば、大抵のcgiプログラムは正常動作するだろう。ただし、正常動作したところで、意図した宣伝効果が得られる確証はない。確証がなくても、1%でも意図した結果が得られれば、広大なネットの全体に放たれたspam書き込みプログラムは膨大な数の宣伝を実現することができるはずだ。

こんなやり方が広まってしまうと、ネット上のcgiなんてもうほとんど使いものにならない気がする。

ネット上で、自由に書き込めるプログラムがあればなんでも勝手に書き込まれてしまうし、掲示板のようなものではなくて、何かの処理を行うようなプログラムがあれば、それらは意図しないタイミングで起動される恐れがある(そんなケースがあればセキュリティ的によろしくないけれども)。

ユーザー認証とか、画面上に画像で文字を表示して「この内容を入力してね」なんて操作をユーザーにさせることによって、この手の書き込みを防ぐ技術があるが、それはユーザーに負担を強いることであり、ある意味spamに敗北していると言えなくもない。

今来ているようなものであれば、どうにかユーザーに負担をかけずに対策できなくもない。しかし、段々エスカレートするにつれて、私は暗澹たる気分になってくる。

ネットワークの未来は一体どうなるんだろう。
誰にでも開放されていて、誰でも発信できる時代は一時的なもので、もしかしてもうそろそろ終わってしまうのだろうか。そこまで考えるのは考えすぎだろうか?でも私は考えてしまう・・・
posted by Jack at 18:06| Comment(2) | TrackBack(0) | Web系 | 更新情報をチェックする

2006年01月06日

さて、一日経過してどうなったか?

昨日の掲示板SPAM対策のログを調べてみた。
やっぱり、俺を一番悩ませていた「色んなURLを大量書き込みしてくるやつ」が4件ほど釣れました。全てがURL書き込み件数のチェックで引っかかってます。

URLの書き込み件数超過チェックに引っかかるってことは、もう一つ仕掛けた「パラメータの変更」は突破しているということで、まさか人力か、そうでなければHTMLのフォームをわざわざ解析して送信している(解析したって限界があるから、これをわざわざやるとは考えにくい)可能性がある。

具体的に変更したパラメータというのは、うちの掲示板に使っているyy-boardの「mode」というパラメータの値である。
この手の掲示板cgiというのは、ひとつのcgiで記事閲覧から書き込み、さらには記事削除と様々な処理を行うケースが多いので、この「mode」のように何らかの形で処理モードを渡して処理を切り替えているものが多い。今回やったのは、書き込み時に設定される処理モード「regist」を別の文字列に書き換え、それまでの「regist」では書き込みが行われないようにした、という対処方法である。

ほとんどの場合の書き込み自動化プログラムは相手のCGIの仕組みに合わせて固定的に作られる(はず)ので、yy-boardが相手なら書き込み時には「mode=regist」の値を送信するように作るはずである。これでネット上にあるyy-boardのほとんど全てには書き込めるはずで、今回のSpammerのような悪意のあるプログラムでなく、単純に掲示板のビューアとして動作するソフトウェアなんかも存在する。

この固定的なアプローチが通用しない場合、書き込みの自動化は非常に難しい。HTMLで書かれたフォームの意味を動的に解釈することなど(あてずっぽうでもなければ)不可能だからだ。

厳密に言えば、今回変更したのは「mode」というパラメータ名ではなく「mode=regist」として表現される「regist」という値だ、という点が対策としては若干手抜きと言える、yy-boardというプログラムのルールにおいては「mode」は処理モードなので、正規の投稿フォーム画面を読めば書き込み画面が「mode」に何を設定しているかはある程度は解釈可能である。

しかしそんなことをやるメリットが思いつかない、そんな乱暴な対策を取るサイトがそんなにたくさんあるとは思えないからだ。となると他にこの対策を突破する方法は「人力書き込み」という最強の方法がある、制限しきれない様々なIPアドレスからアクセスされれば正規ユーザとなんの区別もつけられないからこのレベルでは対策しようがない。

でも、それはふつーに考えてやらないよな・・・
そりゃ、物価の安いどこかの国ならn件で10円とかでも喜んでやる人達がいるかも・・・とか恐い想像もできなくはないけど、それは恐いから想像したくない(笑)

というわけで、一体どうしてあの対策を突破してくるのかいまいち解らないのだが、突破してくるやつに対してはURL書き込み件数のチェックで弾けているので当面は問題ない。パラメータの変更によって弾いた例は現段階ではまだログに出ていないが、これも近いうちに出てくるんじゃないかなーと思う。

ところで、今回探してみたら、SPAM対策済みの掲示板スクリプトっていくつか配布されてました。これ使えばよかったのかな(笑)

いちお、前のバージョンの掲示板が独自に改造してたこともあって、その改造コードを移植するよりはと思って自力で対策したんですけれど、先日掲示板を新しいバージョンにした時にどのみち改造コードの移植はやってしまったので、これははっきり言って無駄にコードを書いてしまったということになる。プログラマとしてはあまり感心できないことである。

書く前にちゃんと探しましょう(笑)
posted by Jack at 01:24| Comment(2) | TrackBack(0) | Web系 | 更新情報をチェックする

2006年01月04日

掲示板SPAM対策まだ完結してなかった編

さてさて、掲示板SPAM対策、色々やってたんですが、今日掲示板を見て愕然としました。

なんか、多種多様なURLがどっさり書いてある。

50件以上は書いてあっただろうか、これじゃ他の記事が読めないし・・・
これだけ多種多様にURLを書かれてしまうと、書き込み禁止ワードにどのURLを設定していいものやら解らないし、設定したところでまた新しいパターンが登場すればそれまでです。

さあ困った、どうする?

そこで今回は、本文中に書き込まれるURLの件数を制限するチェックを追加しました。URLが6件以上検出されるとエラーを返して書き込みを止めます。
相手が人力かつやる気まんまんな相手の場合、ひとつの書き込みを5件以内に分割して大量書き込みなんてこともあるかもしれませんが、恐らくそこまではやらないでしょう。

また、最近2chみたいにttp://でURLを書いていくタイプもあったので、ttp://の場合もばっちり捕まえます。

それから、大量にURLを書くわけではなく、一件か二件くらいしか書かない代わりにエロ宣伝文句満載のSPAM書き込みも最近増えてきてます。こいつが手動なのか自動なのかは解らないですけど、手動書き込みのパターンがあったとしても必ず自動で書き込んでくる奴もいるはずなので、先日のバージョンアップした時に元に戻っちゃってた、フォームパラメータ名の変更も再度やってみました。

同じCGIスクリプトを狙って自動化された書き込みの場合は、これですっかり止められるはずです。

また、今回、それぞれのチェックに対して、実際にチェック処理にひっかかってエラーを返した際にログを記録するようにしました。これで、実際に効果があったのかも含めて把握できるはずです。その報告もここのブログでやっていきたいと思います。

ある程度効果が上がったら、掲示板SPAM対策まとめサイトでも作りましょうか。プログラムを直接改造するタイプの対策を挙げているサイトはあまりなかったようなので、これはこれで意味があるかもしれませんね。
posted by Jack at 23:51| Comment(0) | TrackBack(0) | Web系 | 更新情報をチェックする

2005年12月29日

掲示板SPAM対策完結編

結局、掲示板CGIを新しいバージョンに変えて(ちょっと機能追加してたから大変だったけど)、そいつについてた「禁止ワード検出機能」を使って宣伝されるURLを禁止して対策完了としました。

禁止ワードに追加しなきゃいけないと対応が常に後手に回ってしまう危険はありますが、相手は宣伝するURLが書けなきゃ意味がないので、まあ対策としては有効です。

ついでにソースを眺めてみたら各種いたずらに対する対策も強化されていたようなので、まあよかったかなと。

ひとまずこれで対策完了とします。
posted by Jack at 05:35| Comment(0) | TrackBack(0) | Web系 | 更新情報をチェックする

2005年11月30日

掲示板SPAM対策・・・になるのだろうか

最近本家サイトの掲示板がうるさいのです。
三時間間隔くらいで広告書き込みが来まくるんです。

色んなIPアドレスから来てるのでアクセス制限もし辛いし。

なんか対策ないかなーと思って調べてみても「警告の文章を書いておく」とか無意味そうな対策が書いてあったりしていまいち求めるものに出会えませんでした。

アクセスログを見ると・・・

1.目的の掲示板にアクセスする
2.書き込みを行う(1のReferrerをつけて)

という順序になっている、警告書いておくって対策が出てたり、1の手順が含まれていることを考えるとまさか人力か?とも考えてしまうが、やはりこれは自動化されたプログラムによる投稿だろうと思うので、CGIに細工してみた。

フォームから送ってくるパラメータ名をちょっと変えてしまっただけなんだけどね。

使っているのが沢山出回ってるフリーウェアの掲示板だから、それに合わせた内容を書き込んでいると思う、であれば、それを変更してしまえば、プログラムからは正しい書き込みができなくなるはず。

で、掲示板の本来のユーザーは画面のフォームに従って投稿してるわけだから、影響は受けない。一部、Web上の掲示板を巡回するツールもあるけど、うちの掲示板でそんなの使う奴もいないだろうからそれらは放置です。変更内容を公開すれば設定で対応することもできるだろうけど、それもめんどくさいので要望がない限りはやりません。

とりあえず、人力でなければこれで対策できるはずなのです。
昨日の夜に対策して、今朝までとりあえずSPAM書き込みはありません。

ただ、ネット上を調べてみると、書き込み中にURLが含まれていたら弾いてしまえ、とか、どうも人力を意識して対策してるような例がいくつか見受けられるのでなんか不安です(笑)

人力だと本来のユーザーの書き込みと完全に区別するのって不可能に近いしね・・・本来のユーザーにはちゃんと書き込みできる環境を提供しないといけないから、区別ができなくなったらそこでアウトなわけです。まさかそんなことはないと思うけどな(笑)

人力ならあんな寂しい掲示板に書くのは労力の無駄だと思う(笑)

でも、パラメータの変更なんて誰でもすぐ思いつきそうな手段が他に見つからなかったって事実が俺をちょっと不安にさせてるのです。まあ、今日一日様子を見てみよう。
posted by Jack at 08:32| Comment(5) | TrackBack(0) | Web系 | 更新情報をチェックする

2005年09月19日

トラブル覚え書き

いやぁ、チャットに取り付けたAjaxもどきな参加者カウント機能、うっかりしてIEでのテストしてなかったよ(笑)

IEでやったら二回目以降が動いてないでやんの(笑)

詳しく調べなかったけど・・・なんだろ、キャッシュでも参照してるのか、リクエストの呼び出し自体は成功しててもサーバに呼び出しが来てなかった。

対応策も詳しく調べてないんだけど、メソッドをGETからPOSTにして、なおかつ今までnullを渡してたsendに対しててきとーに文字列投げたら無事に継続して動くようになった。

これ、人によってはハマっちゃいそうなトラブルだから、ここに書いておく意味はあるかもね。

ついでに、サーバへの呼び出し間隔を3分からさらに広げて10分にしときました。onunloadによる参加取り消しの通知に失敗すると、最大で10分間幽霊が残ることになりますが、そんなに沢山人が来るサイトじゃないから10分なんてどうでもいい数字です(笑)
posted by Jack at 02:52| Comment(0) | TrackBack(0) | Web系 | 更新情報をチェックする

2005年09月18日

でも、よく考えてみると・・・

さて、そういうわけで前の記事の後ろで心配していたCGIの呼び出し間隔をさらに広げて3分間隔にしてみました、まあ、大した差はないですがこのくらいなら参加人数の少ないうちのサイトではまったく問題ないレベルです。

でもさ、ちょっと考えてみたのですよ。

今回はAjaxと呼ぶにはあまりにも中途半端なプログラムなのでサーバー側へのリクエスト送信の回数がだいぶ少ないですが、普通にAjaxっていうと、もっと頻繁にサーバにリクエスト投げるほうが多いんじゃないかと思います。Google Mapsなんてレスポンスの容量も半端じゃないレベルだよね。

いや、もちろんそんなに頻繁に投げなくてももっとゆったりしたAjaxというのもありえるとは思いますけれど。

恐らくはサーバへの負荷を考えてのことですが、私の使っているレンタルサーバではウェブチャットの設置が禁止されています。

でも、Ajaxって使い方によってはウェブチャットをはるかに超える高負荷になるだろうことは想像に難くないですよね。

やがてはAjax禁止を明記したレンタルサーバってのも出てくるのかなぁ、とちょっと思った。
posted by Jack at 14:17| Comment(0) | TrackBack(0) | Web系 | 更新情報をチェックする

Ajaxの応用?

うちのサイトのチャットをちょこっと改造してみました。
とはいうものの、チャット自体はレンタルのJavaアプレットなので、あのプログラム自体は俺が直接手を入れることはできません。

そこで、あのチャットの置いてあるhtmlファイルの方に細工したわけです。
詳しくはソースを見てしまえばわかりますが、あのファイルを読み込むとonloadイベントでXMLHttpRequestを使用して、うちのサーバ上のCGIを呼び出します。
CGIは単純に、呼び出された時間とIPアドレスをファイルに記録します。そのときファイル中に記録されたレコードの中で、一定時間(今のところ130秒)を過ぎたレコードがあれば削除されます。
また、onloadイベントのイベントハンドラではsetTimeoutを使って一定時間(今のところこっちは120秒)ごとに同じCGIを呼び出します。

ウェブチャットなんかでよくある、入室者の管理ですね。
ただ、入退室を検出できるのはアプレットのみなので、入室していないROMのメンバーも同じようにカウントせざるを得ません。それでも、トップページを見ただけで、今チャットを見てる人がいるってことがわかれば、チャットに入ってみようかなって気にもなりやすいでしょ?

JavaScriptが動かない環境とかでは動作しないわけですが、元々この手のプログラムはそんなに精度が高い必要はないので気にする必要はありません。

そして、サイトのトップページではSSIを使って、ファイルに記録されたIPアドレスの中から一定時間(書き込みの時と同じ130秒)を経過していないものの数をカウントして、現在の参加人数としてトップページに表示します。

ついでにonunloadイベントも捕まえて、こっちでもやっぱりXMLHttpRequestを使用します。こっちでは自分のIPアドレスが記録されていれば即座に削除、ということをやって、退室者の処理とします。

まあ、unloadが取れるなら定期的にCGIを呼び出し続ける必要なんてないのでは?とも思うわけですが、手元のFirefoxでは他のページに遷移させる場合はonunloadが動いたものの、ブラウザを閉じる場合には動かないことがあるようでした。

onunloadが動作し損ねると、ずっと参加者がいるまんま、ということになってしまいます。

それではまずいので一定時間を経過した参加者を除外するわけですが、除外するのなら定期的に参加を確認しなければいけません、このあたりの考え方自体は昔からウェブチャットでやっている考え方と一緒ですね、必ず退室ボタンが押されるとは限らないので定期的に入室者を管理しなければならない、という。ウェブチャットの場合はログのリロードがあるのでそこに混ぜ込めば済んでしまいますが。うちのシステムではチャット本体は別のプログラムなので入室者管理専用にプログラムを呼び出さなければならないという。そういう話です。

というわけで、今回初めてXMLHttpReauestを使ってみました。

レスポンスの処理すらしていないので、これをAjaxと呼ぶのは無理があるでしょう。実際にはAjax(Asynchronous JavaScript and XML)といってもXMLを使用しないケースは多いようですが、レスポンスをまったく処理しないというのはさすがに違う気がします。

でも、とりあえずリクエストの送信自体は実に簡単に楽しく作れましたよ。

今回の機能、問題としてはウェブチャットと同じように定期的にリクエストを飛ばさなければいけないのでサーバの負荷が心配になりますが、ウェブチャットのようにログを取得したりしているわけではないので、転送量的には多少マシだと思います。さらには、参加者数を把握するだけなのでそんなに短時間に頻繁にリクエストを飛ばす必要もなく、現在設定した120秒ってのは標準的なウェブチャットのリロード(30秒くらい)の4分の1の頻度ですから、まあマシだとは思います。

とはいえ、ほとんどの場合onunloadで退室を検出できるならば、呼び出しの間隔はもっと長くてもいいかもしれないと、これを書きながら思いました(笑)

んー・・・あとでもうちょっと長くしときます(笑)
posted by Jack at 14:06| Comment(0) | TrackBack(0) | Web系 | 更新情報をチェックする

2005年09月01日

RSSでもっと遊べないか?

職場のメーラーをEdMaxからThunderbirdに変えてみた。データの移行方法とかまた後で記事まとめます。

で、Thunderbirdって、RSSリーダも兼ねてるんですね。

んでもって、友達のブログを試しに読み込んで眺めてみてたら、ちょっと思いついた。

Jack's Roomの作品のRSSとか作ったら面白いだろうか?

という話である。

Thunderbirdその他のRSSリーダで詩が読めるってのは別にそんなに必要なことではないかもしれないけど。例えばRSSを生成できる詩の投稿システムを作成して配布してみて、mixi用に使ったRNAを組み合わせてみると、複数サイトに投稿された詩をまとめて読むことができたりしそうだ。

もっとも、詩の一個一個を全部配信してるとかなりなサイズになりそうなのが問題ではある。

でも複数サイトによる連携って一度は挑戦してみたいんだよねぇ、最近すっかり止まってしまっている新システム開発計画「j2プロジェクト」ですが、再開の時にちょっと、RSSについてまじめに検討してみようと思いますです。
posted by Jack at 00:47| Comment(0) | TrackBack(0) | Web系 | 更新情報をチェックする

2005年08月13日

Ajax解説ページ

そんなわけで、先日以来すっかりAjaxが気になってるJackです。

Ajax解説ページ

なんか、キャラクターがいるなぁと思ったらこの解説自体がAjaxなのね。
もちろん、これならどうしてもAjaxじゃなきゃ・・・ってことはないように見えるけど、でも解説としてはそれなりわかりやすかった。

面白そうだけど、遊んでみたいけど、まだj2システム(Jack's Roomの新しいシステム)の開発も途中だしなあ、まさか詩の読み込みをAjaxにしてもあまり意味がないしなぁ。作者リストとかはちょっと面白いかも、入力内容に併せてその場で検索して作者を絞り込む。Google suggestみたいな感じっぽい。

でも、うちみたいなレンタルサーバでそんなにリクエスト投げまくっていいんだろうかちょっと心配なので、実現の可能性は低い(笑)
posted by Jack at 19:51| Comment(1) | TrackBack(0) | Web系 | 更新情報をチェックする

2005年08月12日

Ajax Full IME

スラッシュドットの記事で見かけたAjax を使った日本語 Full IMEなるもの。

すげえ、ここまでやっちゃうのか。

Ajaxって最近気になるキーワードではあるし、面白そうなんだけど俺的には使う機会がなくってとりあえず見守ってる状況です。しかしこんなことまでやってくる人がいると刺激を受けずにはいられない、なんかやってみたいなぁ。

でも、今のJack's RoomにAjaxが必要なものなんてどこにもないんだよな。暇になったらなんか作って遊んでみようかなぁ・・・
posted by Jack at 10:31| Comment(0) | TrackBack(0) | Web系 | 更新情報をチェックする

2005年07月31日

RNAのまとめ

さて、昨日今日と試してきたRSSアンテナ「RNA」について簡単にまとめ。

1.インストールはファイルを展開して配置して、設定ファイルをちょろっと書き換えるだけ、あとは初回に実行するcgiプログラムがあるけど、これはシェルから叩いてしまってもok、とってもかんたん♪
このへんの手順に関してもきっちりドキュメントがあるので迷うことはないはずですが、簡単ですよって書いとけばここ読んで使う人もいるかなぁと(笑)

2.巡回するサイト(のRSS)の指定は設定用にCGIが用意されてるので全部ブラウザから設定できます。
ただ、初期状態で既にいくつかのRSSが指定されているので、それは削除しとかないとそっちの記事も混じってしまいます。

3.crontabによる定期巡回の設定方法もドキュメント(バージョン1.9以降のもの)の下のほうに書いてあります。テストしていないとは書いていますが、きっちり動きました。

4.JavaScriptの貼り込みによって他サイトからRNAで取ってきたRSSの中身(HTML化されてきます)を取り込むことができる、まだうちのサイトでは使っていないけど、使ったらこの記事に追記します。

と、全体としてとっても簡単、実にすんなりと当初の目的であった「複数のRSSのマージ」ができました。こういうことをしたい人ってどれだけいるのか俺にはちょっと需要がわからないけど、やりたい人には実に便利です。

で、今回対mixi用RSSにRNAを使用するってアイディアは↓のサイトさんで見つけました。

http://www.add-info.com/mt/archives/000726.php

ありがとうございました。
posted by Jack at 17:34| Comment(2) | TrackBack(0) | Web系 | 更新情報をチェックする

RNA設定完了

さて、RNAの設定完了、cronからとりあえず一時間毎に実行としておきました。

このエントリがmixiから読めれば大成功なわけですが、mixiがRSSを読むタイミングというのが、4時間に一度だそうで、つまりすぐには結果は判明しないわけです。

というわけで朝まで待っていた結果、どうやら無事に反映されたようです(笑)
うん、RNA、使い方簡単で便利だわ。

本家blogの右側にある、Jack's Roomの人々リンクなんかも、こいつ使ってblogそのものへのリンクじゃなくてみんなの新着記事へのリンクにできないかなぁ。というのも、せっかくリンクから飛んでもう何ヶ月も更新されてないblogに当たるってのもイヤだと思うんです。だったら最初から新着記事リンクにしてしまえば問題解決かなーと思う。

うん、調べてみるとそういう使い方も簡単にできそう。
JavaScriptを仕込んでRNAの生成したリストを表示する方法が用意されているし、表示形式もきっちりとテンプレート化されているのでしっかりカスタマイズできそうだ。そんで、適度にカスタマイズしてあげればblogに仕込むリストを作る分には充分っぽい。
これについては近いうちにやってみるとして・・・そろそろ寝るか、さすがに・・・
posted by Jack at 06:18| Comment(3) | TrackBack(0) | Web系 | 更新情報をチェックする

さあ、このブログの開設準備

さて、当初の予定(本家blogでだいぶ前に予告した)よりだいぶ遅れてスタートしたプログラマ向けblog「Jack's Room開発室」だが、何故遅れたか、実はこのblogの開始のために俺的に必要な技術的要件があって、それの解決が遅れた・・・いや時間がかかっていたのではないけど、それに時間を割く余裕がなかったのである。

その要件とは「本家blogとのRSSの統合」なんです。

というのも、そうしないとmixi日記にこのblogの記事情報が渡せない(mixiはRSSを定期的に読み込んでます)んです。でも、このblogの記事を読んでくれそうな人はJack's Roomのお客さんよりもmixiの友人達に多いのです。

かといって、mixiに設定する日記をこっちのblogオンリーにしてしまうと、こっちのblogは本家blogと違ってそう毎日書けるものでもないので、mixi側の友人達にコンテンツを提供できる機会をそれだけ損失してしまうことになります。

なので、二つのblogのRSSを統合っつーかマージして、mixiに対して二つのblogの記事が紹介されるようにしたかったわけです。

そのために今回使ってみたのがRSSベースのアンテナこと「RNA」、こいつを使えばどうにか目的が達成できそうです。

実はこの記事は、RNAの実験をするために書かれています。
mixi側の友人の方々、この記事をmixiから辿れたら、私の実験が成功したものと判断してください。

では、これからのんびり更新していきますが、よろしくお願いします。
posted by Jack at 02:05| Comment(1) | TrackBack(0) | Web系 | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は180日以上新しい記事の投稿がないブログに表示されております。