【連載】Railsとnode.jsを繋ぐ認証 作戦編 -cookie sessionのおさらい-
ガリレオスコープ開発チームによる �最新Web動向、技術メモ ( Ruby, Rails, node.js ) です 最近、我々の開発はrubyのRailsだけでなくてcoffeescriptでのnode.jsでの開発のウェイトも高くなってきています。 そこで、Rubyとnode.jsを繋ぐ上での問題になった箇所をまとめて、今後同じような問題に当たる人へのメモにしようと思います。 まず始めに、認証編ということで、全3回でまとめます。 認証編の第一回目はcookie sessionのおさらいと作戦立てです。 cookie sessionのメリット まずは、cookie sessionのおさらいをしながらメリットを。 Railsでは2.0からcookie sessionを標準にしています。 cookie sessionの良い点は、 1. スケールアウトしやすい2. session管理の簡便さ3
CookieStoreとセキュリティ, RailsによるアジャイルWebアプリーション開発第2版とRails 2.0 - Journal InTime(2008-01-13)
_ CookieStoreとセキュリティ Rails 2.0ではCookieStoreという新しいセッションストアが導入されている。 CookieStoreは、セッションデータをサーバ上のファイルやDBに保存する代りに、クッキー自体に保存する。 このため、セッションデータの読み書きのコストが減ったり、古いセッションデータ の掃除の手間がなくなる、という利点がある。 「そんなことをしたらユーザにセッションデータを改竄されるじゃないか」というのが 当然の疑問だが、HMAC(デフォルトではSHA1)によるチェックで改竄を防ぐようになっ ている。 ただし、セッションデータ自体は平文(marshal+base64)なので、中身を見られてしま う。これについては、そもそもユーザに見られては困るようなデータをセッションデ ータに格納すべきではない、という立場を取っているようだ。 ちょっと気になるのが、サ
Rails 4.0.0を4.0.2にアップグレードした
Rails 4.0.2が出ていたので、セキュリティフィックスが含まれているということもあって、動かしているウェブアプリ（このブログ）を4.0.2にアップグレードしました。その際の作業ログをメモっておきます。 Rails 3.2.16 and 4.0.2 have been released! http://weblog.rubyonrails.org/2013/12/3/Rails_3_2_16_and_4_0_2_have_been_released/ (1) GemfileのRailsのバージョンを4.0.2にする (2) 以下のコマンドを実施。 {{{code bundle update rake rails:update }}} 以下、rake rails:updateの作業ログです。 -routes.rbはスキップ -application.rbは特に変化が無かったのでスキップ
Rails SessionにCookieStore使った時の問題点 - OAuth.jp
今日 @mad_p さんからRT来てたこのツイートに関して、ちょっと調べたのでまとめときます。 Security Issue in Ruby on Rails Could Expose Cookies http://t.co/JlsXVEn4rZ — Ruby on Rails News (@RubyonRailsNews) September 25, 2013 前提条件 Railsではデフォルトでsessionをcookieにのみ保存して、DBなりmemcacheなりのserver-side storageには何も保存しません。 これがCookieStoreとか呼ばれてるやつです。 この場合のsession cookieは、Railsのsession object (Hash object) をMarshal.dumpしてそれに署名を付けたtokenです。 rails 4では署名付ける代
MongoDBでPHPのセッション管理をする : エクスギア Blog
MongoDBはNoSQLと言われるドキュメント指向データベースとして有名です。 以前個人的にsymfony1系でのセッション管理をMongoDBで行うsfMongoSessionStrageというのを書いたのですが、もっと汎用的にインクルードするだけで普通のPHPスクリプトでも使えるように書き直してみたので紹介したいと思います。 MongoDBでセッション管理を行うメリット 単体サーバーでの運用ではメリットはほとんど無いと思います。メリットがあるのは複数台構成のサーバーでPHPのアプリケーションを運用する場合です。セッションのデータを通常のファイルベースで行うとアクセスしているWebサーバーにセッションデータが保存されます。そのため複数台構成の場合はアクセスするWebサーバーが異なってしまった場合にセッションデータを読み込めないという問題が発生します。そこでデータベースを利用してセッシ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20080101/p01/
