最近どこもかしこもAPI公開なご時勢ですが、FlipClipもクリップ検索用のフィードをAPI第1段として公開しました。
FlipClip開発者向け情報のページ
http://www.flipclip.net/developer/
フィードと言うよりAPIといったほうが世間の受けはよさそうな気がしますが、フィードはフィードなんで、フィードという名前にしときました。
今のところ、以下のクリップを取得できます。
- 一般公開クリップ
- 特定ユーザーのクリップ
- 特定ユーザーの友だちのクリップ
- 特定ユーザーのお気に入りクリップ
フィードのフォーマットはAtomフィード、JSONフィード、RSS2.0を用意しました。
フォーマットの指定はクエリパラメータでできるんですが、別の方法として、Acceptヘッダを使った指定ができるようにしてあります。
リソースを取得するためのURLがあって、そのURLに対してこのフォーマットでくれというと、その形式で返す、というようにRESTっぽくしたかったので、つけました。
それと、絞り込み機能を充実させています。
タグやフリーワード、カテゴリ、撮影日時に位置情報など、対応できそうなのにはひととおり対応してみました。
また、ソートもいろいろな基準でできるようにしてあります。
フィードなんで基本日付以外でソートできるのは、よろしくないような気もしましたが、
使い勝手を考えて、再生回数とか投票の数などでソートできるようにしてあります。
もうひとつ、フィードの認証も実装してあります。
認証にはWSSEを採用しました。
フィードのリクエストの際にWSSEヘッダを付与してリクエストを送れば、
認証されたユーザの権限でクリップが取得できるようになります。
たとえば、自分のクリップなら、プライバシー設定に関係なくすべて取得できますし、
自分の友だちのクリップで友だち公開なクリップも取得できます。
使ってみて、気づいた点、使いにくい点などありましたら、お知らせいただけるとうれしいです。
2007年2月2日金曜日
2006年12月5日火曜日
mysqldumpで文字化けしないためのメモ
ローカルの開発環境で使っていたMySQLなんですが、何も考えずデフォルトの設定で使っていたら、mysqldumpした際に、データが文字化けして、ちょっとは待ったのでメモ。
MySQLのバージョンは4.1.20。
文字化けする原因は、mysqldumpがデフォルトでは、文字コードをUTF-8で出力するようになっていて、フィールドの型がUTF-8でない場合は、自動でUTF-8に変換するためのようです。
僕が使っていたDBは文字コードについて特に何も設定していなかったので、デフォルトの文字コードであるlatin1になっていました。
なので、これもmysqldumpするとlain1 -> UTF-8な変換が自動で行われ文字化けしたということのようです。納得。
この自動変換を行わないようにすれば解決するはず。ということで調べてみると、--default-character-setというオプションを使うとよいことがわかりました。これを使ってデフォルトの文字コードをDBの文字コードとあわせてやることで、自動変換が行われなくなり、文字化けしないようです。
で、結局以下のコマンドで文字化けせずdumpすることができました。
>
これでデータ自体は文字化けしなくなりますが、これをそのまま、UTF-8なDBに取り込むと、取り込んだデータが文字化けしてしました。
ダンプしたデータを見てみると、所々にSET NAMES latin1とかDEFAULT CHARSET=latin1のように「latin1]の文字が。。
これが原因だったようで、ワンライナーでlatin1をutf8に変更してからインポートしたところ、文字化けせずに取り込むことができました。
>
MySQLのバージョンは4.1.20。
文字化けする原因は、mysqldumpがデフォルトでは、文字コードをUTF-8で出力するようになっていて、フィールドの型がUTF-8でない場合は、自動でUTF-8に変換するためのようです。
僕が使っていたDBは文字コードについて特に何も設定していなかったので、デフォルトの文字コードであるlatin1になっていました。
なので、これもmysqldumpするとlain1 -> UTF-8な変換が自動で行われ文字化けしたということのようです。納得。
この自動変換を行わないようにすれば解決するはず。ということで調べてみると、--default-character-setというオプションを使うとよいことがわかりました。これを使ってデフォルトの文字コードをDBの文字コードとあわせてやることで、自動変換が行われなくなり、文字化けしないようです。
で、結局以下のコマンドで文字化けせずdumpすることができました。
>
<
mysqldump --default-character-set=latin1 -uroot --all-databses > db.dump
これでデータ自体は文字化けしなくなりますが、これをそのまま、UTF-8なDBに取り込むと、取り込んだデータが文字化けしてしました。
ダンプしたデータを見てみると、所々にSET NAMES latin1とかDEFAULT CHARSET=latin1のように「latin1]の文字が。。
これが原因だったようで、ワンライナーでlatin1をutf8に変更してからインポートしたところ、文字化けせずに取り込むことができました。
>
<
perl -pi -e 's/latin1/utf8/' db.dump
2006年11月25日土曜日
SledgeでもRESTfulなアプリケーションを書きたい!
今日参加した第9回XML開発者の日の川村さんによる「Ruby on RailsにみるRESTfulアプリケーションの方向性」の話を聞いて、SledgeでもRESTfulなコードを簡単に書きたいと思いたち、ちょっとパッチを書いてみました。
>
これを使って書いたPagesクラスのサンプルはこんな感じです。
>
MyProj::Pages::Itemsクラスがアイテムをあらわすリソースに対応していて、
各メソッドにあわせて、CRUDの操作を実行するという風に書けてすっきりする気がします。
ブラウザからはPUT,DELETEリクエストはできないので、_method=putまたはdeleteとクエリパラメータを使うことで代用しています。
こんなのいかがでしょうか?
>
<
--- Sledge/Pages/Base.pm.orig 2006-11-25 00:40:59.000000000 +0900
+++ Sledge/Pages/Base.pm 2006-11-25 09:27:50.000000000 +0900
@@ -8,6 +8,9 @@
use strict;
use base qw(Class::Accessor Class::Data::Inheritable);
+use vars qw($MethodQueryKey);
+$MethodQueryKey = '_method';
+
__PACKAGE__->mk_accessors(
'r', # Apache::Request or Sledge::Request::CGI
'session', # Sledge::Session
@@ -81,10 +84,16 @@
eval {
$self->init_dispatch($page);
$self->invoke_hook('BEFORE_DISPATCH') unless $self->finished;
- if ($self->is_post_request && ! $self->finished) {
+ if ( $self->is_put_request && ! $self->finished) {
+ my $putmeth = 'put_dispatch_' . $page;
+ $self->$putmeth() if $self->can($putmeth);
+ } elsif ( $self->is_delete_request && ! $self->finished) {
+ my $deletemeth = 'delete_dispatch_' . $page;
+ $self->$deletemeth() if $self->can($deletemeth);
+ } elsif ($self->is_post_request && ! $self->finished) {
my $postmeth = 'post_dispatch_' . $page;
$self->$postmeth() if $self->can($postmeth);
- }
+ }
unless ($self->finished) {
my $method = 'dispatch_' . $page;
$self->$method();
@@ -188,6 +197,16 @@
return $self->r->method eq 'POST';
}
+sub is_put_request {
+ my $self = shift;
+ return ($self->r->method eq 'PUT' || ($self->r->method eq 'POST' && lc($self->r->param($MethodQueryKey)) eq 'put'));
+}
+
+sub is_delete_request {
+ my $self = shift;
+ return ($self->r->method eq 'DELETE' || ($self->r->method eq 'POST' && lc($self->r->param($MethodQueryKey)) eq 'delete'));
+}
+
sub make_content {
my $self = shift;
# template output, then fillin forms
これを使って書いたPagesクラスのサンプルはこんな感じです。
>
<
package MyProj::Pages::Items;
use strict;
use base qw(MyPfoj::Pages);
sub dispatch_index {
my $self = shift;
my $item_id = int $self->r->param('id');
if ( $item_id ){
# アイテム単体を返すコードを記述
} else {
# アイテムリストを返すコードを記述
}
}
sub post_dispatch_index {
my $self = shift;
# アイテムを追加するコードを記述
}
sub put_dispatch_index {
my $self = shift;
# アイテムを更新するコードを記述
}
sub delete_dispatch_index {
my $self = shift;
# アイテムを削除するコードを記述
}
MyProj::Pages::Itemsクラスがアイテムをあらわすリソースに対応していて、
各メソッドにあわせて、CRUDの操作を実行するという風に書けてすっきりする気がします。
ブラウザからはPUT,DELETEリクエストはできないので、_method=putまたはdeleteとクエリパラメータを使うことで代用しています。
こんなのいかがでしょうか?
2006年10月23日月曜日
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: スラッシュドット ジャパン | ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解
この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: スラッシュドット ジャパン | ミクシィ、画像に認可制御なしの欠陥を改修できず、ヘルプで弁解
2006年10月4日水曜日
Firefoxの「選択した部分のソースを表示」はJavaScriptで動的に生成したHTMLも表示される
これ知りませんでした。「選択した部分のソースを表示」しても、普通にその部分の生のソースが出てくるだけかと思い込んでました。
最近はJemplateなんかを使って動的にHTMLを生成するというのをやることが多いんですが、これ、HTMLのメンテがしづらいとデザイナーさんからはすこぶる評判がわるかったんです。
これで少しはメンテが楽になるかなー。
via: subtechグループ - マングローブ - JavaScriptなんかでいじられた後の現在のソースを表示
最近はJemplateなんかを使って動的にHTMLを生成するというのをやることが多いんですが、これ、HTMLのメンテがしづらいとデザイナーさんからはすこぶる評判がわるかったんです。
これで少しはメンテが楽になるかなー。
via: subtechグループ - マングローブ - JavaScriptなんかでいじられた後の現在のソースを表示
巨大なFLVを再生中に他のリンクをクリックしてもなかなか移動できない現象を回避する方法
FlipClipでクリップを見ていると、再生の途中で画面内のリンクをクリックして他のページに移動しようとしても、なかなか移動できなくてイライラすることがあったので、これを回避する方法がないものかと考えていたのですが、今日試した方法が有効だったので紹介します。
この現象は、再生している動画のサイズが大きい場合によく起こる現象で、リンクをクリックしてもブラウザはこの大きな動画の再生に忙しいのか、なかなか画面を切り替えてくれません。
そこで考えたのが、クリックした時に、再生している動画をけしてしまうという方法です。
試した方法は簡単で、リンクなどをクリックしてページが切り替わるタイミングで、再生中のフレームを含むdiv要素のinnnerHTMLを空にしてしまうというものです。
コードのイメージはこんな感じです。
>
最初はbeforeunloadではなくunloadで試してみましたが、タイミングが遅いらしく、効果がありませんでした。
beforeunloadはブラウザによっては動かないといった情報をどこかで見たような気がしたのですが、IE, FireFox, Safariでうまく動いたので、互換性に問題なしと判断し、FlipClipでもこの方法を早速採用しました。
画面の移動がスムースになって、いい感じです。
この現象は、再生している動画のサイズが大きい場合によく起こる現象で、リンクをクリックしてもブラウザはこの大きな動画の再生に忙しいのか、なかなか画面を切り替えてくれません。
そこで考えたのが、クリックした時に、再生している動画をけしてしまうという方法です。
試した方法は簡単で、リンクなどをクリックしてページが切り替わるタイミングで、再生中のフレームを含むdiv要素のinnnerHTMLを空にしてしまうというものです。
コードのイメージはこんな感じです。
>
<
<script type="text/javascript"><:!--
Event.observe(window, 'beforeunload', function(){
$('clipPlayer').innerHTML='';
});
--></script>
最初はbeforeunloadではなくunloadで試してみましたが、タイミングが遅いらしく、効果がありませんでした。
beforeunloadはブラウザによっては動かないといった情報をどこかで見たような気がしたのですが、IE, FireFox, Safariでうまく動いたので、互換性に問題なしと判断し、FlipClipでもこの方法を早速採用しました。
画面の移動がスムースになって、いい感じです。
特定のネットワークからは無制限に、外からのアクセスはパスワードを要求
今までapacheでアクセス制限かけるときはIP制限ならIP制限だけ、標準認証なら標準認証だけしか設定したことがなかったし、それで事足りていたのでなにも困ることはなかったんですが、社内のネットワークやサーバ間で通信する相手からのアクセスは無制限に行いたいけど、その他のネットワークからのアクセスはパスワードで制限したいという状況になったので、ちょっと調べてみたら、結構簡単にできました。
>
Apacheのドキュメントに普通に書いてありました。マニュアルはちゃんとよんどかないとだめですね。
それにしてもSatisfy Anyってわかりやすい書き方ですね。どっちか満たせばOKって、覚えやすい。
>
<
Require valid-user
Allow from 192.168.1
Satisfy Any
Apacheのドキュメントに普通に書いてありました。マニュアルはちゃんとよんどかないとだめですね。
それにしてもSatisfy Anyってわかりやすい書き方ですね。どっちか満たせばOKって、覚えやすい。
登録:
投稿 (Atom)