タグ

ブックマーク / developer.cybozu.co.jp (9)

  • Kazuho@Cybozu Labs: String::Filter っていうモジュール書いた - 続: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について

    先のエントリ「(Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について」の続き。 弾さんが「404 Blog Not Found:DHTML - 構造化テキストは構造化するのがやっぱ正しい」で示されているような DOM ベースの操作を行えば、原理的に XSS 脆弱性を防ぐことができます。ただ、クライアントサイド JavaScript によるレンダリングはウェブの構造を破壊するという点で筋が悪い(テーブルと FONT タグを利用したページレイアウトが批判されていた頃を覚えていらっしゃいますでしょうか。JavaScript によるレンダリングはウェブのリンク構造も破壊するので一層たちが悪いというのが自分の考え)ですし、サーバサイドでの DOM 操作は重たいので、できれば避けたいところです。 構造化テキストの HTML への変換は、よほど複雑な記法でない限り

  • Kazuho@Cybozu Labs: (Twitter の XSS 脆弱性に関連して) 構造化テキストの正しいエスケープ手法について

    昨日の Twitter の XSS 騒ぎは、まだ皆さんの記憶に新しいことと思います。いい機会なので、ツイートのような構造化テキストのエスケープ手法について触れておきたいと思います。 Twitter のメッセージは、単なる平文(プレインテキスト)ではなく、「@英数字」のような他のユーザーへの言及と「http://〜」のような URL を自動的にハイパーリンク化する構造化テキストです。 このような複数のルールをもつ構造化テキストを HTML 化する際には、どのようなコードを書けばいいのでしょう? まず「@〜」をリンク化してから、URL をリンク化すればいいのでしょうか? それだと、@〜 のをリンク化した A HREF タグの中の URL がさらにリンク化されていまいますね。 では、URL をリンク化してから @〜 をリンク化すればいいのでしょうか? それだと、@ を含む URL があった場合に

  • Cybozu Inside Out: ScaleBench 公開

    どーもみなさま。こんにちは。 amachang と申します。 さて、ようやく ScaleBench というプロダクトが発表されましたね! ScaleBench のご紹介 で、僕もこれの開発に携わっていたのでちょっと技術的なことについて書いてみたいと思います。 ScaleBench とは ScaleBench とは、サイボウズ製品向けの負荷テストツールで Grinder というオープンソースの負荷テストツールをベースにしています。 Grinder とは Java を使った Web の負荷テストツールです。 Jython でシナリオ(ユーザがどう行動するか)を書いてそれを実行します。 またブラウザの操作を記録して、シナリオを自動で生成することもできたりします。 で、僕がこのプロジェクトで担当していたのが Grinder の改良、改造 シナリオ(バーチャルユーザがどのような順で負荷をかけていくか

    Cybozu Inside Out: ScaleBench 公開
  • Kazuho@Cybozu Labs: REST におけるトランザクションについて (Re: Web を支える技術)

    といいつつ、ひとつだけ理解できないというか、納得できないところが。トランザクションのところがなんだかRESTっぽくないのがすごく気になる Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESSプラスシリーズ)(山 陽平) - ただのにっき(2010-04-23) 「Web を支える技術」は自分もとてもいいだと思う (教科書としてすばらしいし復習用としても読みやすいのでイイ) のですが、トランザクションの所だけは分かりづらいなと感じました。その原因は、atomic transaction で解決できる課題を例として使っているという点と、トランザクションと更新クエリのレイヤ分割がされていない、という2つの点によるものではないでしょうか。 HTTP 上でトランザクションを表現する必要があるケースのほとんどは、atomic transaction ではなく

  • Cybozu Inside Out: SpiderMonkeyを使ってPHPでサーバーサイドJavaScript

    はじめまして。2009年に新卒で入社しました天野祐介です。amachang を期待された方はゴメンナサイ! 先日 SpiderMonkey を利用して PHP から JavaScript を実行する方法を調べる機会がありましたので、ご紹介します。 SpiderMonkey とは SpiderMonkey は  C で実装された Mozilla の JavaScript エンジンです。 これを PHP から実行する拡張を利用すると、 PHP コード内で JavaScript が実行できます。 SpiderMonkey extension のインストール こちらhttp://devzone.zend.com/article/4704に記載されている方法で CentOS にインストールしてみました。 PHP 5.3.0 以上が必要です。 $ wget http://ftp.mozilla.org

    Cybozu Inside Out: SpiderMonkeyを使ってPHPでサーバーサイドJavaScript
  • Kazuho@Cybozu Labs: crontab を使って効率的にサービス監視する方法

    監視とは継続的なテストである、という話 (もしくは cronlog とテストスクリプトを組み合わせた監視手法について)に続きます 今日ようやく、積ん読状態だった「Software Design 2010年1月号」を手に取ったのですが、特集が「今日から使えるスクリプト満載! [プロ直伝]お手軽サーバ監視術」。興味深く拝読したのですが、もっと楽ができるのにと思うところも。ちょうど、昨年末に運用しているサービス「パストラック」のサーバを移転し、crontab と perl で書かれたスクリプト群を使った監視環境を構築したところなので、そこで使っているスクリプト cronlog を紹介したいと思います。 特集の前書きにも書かれていることですが、サーバやネットワーク機器が多数ある環境なら、Nagios を始めとする、専ら監視のために作られたソフトウェアを使って、監視システムを構築すべきです。逆に小規

  • Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法

    MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a

  • 記号でPolyglotプログラミング♪(RejectKaigi2009) | TAKESAKO @ Yet another Cybozu Labs

    RubyKaigi2009の最終日に同じ場所で開催された別のイベント「RejectKaigi2009」にて 「はじめてのRuby1.9プログラミング」と題して、記号Polyglotプログラミングの話をしてきました。 3分という限られた時間でありましたが、貴重な発表の機会を与えてくださりありがとうございます。 取り急ぎプレゼンで披露した記号Polyglotのプログラムを公開しておきます。 ■ hello.pl (という名前ですが、Perlの他にRubyJavaScriptでも実行できるプログラムです) "#{",$/*"}";%#=();$^_^=’?“;">)~${`&&@`{;:+`[[‘,$^_^=’/?")-=^{(=!".=.!,!)&&>’,$^_^=’`-+|{!?“*.((-+({:^(_^’,$^_=”^’+@$@&’^’^.@%@’.’$^_^"";’.$^_^"",’

  • Kazuho@Cybozu Labs: Pacific という名前の分散ストレージを作り始めた件

    大規模なウェブアプリケーションのボトルネックがデータベースであるという点については、多くの同意が得られるところだと思います。解決策としては、同じ種類のデータを複数の RDBMS に保存する「sharding」 (別名:アプリケーションレベルパーティショニング/レベル2分散注1) が一般的ですが、最近では、分散キーバリューストア (分散 KVS) を使おうとする試みもみられるようになってきています。 分散 KVS が RDBMS sharding に対して優れている要素としては、事前の分割設計が不要で、動的なノード追加(とそれにともなう負荷の再分散)が容易、といった点が挙げられると思います。一方で、Kai や Kumofs のような最近の実装では eventually consistent でこそ無くなってきているものの、ハッシュベースの分散 KVS は、レンジクエリができなかったり (例:

  • 1