Dancer(http://perldancer.org)でのCookie、ヘッダの扱いについて
最近「体系的に学ぶ 安全なWebアプリケーションの作り方」という本を読んでいて、「Dancerではどうするのだろう?」と気になった3点についてのメモです。
1. JavaScriptからアクセスしないCookieにはHttpOnly属性をつける。
Dancerでは、デフォルトでHttpOnly属性が指定されています。つまり単純にset_cookieを呼び出しただけでJavaScriptからアクセスできないCookieになります。
get '/default' => sub { set_cookie cookie_test => 'default'; return "default cookie"; };
反対にHttpOnly属性をつけたくない場合は、set_cookieの引数に「http_only => 0」を追加します。
get '/no_http_only' => sub { set_cookie cookie_no_http_only => 'no_http_only', http_only => 0; return "without HttpOnly"; };
2. https通信の場合だけ使用するCookieにはSecure属性をつける。
Secure属性はデフォルトでは指定されないので、set_cookieの引数に「secure => 1」を指定します。
get '/secure' => sub { set_cookie cookie_secure => 'secure', secure => 1; return "secure cookie"; };
3. HTTPのレスポンスヘッダにX-FRAME-OPTIONSを指定する。
header を使います。frameまたはiframe内に表示されないページはDENY、表示されるページはSAMEORIGINを指定します。
get '/x_frame_options' => sub { header 'X-FRAME-OPTIONS' => 'DENY'; return "X-FRAME-OPTIONS test"; };
NetBSD Xen Dom0でのルートパーティションの選択について
NetBSDをXenのDomain 0で使うとき、boot.cfgの項目を以下のように作成します。
menu=Xen dom0:load /netbsd-XEN3_DOM0 console=pc;multiboot /xen.gz dom0_mem=512M
マシンのディスク構成が
- マシンにはwd0とsd0が接続されている
- / はwd0aに作成している
となっている場合に、「カーネルはwd0aから読み出しているのに / はsd0a をマウントしようとする」という現象が起こりました。原因はよく分からないのですが、root=wd0a を追加して / パーティションの場所を明示すると回避できました。
menu=Xen dom0:load /netbsd-XEN3_DOM0 root=wd0a console=pc;multiboot /xen.gz dom0_mem=512M ^^^^^^^^^
pkgsrcでruby 1.8とruby 1.9を共存させる
このマシンでは pkgsrc のソースを /home/pkgsrc に展開しています。インストール先は /usr/pkg です。
まず、pkg_alternativesコマンドをインストールします。
# cd /home/pkgsrc/pkgtools/pkg_alternatives # make install
次にruby 1.8とruby 1.9をそれぞれインストールします。
# cd /home/pkgsrc/lang/ruby18-base # make install # cd /home/pkgsrc/lang/ruby19-base # make install
pkg_alternativesを使ってruby19-baseをデフォルトに設定します。
# pkg_alternatives manual ruby19-base
これで /usr/pkg/bin/ruby は ruby 1.9 ruby 1.8 を使いたいときは /usr/pkg/bin/ruby18 を実行すればよい、という環境ができました。
Net::Twitter::Role::OAuth のサンプルコードが少し違うかも
http://search.cpan.org/~mmims/Net-Twitter-3.11004/lib/Net/Twitter/Role/OAuth.pm 中にWebアプリケーションの例がありますが、2010年2月13日の時点ではこの通り実行してもtwitter_auth_callback の request_access_tokenで失敗します。
成功させるには、callbackに渡された oauth_token を request_access_token の引数に追加する必要があるようです。
sub oauth_callback : Local { my ( $self, $c ) = @_; my %cookie = $c->request->cookies->{oauth}->value; my $token = $c->req->params->{oauth_token}; # oauth_tokenを取得 my $verifier = $c->req->params->{oauth_verifier}; my $nt = Net::Twitter->new(traits => [qw/API::REST OAuth/], consumer_key => 'CONSUMER_KEY', consumer_secret => 'CONSUMER_SECRET'); $nt->request_token($cookie{token}); $nt->request_token_secret($cookie{token_secret}); my ($access_token, $access_token_secret, $twitter_id, $screen_name) = $nt->request_access_token(token => $token, verifier => $verifier); # tokenを追加 }
OAuth 自体のドキュメントは読んでないので、「正しい」のかどうか分からないですが……。
SproutCoreを使ったプログラムで、ソースの変更が開発用HTTPサーバに反映されていない気がするとき
例えばsc-initで作ったディレクトリの名前がtestspだとします。この時SproutCoreの開発用HTTPサーバ「sc-server」はtestsp/tmp以下に一旦ファイルを静的に出力して、これをブラウザに送信しているらしいです。
SproutCoreを使ったプログラムを書いているとき、コントローラのソース変更がWebブラウザで上手く確認できないことがありましたが、
- sc-serverを停止
- testsp/tmpを削除
- sc-serverを起動
してからもう一度Webブラウザで読み込んだらソースの変更が反映できました。
……削除しなくても、もう一度リロードしてたら上手く行ってたかも?
Plaggerの出力に「はてなブックマークコメント一覧へのリンク」を追加する。
assets/plugins/Widget-Simple/hatena_bookmark_comments.yaml というファイルを作る。appendでは以下の処理をしている。
link: http://b.hatena.ne.jp/entry/ append: my $p = $args->{entry}->permalink; $p =~ s|^http://||; $p =~ s/#/%23/; $p content: <img src="http://b.hatena.ne.jp/images/append.gif" />
Plaggerの設定に追加。
plugins: - module: Widget::Simple config: widget: hatena_bookmark_comments