|
今日、仕事で技術調査をしていて、
見つけたＢｌｏｇに「Twitter」のＢｌｏｇパーツが貼られていたのをきっかけに、 Twitter関連の情報をあさっていたのですが・・・ 正直、Twitterを筆頭とした「ミニブログ系」の何が面白いのかいまいち・・・(´･ω･`) 私にとってＢｌｏｇ・・・というか、「Ｗｅｂで日記を書く」という行為には、 以下のような意味があります １．文章を書くと楽しい ２．情報を発信する・・・というか、ばらまくと楽しい ３．情報を元に他人とやり取りするのが楽しい 優先順位の高い順に書くとこんな感じなのですが、 問題は、書くと楽しいのは「文章」であり、 「ひとりごと」という「文」ではないってことですね 私の感覚だと、文章であれコードであれ、 「ある程度まとまった意味のあるまとまり」を書いたり読んだりするのが楽しいので、 あまり意味を持たない散文的なものは肌に合わないのはあります ある一瞬にしか意味を持たない文章より、 何年か後に読み返しても面白いものが好きなんですよね ぶっちゃけ、以前ＨＰとしてやっていた頃のコンテンツを、 今読んでも「私は」楽しいです たぶん、今書いている日記の最大の読者は「私自身」なのでしょう さて、話が発散してきたので元に戻すと、 私にはいまいちと思っても、ミニブログ系がある程度うけているのも事実なので、 どれかのサービスを試してみようかと思ってます Twitterが第一候補だとは思うのですが、 私はひねくれているので、あえてマイナー系を選ぶかも・・・ |
|
冷静に考えれば、Ｆｌｅｘは「クライアントサイド」で動作するわけなので、
すぐに気づきそうなものだったのですが・・・ Ａｊａｘと同じことですからね・・・ 結論から言うと、ロジックを担当しているＪａｖａコンテナを、 外から隠蔽することは不可能でした 応急処置としてコンテナのポートを開けることになりました(´･ω･`) まあ、これを仕事の本番テストでやっていたら、 とんでもない大騒ぎになるところなわけで、 自分で検証して、外部に使ってもらったのは正解でしたね 想定外にコンテナを外に公開することになったので、 ロジックレベルで、落ちた分のセキュリティを補完しないといけないわけですが・・・ そこは腕の見せどころか(`･ω･´) |
|
思ったより時間がかかりましたが、
Servlet側のロジック構築が一通り終わり、 とりあえずのβリリース版が完成しました(｀･ω･´) ｂ あくまでデモの範囲で動作するレベルですので、 実際の運用に必要なユーザ管理とかが足りてないのですが、 運用テスト期間中は私が手動でカバーする方向で で、あっちのＢｌｏｇにも書いたのですが・・・ 今回のシステムでは、ＦｌｅｘはＵＩのみを担当し、 データを操作するロジックは一切持っていません また、データを特定するためのＩＤ等も、極力ＵＩ側から排除しています 独自のセッション機構（というほど立派でもないですが・・・）により、 ユーザ固有のデータはＳｅｒｖｌｅｔ側で保持し、 Ｆｌｅｘ側は必要最小限のリクエストを投げるだけになっています また、ＵＩを動かすＷｅｂサーバと、ロジックを担当するＪａｖａコンテナは、 ポートが別になっており、ルータが開いているのはＷｅｂサーバだけですので、 ロジック側に不正なリクエストを投げることが難しい仕組みになっています さらに、これらとは別に、 ロジック側で不正なリクエスト判別の仕組みも組み込んでいます これらの保護構造により、不正なデータ操作は極力排除した・・・はずです （最悪、セッションを乗っ取られたとしても、 影響範囲は乗っ取られたセッションのユーザ権限の範囲に収まるはず） システムに完璧はありえませんが、逆にどんな問題が発生するかは、 実際に運用テストしてみないとわからない部分が大きいので、 後は試してみてですかね・・・ あと、先日書いた「localhost」問題ですが、 やっぱりlocalhostは別ドメイン扱いでした(´･ω･`) よって、Ｆｌｅｘがアクセスするサーバを外部ファイルに切り出すことで、 開発環境と本番環境で再コンパイルが発生しないようにしました さて・・・さくっとユーザ管理機能を追加しなければ・・・ |
|
今日は「BOT」のお話
とはいえ、こっちのBlogで書く以上、 当然「フォームの自動化スクリプト」のことを指します BOTを排除する手段はいろいろありますが、 有名なのが「CAPTCHA」ですかね 要するに、人間の目を経由しないと得られない情報を使うことで、 BOTが単純にリクエストを生成するのを防ぐというわけです ただ・・・この「CAPTCHA」を破ることも自動化することが可能です 単純に「画像の合成」で画像を生成する仕組みでは、 元になる画像の規則性と、画像を結合する規則性さえ割り出せれば、 自動で文字列を割り出すことは可能です よって、既存の画像を「合成する」のではなく、 「生成する」方向になるわけですが・・・ これって要は、サーバサイドで（Photoshopのような） 画像処理ロジックを持たせるということであり、 ものすごくコストがかかる話ですよね(´･ω･`) というわけで、既存のライブラリを利用する方法がいいとは思いますが、 こういった記事もあり、CAPTCHAという仕組みそのものが そろそろ限界のようにも思います ・・・と、ここまで書いてきましたが、 相手が一般のユーザ、あるいは「スクリプトキディ」程度なら、 CAPTCHAの存在で心理的な障壁が発生し、ある程度の不正が防げます 問題は、今回この話を調べるに至った原因に「利権」が絡んでいることです つまり、破ることで金になるってことです 「正規のユーザ」がBOTスクリプトで操作を自動化していたのですが、 これを弾く仕組みが欲しいわけです 極論を言えば、どこかのサイトで述べられていたように・・・ 「破るのにかかる費用＜利益」 ・・・が成立する限り、あらゆる手段を用いてくる可能性はあります どんなにCAPTCHAのロジックを強化しても、 相手がそのロジックに追随してくればいたちごっこです 思うに、この問題は「HTMLフォーム」という仕組みの限界な気もします APサーバがキーと値の対になる情報を受け取って処理するという仕組みである限り、 HTMLから対になる情報さえ抽出できれば、いくらでも自動化は可能です 一方で、それを解決する一助になりそうなのが「RIA」 ・・・例えば「Flex」なのかなと Flex/Javaシステムてあっても、 結局はUIであるFlashからServletへリクエストを投げるわけで、 基本的な仕組みは同じです しかし、Servletのアクセスポートが外部に公開されていなければ、 外部からはFlashを経由しない限り、 Servletにリクエストを発行できません （これは一般的なWebインターフェースとDBの関係に似ていますね 普通はDBを直接操作できないという 今回の場合、隠蔽されるのはDBも含めた「ビジネスロジック」ですね） Flashは自分が動作しているドメインの外へリクエストを発行できない （発行するには相手サーバの許可が必要）ので、 Flashを逆コンパイルしてリクエスト情報を抽出しても、単純な自動化はできないかと ・・・という認識なのですが、間違ってますかね？ つまり、Flexが「localhost」にリクエストを発行するという記述で、 システムが動くか、ってことなんですが Flexでシステムを作っているくせに、あまりにも今さらな疑問なのですが、 今週末には例のシステムが運用テストに踏み込める予定なので、 そこで確認ですかね・・・ ・・・ほんと、今さらだな(´･ω･`) |
|
きっかけはこのＢｌｏｇのアクセスが妙に増えていたことでした
カウンタだけ見ると、平常時の３～４倍になってますΣ(・ω・ノ)ノ 最初に疑ったのが、悪名高き「百度」のクローラー 日本進出の際、あまりに日本のサイトからブロックされまくったため、 謝罪文を掲載し、クロール頻度をかなり落としました （以前は９回／１ｓだったらしく、狂ってるとしか・・・） それ以降は文字通り「話題にも上らなくなった」のですが、 ほとぼりが冷めた今、また動き出したのかと思い、 ちょっとＷｅｂで調べてみたのですが・・・ 出てくる情報が日本進出前のものばかりなので、 おそらく沈静化を通り越して空気化しているのだと思いますが、 百度について書いたＢｌｏｇの中に、ＩＴｍｅｄｉａのものもありました 問題はですね・・・ そのＢｌｏｇから旧Ｂｌｏｇに対し、トラックバックがあったようでしてΣ(・ω・ノ)ノ それに気づかず、旧Ｂｌｏｇは更新が面倒で閉鎖してしまいました ただ、ログは残してあったので、多少なりとも需要があるのならと、 使えそうな記事だけリカバリしてみました ざっと１０件程度ですが、使えそうなものは参考にしていただければと さて、問題のアクセス過多の件ですが、 アクセスログをチェックしてもこれといった情報が得られませんでした(´･ω･`) もうすぐopenSUSE11.0が出る（明日あたりβ３？）ことですし、 それに合わせてサーバを再構築する時は、 Apacheのログ出力フォーマットも考えないといけませんね・・・ |
