前に似たような名前のエントリ書いたのは、もう１年以上前のような気がするのだけれど、
今回は2ch側の対策がキッチリされている印象。

今朝の5:00～6:20位に一時的に書きこみできていたようだけれど、
その後、すぐにBBQされたようだ。
ログを見ると、かなりのIPが新規にBBQされているのがわかる。

対策コードを書くのはそんなに難しいことでもなかったので、
今まで対策されてなかったのは何らかの理由があると思っていたのだけれど、
なにかしらの状況の変化があったということか。

臨時用2ch串は、今話題になっている2ch経由でウィルス入りのフリーソフトを掴まされるのと、
基本的には同じ手法で2chに書きこみしてたので、その絡みがあったのかもしれない。

まぁ、あれこれ邪推しても書き込めるようになるわけでもないので、
臨時用2ch串を存続させるには新しい手法を考える必要があるのだけれど。

臨時用2ch串は基本的にブラウザでアクセスしてスレを見るはずなので、
多少なりとも利便性を上げるために、レス番にマウスオーバーさせると
レスの内容がみられるポップアップをJavaScriptで実装しているのだけれど、
どうも、IEのエンジンを使ってるとポップアップが動かない状態になってたっぽい。

作ったときは動いてたはずなのでいつ頃からそうなっていたのかは知らんけど。
という訳で、本番のスクリプトにalert() 文埋め込んで実行するという暴挙に出た。
結局、原因がわかるまでに午前中いっぱい使ったので、
その間ユーザーは意味不明なメッセージボックスにさぞ迷惑しただろう。

帰宅してから、IEのバージョン判定が間違っていたのに気が付いたので再度修正。
とりあえず、これで治った……と思う。

この機能についてはコメント来たこともないので、
どのくらいの影響があるかさっぱりわからないのだけれど。
苦情もないってことは、需要もないって事だよなぁ……

まぁ、自己満足にはなったので良しとする

最近、臨時用2ch串で頻繁に忍法帖の水遁祭りが起こっているので、
臨時用2ch串で使用する忍法帖の数を減らしてみた。

2chでは、１つのIPに対する時間あたりの忍法帖の最大個数が決まっていて、
それを超える数の忍法帖の作成要求が来た場合、そのIPに関連付けられた忍法帖は
全部、水遁されてしまうのだそうな。

臨時用2ch串は書き込みを他所のプロクシに依存している関係上、
そのプロクシを臨時用2ch串以外の誰かが使うこともありえるわけで、
臨時用2ch串だけで2chの制限値に近い数の忍法帖を持つと、
同じプロクシを使う誰かが忍法帖を使用すると、全員水遁になってしまう。

臨時用2ch串でのプロクシ取得はそれほど特別なことをやってるわけではないので、
取得元が同じであれば、そりゃ、使うプロクシもダブる訳で。

元々、書き込み頻度が多すぎて、中々書き込めない状態になっていたのを
緩和する為に忍法帖を複数作って分散させるようにしたのだけれど、
頻繁に忍法帖が水遁されてしまうと、結局Lv制限で待ち時間が長くなり、
効果が無くなってしまう。

７月に入ってからは、数日に一度は水遁されていたので、
せめて、月一位になってくれないかな。と期待してみる。

本質的には問題の解決になっていないのだけれど、
後は本当にIPを複数持つ位しか解決の方法はない。

プロクシが見つけられている間は、忍法帖を作りなおせば書き込めるので、
個人的には、それほど困っていないので対応する気もあんまりないというのが
真相だったりする。

今回は臨時用2ch串の話。

海外のプロクシを利用してる臨時用2ch串が言えた義理ではないのだけれど、
犯罪予告とかあった時に面倒が起きると嫌なので、プロクシ経由っぽいアクセスは
基本的には弾くようにしている。

ある程度ログを見てると、書き込み傾向とリモートホストで常連さんは識別できるので、
同種の書き込みでリモートホストが違ってたりすると、怪しさ倍増。

これが、日本のホストなら、たいていは運営元がわかるのだけれど、
海外のサイトになるとリモートホスト名からは、ISP経由なのか、
モバイル網経由なのか、プロクシ経由なのかさっぱりわからなくなる。

とりあえず、3つほどドメインで規制をかけたものの、
この規制が誤爆しているような気もしている。

というわけで、以下の３つのホスト名に覚えのある人は、どういうホストなのか
確認できるような情報(できれば日本語か英語)をくれると助かります。
netvigator.com
.ismart.net
.smartone.com.hk

プロクシ経由以外は規制する気はないので。

いったい何がすまないのかというと、
臨時用2ch串のプロクシチェックの修正が、間違っていたために、
1回書き込むのに450秒もの時間がかかるようになってしまった。

プロクシチェックは特定のリモートホスト名からのアクセスや、
特定のポート(httpの80番等)が空いているホストからの接続を拒否るはずなのだけれど、
今まで動いていたのはホスト名の方だけで、ポートチェックが動いていなかった。

これは、ブロックしたログに怪しいのがあったので、手動で接続してみたところ、
httpの80番に接続できてしまったので発覚。
実際は、確かにプロクシチェックは出来るんだけど、この待ち時間は想定外。

当の本人は、家に帰ってテストするまでちゃんと動いているもんだと思っていた。

原因は、PHPの default_socket_timeout という設定で、
タイムアウト値を設定していた認識だったのだけれど、この default_socket_timeout　、
ソケット接続時のタイムアウトには効果がない。

そうとは知らず、この設定値で行けると思って、
ソースだけ構文チェックが通ったのを放置してしまった。
結果として、　以下のような感じで待たされる。
チェックするポート数（３個）×タイムアウト時間（７５秒）× POST回数（２回）
計４５０秒。

厄介なのは、長時間待てば書き込みは出来てしまうところ、
なまじ、書き込めてしまうせいでログは一応それっぽく動いている訳で、
運用情報臨時板のso-net規制解除要望スレ眺めてなけりゃ気が付かなかったかもしれん。

まさか、450秒待ててしまう剛の者がこんなにいるとは思ってなかったんだ……