Perlを中心とした技術系の話などをつらつら

2006年10月22日

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

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

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

このとき一番聞きたかったのがまさに今回のミクシィの件で話にでてきた「認証のかかったコンテンツをakamaiで配信できるのか？」という点でした。

というのもFlipClipでは動画・サムネールの配信はすべてmod_perlアプリケーションから動的に行っていて、動画に設定されたプライバシーからユーザのアクセス権を判定し、OKならば動画・サムネールを吐き出すという処理をおこなっているからです。

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

  1. akamai-FlipClip間でルールを決めて作成したCookieを使ってアクセス権を制御する方法
  2. akamai-FlipClpi間でルールを決めて作成したクエリパラメータを使ってアクセス件を制御する方法
  3. 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: スラッシュドット ジャパン | ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解

Posted by horiuchi at 20:18 | Permalink | Comments (0) | TrackBack (0)

2006年10月04日

Firefoxの「選択した部分のソースを表示」はJavaScriptで動的に生成したHTMLも表示される

これ知りませんでした。「選択した部分のソースを表示」しても、普通にその部分の生のソースが出てくるだけかと思い込んでました。

最近はJemplateなんかを使って動的にHTMLを生成するというのをやることが多いんですが、これ、HTMLのメンテがしづらいとデザイナーさんからはすこぶる評判がわるかったんです。

これで少しはメンテが楽になるかなー。

via: subtechグループ - マングローブ - JavaScriptなんかでいじられた後の現在のソースを表示

Posted by horiuchi at 10:24 | Permalink | Comments (3) | TrackBack (0)

2006年10月03日

巨大なFLVを再生中に他のリンクをクリックしてもなかなか移動できない現象を回避する方法

FlipClipでクリップを見ていると、再生の途中で画面内のリンクをクリックして他のページに移動しようとしても、なかなか移動できなくてイライラすることがあったので、これを回避する方法がないものかと考えていたのですが、今日試した方法が有効だったので紹介します。

この現象は、再生している動画のサイズが大きい場合によく起こる現象で、リンクをクリックしてもブラウザはこの大きな動画の再生に忙しいのか、なかなか画面を切り替えてくれません。

そこで考えたのが、クリックした時に、再生している動画をけしてしまうという方法です。

試した方法は簡単で、リンクなどをクリックしてページが切り替わるタイミングで、再生中のフレームを含むdiv要素のinnnerHTMLを空にしてしまうというものです。

コードのイメージはこんな感じです。

 <script type="text/javascript"><:!--
 Event.observe(window, 'beforeunload', function(){
     $('clipPlayer').innerHTML='';
 });
 --></script>

最初はbeforeunloadではなくunloadで試してみましたが、タイミングが遅いらしく、効果がありませんでした。

beforeunloadはブラウザによっては動かないといった情報をどこかで見たような気がしたのですが、IE, FireFox, Safariでうまく動いたので、互換性に問題なしと判断し、FlipClipでもこの方法を早速採用しました。

画面の移動がスムースになって、いい感じです。

Posted by horiuchi at 23:28 | Permalink | Comments (1) | TrackBack (0)

特定のネットワークからは無制限に、外からのアクセスはパスワードを要求

今までapacheでアクセス制限かけるときはIP制限ならIP制限だけ、標準認証なら標準認証だけしか設定したことがなかったし、それで事足りていたのでなにも困ることはなかったんですが、社内のネットワークやサーバ間で通信する相手からのアクセスは無制限に行いたいけど、その他のネットワークからのアクセスはパスワードで制限したいという状況になったので、ちょっと調べてみたら、結構簡単にできました。

Require valid-user
Allow from 192.168.1
Satisfy Any

Apacheのドキュメントに普通に書いてありました。マニュアルはちゃんとよんどかないとだめですね。

それにしてもSatisfy Anyってわかりやすい書き方ですね。どっちか満たせばOKって、覚えやすい。

Posted by horiuchi at 23:14 | Permalink | Comments (0) | TrackBack (0)

アーカイブ