雨季のバンコク2泊4日旅行記 夏は苦手と言いながら、春先の憂鬱を吹き飛ばしたくて、今年も海外旅行の予定をいれてしまった。昨年20年以上ぶりに海外に足を伸ばし、旅をすると人生の栞が増えることを実感してから、だんだん旅が好きになってきたように思う。 今年の行先は雨季まっさかりのタイ・バ…
![はてなブログ | 無料ブログを作成しよう](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
前書き セッションはご存知のとおりリクエストがないと一定時間で消えてしまいます。 けどページによってはタイムアウトの時間をとても長くしたい場合があります。 例えばお絵かきツールで大作を描いたり。。メール文面入力ページで緻密に計算されたラブレターを書いていたり。。などなど。(消えちゃったら発狂しますね) なのでそのページだけはタイムアウトをなくしたいです。 やり方 ajaxで定期的に裏でリクエストを発行すれOKです。 リクエストのたびにセッションの有効期限が延長されます。 util_controller.rb class UtilController < ApplicationController def extend_session_expire # 特になにもしない。 render :text=>"ok" end end 自動延長したいview <%-- javaスクのライブラリロード
こないだ、よくわからんので今度調べると書いたところについて。 CSRFの対応について、rails使いが知っておくべきこと - おもしろWEBサービス開発日記 まずクッキーとセッションの違いから。自分の認識はこんな感じ クッキーもセッションも、ブラウザにデータを保存させる仕組み。 クッキーはデータをそのままブラウザに保存させる。 セッションはセッションIDをブラウザに保存させ、データはサーバ側が保持する。サーバはセッションIDをキーにしてデータを取り出す。 railsでクッキーを設定するには railsでは、クッキーは基本的に使わないと思ってますが、一応使い方をメモ。 cookies[:hoge] = { :value => "value", :expires => "30.days.from_now", :path => "/store", :domain => "www.example.
_ CookieStoreとセキュリティ(2) ちょっと気になるのが、サーバが一度発行したクッキーは、HMACで使用する鍵を変えたりしない限り、ずっと有効だということだ。悪意のある第三者がクッキーを盗聴してリプレイを試みる、というケースについては、盗聴できたという時点で他のセッションストアの場合もセッションハイジャックが可能になるので、CookieStoreがとりわけ危険だというわけではない。気になるのは、ユーザがセッションの状態を任意の時点に戻すことができる点だ。アプリケーションの作りによっては悪さができそうな気もするのだけれど、実際のところどうなのだろう。 [Cookieとセキュリティより引用] と書いたけど、問題になりそうな具体例を思い付いた。 RailsによるアジャイルWebアプリケーション開発 のサンプルのショッピングカートアプリケーションでは、カートの格納先にセッションを使用し
_ CookieStoreとセキュリティ Rails 2.0ではCookieStoreという新しいセッションストアが導入されている。 CookieStoreは、セッションデータをサーバ上のファイルやDBに保存する代りに、クッキー自体に保存する。 このため、セッションデータの読み書きのコストが減ったり、古いセッションデータ の掃除の手間がなくなる、という利点がある。 「そんなことをしたらユーザにセッションデータを改竄されるじゃないか」というのが 当然の疑問だが、HMAC(デフォルトではSHA1)によるチェックで改竄を防ぐようになっ ている。 ただし、セッションデータ自体は平文(marshal+base64)なので、中身を見られてしま う。これについては、そもそもユーザに見られては困るようなデータをセッションデ ータに格納すべきではない、という立場を取っているようだ。 ちょっと気になるのが、サ
RailsのセッションCookieにDomainを指定しようとして、少々苦労したのでメモ。なんでそんなことしたかったかというと、以下のようなサブドメインを運用していて、aのアクセスのために認証したら、bにアクセスしたとき認証情報引き継いでて欲しかったのです。 a.example.com b.example.com c.example.com 結論:config/environment.rbや config/environments/production.rbなどに、以下のようにかけばよい。 config.action_controller.session = { :session_domain => "example.com" } ついでにセキュアCookieを使いたければ、以下のようにすればOkぽい。 config.action_controller.session = { :sessi
2007年08月03日14:57 by 山崎泰宏 RailsのSessionが良くわからないのでコードを追いかけはじめました カテゴリRuby Tweet sparklegate Comment(9)Trackback(0) 最近APIのマニュアルを読んでも良くわからないことが多くなってきた。なので、ぼちぼちRailsのソースを読む機会が増えて来ました。 やっぱりオープンソースってすごいですよ。 完全に透明なプロダクトって最後は中を見てしまえるという安心感があります。 この安心感って重要で、リチャードストールマン氏がその昔プロプライエタリなプリンタドライバのバグを直せなくてイライラしたって言っていた理由がよくわかります。 今回はRailsのセッションについて調べました。追いかけていくと分かるのですが、セッション関連の処理は非常に大掛かりです。 るびまにも書かれている通りチューニングのポイン
ソースつき解説。有難いです。 セッションデータがファイルからクッキーに行くことによるメリットは多々あります。 一番大きいところでは、アプリケーションサーバの分割(つまりスケール)が容易になること。 あとは公式ブログの2.0機能ダイジェストにもあるように、軽くなる、メンテが簡単になるなど。 *1 でもセキュリティはやっぱり心配。digestは改竄防止にはなるけれど、データの中身が覗かれたり、secret(digestの鍵)を計算されてしまうリスクは増えています。 対策として考えられるのは、以下でしょうか。列挙してみると基本的なことばかりなのですが。 cookieにはsecureオプション dataには漏洩してはまずい情報はなるべく保存しない ↑と関連してCSRF対策は念入りに secretを十分長くとることや、定期的更新など なんか勘違いとか漏れとかあったらご指摘お願いします。 *1:携帯端
This article was migrated from http://rails.office.drecom.jp/takiuchi/archive/101 Ruby on Railsでは、コントローラの挙動をテストするためにFunctionalテストという仕組みがあります。 実際にページを取得し、レンダリング結果のタグを解析したり、リダイレクト先が正しいかどうか、指定したIDのタグが出力されているかどうか、などなど、様々なテストを行う事ができます。 そこで、ログインした状態でないとアクセスできないようなページのテストを記述するために、Cookieやセッションを使ってテストを記述する必要が出てきます。しかし、こちら(Rails - Functional Test with Cookie)で報告されているように、FunctionalテストでCookieを使用する方法には若干癖があり、ド
Rails2.0の変更点で、セッション(session)データの保存先がクッキー(cookie)になったということを、よく目にする。確認してみると、確かに以前はtmp/sessionsフォルダの中に常にセッションファイルがあり、増え続けていたが、2.0環境にしてからはいつも空っぽだ。そうなると、本当にクッキーに保存されているのか?どのように保存されているのか?実際に覗いてみたくなった...。 クッキーを確認する MacOS X版のFirefox2.0のクッキーは、Firefoxの環境設定 >> プライバシー タブ >> Cookieを表示 ボタン、で表示される。 想像以上のクッキーの多さに驚く。一つずつ見ていてはキリが無いので、検索で「localhast」と入力してみる。 すると一気に絞り込まれ、Cookie名から「_test_slip202_session」が求めるクッキーだと予想できる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く