来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
はてなブログ | 無料ブログを作成しよう
来年も作りたい！ふきのとう料理を満喫した 2024年春の記録 春は自炊が楽しい季節 1年の中で最も自炊が楽しい季節は春だと思う。スーパーの棚にやわらかな色合いの野菜が並ぶと自然とこころが弾む。 中でもときめくのは山菜だ。早いと2月下旬ごろから並び始めるそれは、タラの芽、ふきのとうと続き、桜の頃にはうるい、ウド、こ…
セッションの自動延長 - odeの開発メモ日記
前書き セッションはご存知のとおりリクエストがないと一定時間で消えてしまいます。 けどページによってはタイムアウトの時間をとても長くしたい場合があります。 例えばお絵かきツールで大作を描いたり。。メール文面入力ページで緻密に計算されたラブレターを書いていたり。。などなど。（消えちゃったら発狂しますね） なのでそのページだけはタイムアウトをなくしたいです。 やり方 ajaxで定期的に裏でリクエストを発行すれOKです。 リクエストのたびにセッションの有効期限が延長されます。 util_controller.rb class UtilController < ApplicationController def extend_session_expire # 特になにもしない。 render :text=>"ok" end end 自動延長したいview <%-- javaスクのライブラリロード
railsのクッキーとセッションについてまとめ - おもしろwebサービス開発日記
こないだ、よくわからんので今度調べると書いたところについて。 CSRFの対応について、rails使いが知っておくべきこと - おもしろWEBサービス開発日記 まずクッキーとセッションの違いから。自分の認識はこんな感じ クッキーもセッションも、ブラウザにデータを保存させる仕組み。 クッキーはデータをそのままブラウザに保存させる。 セッションはセッションIDをブラウザに保存させ、データはサーバ側が保持する。サーバはセッションIDをキーにしてデータを取り出す。 railsでクッキーを設定するには railsでは、クッキーは基本的に使わないと思ってますが、一応使い方をメモ。 cookies[:hoge] = { :value => "value", :expires => "30.days.from_now", :path => "/store", :domain => "www.example.
CookieStoreとセキュリティ(2), CookieStoreの有効期限, Ruby on Rails の注文の多い料理店に入ってしまった話 - Journal InTime(2008-01-14)
_ CookieStoreとセキュリティ(2) ちょっと気になるのが、サーバが一度発行したクッキーは、HMACで使用する鍵を変えたりしない限り、ずっと有効だということだ。悪意のある第三者がクッキーを盗聴してリプレイを試みる、というケースについては、盗聴できたという時点で他のセッションストアの場合もセッションハイジャックが可能になるので、CookieStoreがとりわけ危険だというわけではない。気になるのは、ユーザがセッションの状態を任意の時点に戻すことができる点だ。アプリケーションの作りによっては悪さができそうな気もするのだけれど、実際のところどうなのだろう。 [Cookieとセキュリティより引用] と書いたけど、問題になりそうな具体例を思い付いた。 RailsによるアジャイルWebアプリケーション開発 のサンプルのショッピングカートアプリケーションでは、カートの格納先にセッションを使用し
CookieStoreとセキュリティ, RailsによるアジャイルWebアプリーション開発第2版とRails 2.0 - Journal InTime(2008-01-13)
_ CookieStoreとセキュリティ Rails 2.0ではCookieStoreという新しいセッションストアが導入されている。 CookieStoreは、セッションデータをサーバ上のファイルやDBに保存する代りに、クッキー自体に保存する。 このため、セッションデータの読み書きのコストが減ったり、古いセッションデータ の掃除の手間がなくなる、という利点がある。 「そんなことをしたらユーザにセッションデータを改竄されるじゃないか」というのが 当然の疑問だが、HMAC(デフォルトではSHA1)によるチェックで改竄を防ぐようになっ ている。 ただし、セッションデータ自体は平文(marshal+base64)なので、中身を見られてしま う。これについては、そもそもユーザに見られては困るようなデータをセッションデ ータに格納すべきではない、という立場を取っているようだ。 ちょっと気になるのが、サ
Immortal Session の恐怖 : 404 Blog Not Found
2007年11月29日07:15 カテゴリ書評/画評/品評 Immortal Session の恐怖 さすがの私も、今夜半の祭りにはmaitter。 私のtwitterが荒らされていたのだ。 荒らし発言は消してしまったが、にぽたんがlogを残してくれている。 nipotumblr - Dan the cracked man 一部で言われているように、本当にパスワードが抜かれたかどうかまでは解らない。が、状況としてはnowaがベータテスト段階で持っていたCSRF脆弱性をついた荒らしにそっくりだった。 にぽたん無料案内所 - こんにちはこんにちは！！ この時も、私のnowaのメッセージに荒らしが入った。パスワードを変更しても暫く荒らしが続いていた点も似ている。 ここでの問題は、 bulkneets@twitter曰く(直接リンクは避けます) 問題は本人が気付いてもパスワード変えてもセッション残
RailsセッションのCookieにDomain等を指定する - ある異邦人の技術メモ
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を使いたければ、以下のようにすればＯｋぽい。 config.action_controller.session = { :sessi
RailsのSessionが良くわからないのでコードを追いかけはじめました : やむにやまれず
2007年08月03日14:57 by 山崎泰宏 RailsのSessionが良くわからないのでコードを追いかけはじめました カテゴリRuby Tweet sparklegate Comment(9)Trackback(0) 最近APIのマニュアルを読んでも良くわからないことが多くなってきた。なので、ぼちぼちRailsのソースを読む機会が増えて来ました。 やっぱりオープンソースってすごいですよ。 完全に透明なプロダクトって最後は中を見てしまえるという安心感があります。 この安心感って重要で、リチャードストールマン氏がその昔プロプライエタリなプリンタドライバのバグを直せなくてイライラしたって言っていた理由がよくわかります。 今回はRailsのセッションについて調べました。追いかけていくと分かるのですが、セッション関連の処理は非常に大掛かりです。 るびまにも書かれている通りチューニングのポイン
2007-12-11
ソースつき解説。有難いです。 セッションデータがファイルからクッキーに行くことによるメリットは多々あります。 一番大きいところでは、アプリケーションサーバの分割（つまりスケール）が容易になること。 あとは公式ブログの2.0機能ダイジェストにもあるように、軽くなる、メンテが簡単になるなど。 *1 でもセキュリティはやっぱり心配。digestは改竄防止にはなるけれど、データの中身が覗かれたり、secret(digestの鍵）を計算されてしまうリスクは増えています。 対策として考えられるのは、以下でしょうか。列挙してみると基本的なことばかりなのですが。 cookieにはsecureオプション dataには漏洩してはまずい情報はなるべく保存しない ↑と関連してCSRF対策は念入りに secretを十分長くとることや、定期的更新など なんか勘違いとか漏れとかあったらご指摘お願いします。 *1:携帯端
FunctionalテストでCookieを使う方法 - Hello, world! - s21g
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を使用する方法には若干癖があり、ド
2.0のcookie session storeを体感する - ザリガニが見ていた...。
Rails2.0の変更点で、セッション(session)データの保存先がクッキー(cookie)になったということを、よく目にする。確認してみると、確かに以前はtmp/sessionsフォルダの中に常にセッションファイルがあり、増え続けていたが、2.0環境にしてからはいつも空っぽだ。そうなると、本当にクッキーに保存されているのか？どのように保存されているのか？実際に覗いてみたくなった...。 クッキーを確認する MacOS X版のFirefox2.0のクッキーは、Firefoxの環境設定 >> プライバシー タブ >> Cookieを表示 ボタン、で表示される。 想像以上のクッキーの多さに驚く。一つずつ見ていてはキリが無いので、検索で「localhast」と入力してみる。 すると一気に絞り込まれ、Cookie名から「_test_slip202_session」が求めるクッキーだと予想できる
Ruby On Rails ピチカート街道 - Rails 2.0・その１１(セッションの情報は全てクライアントのクッキーに書かれる) -
Rails 2.0 がおっしゃいますに、結局セッションに入れる情報ってユーザーIDだけぐらいで短いから、セッションの情報は全部クッキーに入れちゃえばいいんじゃね？みたいに割り切っているようです。 例としては、コントローラ辺りに、session[:food] = 'nikkorogashi' と書いて、そこの処理を通りますと、session オブジェクトが文字列化(Marshal)されてBase64エンコードされてクッキーに保存されます。 要するにクッキーに保存しやすい文字列に変換されます。 決して暗号化されて保存されるわけではありません。 やる気なら誰でも自分のクッキーの情報を見て、session にどういう値が入っているのかを解析できるので、大切な情報（クレジットカード番号とかパスワードとかスリーサイズとか）は session には入れない方がいいです。 どうやってこのようにクッキーを解
2008-06-20
ふと思い立ってほんの一時期RubyNewsを集めいてた。当時はRubyNewsで検索してもそれらしきサイトはヒットしなかったのでなんとなく始めた。しかし想像以上に手間がかかるのですぐに投げ出す。いま検索するとRubyNewsというブログがあるようなのでそちらにお任せしましょう。 http://d.hatena.ne.jp/rubynews/ ちなみに、Googleアラートでrubyとかrailsとかキーワードを登録すればわけなく情報は収集できます。あとはruby-listくらいに読んでおけばOKと思います。 いますぐ使えるOpenID：特集｜gihyo.jp … 技術評論社 第2回 OpenIDライブラリに付属しているRPサーバを動かしてみる：いますぐ使えるOpenID｜gihyo.jp … 技術評論社 を参考に、Ruby OpenID Libraryに付属するRPのサンプルを動かしてみた
あけまして、Rails 2.0 対応 - WebJourney::Widgets on Rails 開発日記
Fixtureも変わっています。大きくは、関連オブジェクトをidではなくhuman readableな名前で記述できるようになった点ですが、このエントリは関係ありません。隠れた変更点？として、fixtureのキャッシュ機能が追加されています。 続きを読む 2008年になりました。カウントダウンTVを見ながらコーディングをしつつ年を越えました。 とりあえず昨年の積み残しで、実際のコードで1.2.3ベースのコードを2.0対応させています。とりあえずは、トップページの表示に問題がないレベルまでいってから rake test:unit かまそうと思っています。 environment.rb が変わっています。こんな感じで、config.action_controller.session = {:session_key => .. , :secret => .. } をつけないと怒られます。 cha
Ruby On Rails ピチカート街道 - Rails 2.0・その１２(CSRFを勝手に防止) -
2024.02 « - - - - - 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 - - - - - - » 2024.04 CSRF (Cross-Site Request Forgery) を勝手に防止してくださいます。 CSRF とは簡単に言うと、ある特定のURLがDBに挿入したり更新したりすると仮定します。そして、そのURLにアクセスしまくってDBの値を変えまくることです（だと思う・・・）。 script/generate scaffold した時点で、もう既に対応済みになっていて何もすることはありませんでした。 じゃあ、どこで設定されているか、というと、app/controllers/application.rb をご覧ください。 protect_from
Rails2.0 でセッションストアを CookieStore から MemCacheStore に乗り換える時の注意点, 広末の「ブラジャーが…」CM 消費者から「不快」指摘で変更 - underscore.jp/diary(2008-01-16)
_ Rails2.0 でセッションストアを CookieStore から MemCacheStore に乗り換える時の注意点 Rails2.0 からデフォルトのセッションストアが CookieStore になりましたが、Cookie 使えないブラウザ（携帯とか）だと当然使えないので、jpmobile プラグインの transit_sid 機能を有効にした上で、MemCacheStore に乗り換えたのです。 で、早速アプリをデプロイして動作確認してみると、以前に一度でも CookieStore のクッキーを喰ったブラウザでアクセスすると、500 Internal Server Error が出るようになった。 Status: 500 Internal Server Error session_id 'ChinkoMankoXhc2hJQzonQWN0aW9uQ29udHJvbGxlcjo6
Rails2.0 のセッション周りのエラー - ヽ( ・∀・)ノくまくまー(2008-03-01)
● [Rails] Rails2.0 のセッション周りのエラー CGI::Session::CookieStore::CookieOverflow 原因: Cookieが4KBをオーバーしている 解決: active_record_store を使う % rake db:sessions:create % rake db:migrate % vi config/environment.rb config.action_controller.session_store = :active_record_store No :secret given to the #protect_from_forgery call. 原因: CSRF 対策が有効になっている 解決: 秘密鍵を設定する (active_record_store の場合 ※1)
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20080101/p01/