Akamaiで認証付きコンテンツを配信する方法

IPAに脆弱性として提出されていた、ミクシィにアップロードされた画像がURLを直接たたけばログインしていなくても閲覧できる件が技術的には改修せず、ヘルプにその旨を記載することで決着したという話題について、その理由のひとつに画像の配信は一部、CDN（akamai）を使っているため、そこに認証をかけるのが難しいのではというものを見かけました。

このakamaiなのですが、実は、僕が開発運用している動画共有サイトFlipClipでも、日ごとに増え続けるサーバへの負荷、トラフィックに対応すべく、動画の配信にこれを使えないかと検討してまして、先日akamaiの人にきていただいて話を聞いてみました。

このとき一番聞きたかったのがまさに今回のミクシィの件で話にでてきた「認証のかかったコンテンツをakamaiで配信できるのか？」という点でした。
というのもFlipClipでは動画・サムネールの配信はすべてmod_perlアプリケーションから動的に行っていて、動画に設定されたプライバシーからユーザのアクセス権を判定し、OKならば動画・サムネールを吐き出すという処理をおこなっているからです。

この質問に対してのakamaiの方からの回答は、3つの方法があるというものでした。

+ akamai-FlipClip間でルールを決めて作成したCookieを使ってアクセス権を制御する方法
+ akamai-FlipClpi間でルールを決めて作成したクエリパラメータを使ってアクセス件を制御する方法
+ akamaiはIf-Modifiedヘッダ付きのリクエストを毎回FlipClipに送りつけ、認証はFlipClipに任せる方法

1のCookieを使う方法と2のクエリパラメータを使う方法は、どちらもあらかじめakamaiとFlipClipの間で認証OKかNGかをakamaiが理解できるクッキー、クエリパラメータ生成ルールを決めておき、それを動画・サムネールのリクエストと一緒に送りつけると、それを元にakamaiが認証を行い、キャッシュがあればakamaiからコンテンツを返すという方法だそうです。
この方法の利点としては、

- akamaiが認証を行うので、動画のリクエストの際に、FlipClipまでリクエストが飛んでこず、FlipClipのサーバへの負荷はかなり減る

という点があげられるんですが、欠点として、

- 認証箇所が2箇所（akamaiでの認証だけでなく、FlipClipでもCookieやクエリパラメータを生成する際に認証が必要）になってしまうため、セキュリティ的にリスクが大きくなってしまう
- akamaiのためにそれ用の実装をしないといけない
- 仮にクエリパラメータがばれたら誰でもアクセスできることになる
- そもそもクエリパラメータをつけるなんてかっこ悪い

という点があり、ちょっと微妙な感じだなーと感じました。

3の毎回FlipClip側に認証を求める方法ですが、これは、akamaiは認証は行わず、akamaiに動画・サムネールのリクエストが送られてきたら、そのリクエストにIf-Modified-SinceヘッダをつけてFlipClipのサーバに転送してくれるという方法だそうです。

これの利点は、

- アクセス制御はFlipClip側1箇所で行うので、ここだけを考えればいい。
- 同じ動画・サムネールへのリクエストが多いという傾向があれば、キャッシュのヒット率があがり、FlipClipサーバからのトラフィックをぐんと軽減することが期待できる

欠点としては、

- FlipClip側がIf-Modified-Sinceヘッダを理解できるようにしないといけない
- 動画・サムネールへのアクセスがほどよく分散されているような傾向の場合は、キャッシュヒット率があまりあがらず、本サーバ側の負荷軽減は小さくなる
- リクエストごとにFlipClip側にリクエストが飛ぶので、クッキーやクエリパラメータを使った方法よりは、サーバの負荷がかかる

という点があげられますが、
1つ目の欠点は、すでにIf-Modified-Sinceは理解するようになっているので、問題なし。
2つ目の欠点は、FlipClipの動画の配信傾向を見ていると、パレートの法則にほぼ従っていて、1日に配信される動画のうち20％の動画の再生数が全体の再生数の約90％を占めているという状況なので、キャッシュのヒット率はかなり高くなりそうなので、問題なし。
3つ目の欠点はリクエストは毎回FlipClipのサーバまで飛んできますが、上記のとおりキャッシュがうまく働いてくれそうなので、FlipClipサーバはほとんど、302をレスポンスとして返すだけで済むはずで、負荷、トラフィックはかなり減らすことが期待できそうなので、まあ問題なし。

ということで、この方法はいいかもという感想でした。

このようにakamai経由でも認証付きコンテンツの配信はできそうなのですが、なぜミクシィがそれをできないのかというと単純にこの修正で影響を受ける箇所が多すぎて、直すに直せないってことなんじゃないかなーとか、静的に返していたコンテンツを動的にアプリケーションから吐き出すようにすると、パフォーマンスがでないと考えているのかなーとか考えちゃいますがほんとのところはどうなんでしょうねぇ。


via: スラッシュドット ジャパン | ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解

タグを頻繁に切るようなプロジェクトでのsvkの使い方。これでいいのか?

ここ最近はsvkを使ってバージョン管理をしているんですが、svk help introで見ることができるイントロで紹介されているように 、

>

# リポジトリをミラー
svk mirror svn://svn.example.com/project_x //mirror/project_x

# リポジトリを同期
svk sync //mirror/project_x

# ローカルリポジトリを作成
svk copy //mirror/project_x //project_x

<

として、同期したproject_xのリポジトリをそのままローカルリポジトリにするという方法でしばらく使っていました。最初はこれで問題ないように思えたんですが、元のリポジトリでブランチやタグを切った後、svk pull //project_xして、リポジトリの同期をとると、ブランチやタグがファイルの実体としてコピーされているようだということに気づきました。

僕の会社でのsubversionの使いかたは、trunkで開発を進めて、リリースの準備ができたら、ブランチを切り(例えば branches/RB-2.3)、実際にリリースする時にはタグを切る(例えば tags/REL-2.3.0)という形をとっているので、結構タグを切ることが多いです。

これだとタグを切るたびにsvk pullするとそのプロジェクト分のファイル容量が消費されてしまい、すごくディスクを無駄にしているような気がしていました。

そこで考えたのが以下の方法。

>

# リポジトリをミラー。ここは同じ
svk mirror svn://svn.example.com/project_x //mirror/project_x

# リポジトリを同期。ここも同じ
svk sync //mirror/project_x

# trunk,brancheのローカルリポジトリをそれぞれ作成。ここを変更
svk copy //mirror/project_x/trunk //project_x-trunk
svk copy //mirror/project_x/branches/RB-2.3 //project_x-rb2.3

<

ローカルリポジトリを作成する際にリポジトリそのままではなく、トランクとブランチをそれぞれローカルレポジトリとして作成してみました。
今はこの方法で開発をはじめてますが、pull, push,なんかも問題なくできますし、トランクの作業コピー上で、svk smerge //project_x-rb2.3として、リリースブランチの修正をトランクにマージすることもできているので、問題はなさそうです。

もうひとつ、考えられる方法として、mirrorする際に、trunkをミラーするという方法もできそうですが、なんかこの方法だと管理が複雑になりそうだったので上記の方法をとりました。

svkは結構柔軟にいろいろできるっぽいので、他のひとがどういう風に使っているのかちょっとしりたいなーと思いました。

CentOS4.3なローカル開発環境がでけた

もう2週間も前になりますが、なかなか時間がなくて作れなかったローカルな開発環境をゴールデンウィークを利用して構築しました。Vmware Player上でCentOS4.3を動かしてます。
CentOSのデフォルトのロケールがja_JP.UTF-8なので、UTF-8な環境の構築も行いました。
さらに、今までbashを使ってたんですが、zshに変更しました。

それにしても環境構築まで長かった。。

最初、colinuxにCentOS4.3を入れようと思って「coLinux 用 インストーラ」を使って、はじめたんですが、OSのインストールに時間がかかるかかる。。最初はスムースに行くんですが、ちょっとすると、真っ青な画面になって、まったく動かなくなりました。固まっちゃったのかなと、何度かインストールをやり直してみましたが、やっぱり、青い画面でとまるので、そのまま放置して寝てみることに。
8時間くらい寝て、起きた後、画面を見てみると、ちょっとインストールが進んでいました。とまっているわけではないのだなと、さらに放置しておいたのですが、なかなか終わる気配がありません。。結局インストール完了するまでに、2日くらいかかりました。。ここまで我慢してがんばってきたんですが、起動してみるとネットワークカードを認識しない。。いろいろ試してみたんですが、うまくいかなかったので、Vmwareでも試してみるかとなりました。

Vmwareへのインストールはすんなりいって、今までの苦労はナンだったんだという感じですが現在が快適なのでよしとします。

WSSE認証で使用するパスワードにハッシュ化した文字列を使うのはどうか？

ここ最近APIの認証について、考えてます。

AtomAPIの認証として事実上標準的に使われているWSSE認証ですが、APIを提供しているサービスにログインするためのパスワードとAPIの認証用パスワードを共通にした場合、APIを利用するクライアント側に生のパスワードを持たせる必要があるので、APIを利用したサービスでパスワードがもれた場合、そのパスワードを使って、提供側のサービスにもログインできてしまうということになりえてしまいます。

かといってサービスログイン用のパスワードと、API認証用のパスワードを別々に設定するようにすると、ユーザはパスワードを二つ覚えておく必要があるので、ちょっと、めんどくさーとか、わすれたーとなってしまいそうです。

そこで、パスワードは1つで済んで、APIを利用する側のアプリでパスワードがもれたりした場合も、本サービスではそのパスワードを使ってログインできないようにする方法として、APIで使用するパスワードは生のパスワードをハッシュ化したものを使うというのはどうだろうかと考えています。

こうしておけば、APIを利用するアプリ側も生パスワードを持たなくて済むので、なんとなく気持ちが楽になるのかなと。結局ハッシュ化した文字列がパスワードのかわりになるだけなので、これがもれるとAPIの認証はできてしまうんですが、APIで触れる範囲はログインしてできる範囲より小さいと考えられるので、被害は小さくなるのかなと思いました。

flashcastingとか言ってみる

先週末、FlipClipにRSSを吐き出す機能を実装しました。

実際のRSSはこんな感じです。
http://www.flipclip.net/horiuchi/rss

RSSのバージョンは2.0を採用しています。
なぜ2.0かというと、今回新しい試みとして、Podcastライクにenclosureを使って、FlashVideo（FLV）を配信するということをしたかったからです。とりあえず、FlashVideoをCastingするということで、「flashcasting」とか言ってみます。（「flashcasting」だとswfを配信するっぽいから「flvcasting」としたほうがいいのかな。でも言いにくい。。）

現時点ではcastしても受け取るプレーヤーがありませんが、配信から先にはじめてみました。

LLDNのイベント情報が更新されてます

LLDN - イベント情報が更新されました

LLDNのイベント情報が更新されてました。
「フレームワーク対決」おもしろそうですね。

GoogleMapsで生まれ故郷を見てみた

[を] Google Mapsでうちも見えた！と思ったら・・・より、GoogleMapsで日本の衛星写真も見ることができるようになったと知ったので、自分の生まれ故郷をGoogleMapsで見てみました。



こうやってみるとちょっと感動。左下の隕石が落ちた跡みたいなのはなんだろ？？

Google Sitemaps

GoogleよりGoogle Sitemapsというサービスがベータリリースされたようです。

サイトの運営者側でサイトマップをXML形式で作成しておいて、そのありかをGoogleに伝えておくとボットがそのXMLを元にクロールしてくれるといったサービスみたい。

こちらでサイトマップのXMLを生成するためのMT用のテンプレートの例が掲載されています。僕も試しにこのテンプレートを使ってサイトマップを作成してみました。

これを使うことで、サイト運営者の側からGoogleに対してインデックスしてよと言えるようになるので、サイト立ち上げてすぐにGoogleで検索に引っかかるようにしたいなんて時に使うといいのかも。

Internet Week 2004 チュートリアル

Internet Week 2004でInternet Week 2004 チュートリアルの内容が公開されています。
Web and Internet Applications Day にだけは参加しましたが、それ以外は時間が無くて見ることが出来なかったので、公開されてちょっとうれしいです。
でも一緒に公開されているビデオの形式がリアルプレイヤー形式。。ちょっとしょんぼり。

amaztype - 関連する商品で文字を描く

amaztypeに感動。AWSを使って入力したキーワードに関する書籍やCDの画像をとってきて、その画像でキーワードを描きます。描画にはFlashを使ってますね。

Googleデスクトップ検索日本語版公開

Google デスクトップ検索日本語版が公開されてます。
機能は3月7日に公開されて英語版と同等だそう。

はてなフォトライフ 色別写真一覧

はてなフォトライフに新機能色別写真一覧が追加されたそうです。
色別とか焦点別とかモデル別とかはてなフォトライフはカテゴライズの仕方がおもしろいですね。

Google、自動生成ページは上位にでにくく

[を] 自動生成ページがGoogle検索で上位に出にくく

Googleが検索対象ページを従来の２倍の８０億ページに増やしたのが原因らしいです。
メモ。

Google Suggest

Google Suggestがおもしろいです。検索フォームに単語を入力するとそれを補完する形で検索単語の候補をGoogle側でリストアップし、表示してくれます。検索結果の総数も一緒に表示してくれるので、どの単語が一般的なのかとか、単語のスペルはあってるかとか検索意外にも役立ちそうです。

そして早くもmiyagawaさんがperlモジュール化してます。その早さにびっくり。

Koders - ソースコード検索エンジン

Koders - Source Code Search Engine

>>
Koders is a search engine for source code. It enables developers to easily search and browse source code in thousands of projects hosted at hundreds of open source repositories.
<<

Kodersはソースコード検索エンジンで、オープンソースのプロジェクトのソースコードを対象に検索を行うことができるようです。Perlのコードも検索できますが、僕が試した限り、あまり役に立つようなコードがでてきませんでした。オープンソースのプロジェクトっていうとPerlは補助的に使われる程度でメインの言語ということがあまりないからでしょうか。
利用方法としては同じ単語、たとえば「mysql」などを検索キーとしてそれぞれの言語で検索を行い、各言語でDBの接続をどのように記述するのかをみて楽しんだりするなんてことはできそうです。

このソースコード検索エンジンですが、社内のサーバに設置して、社内のマシンに散乱しているソースコードを検索するのに使えるとすごーく便利だなーと思います。実はgonzuiというソフトでそういうことができそうなのでgonzuiには非常に注目しています。

Windows XP Service Pack2 RC1

マイクロソフト、Windows XP Service Pack 2 RC1のダウンロード提供を開始



Service Pack2 RC1の概要をさらっと読んでみました。気になる点はポップアップブロックがデフォルトで有効になるという点。「MTへ投稿」のBookmarkletもたぶんデフォルトでブロックされるんだろうなー。

ポップアップで困ったことを振り返ってみると、エロサイトを見ていたときに、クリックするたびにいろいろな広告が飛び出てきたり、ブラウザを閉じても閉じても出てくる広告をまた消すのがうざったいなーってことくらいしか思いつかないので、なぜデフォルトで有効なのかちょっと疑問です。やはり世の中はエロを中心にまわっているのでしょうか（笑）

JavaScrypt

JavaScrypt: Browser-Based Cryptography Tools


Welcome to JavaScrypt, the high-security data encryption solution which runs entirely in your Web browser. To use the page, your browser must support JavaScript and you must not have disabled execution of that language. Let's see...

JavaScriptじゃなくてJavaScrypt。クライアントサイドでAESを使って暗号化するそう。