Journal InTime

_ Pashapa

京セラのPashapaというauの携帯電話に接続できるデジタルカメラを買った。 4100円なり。 画質もそれなり。

_ 雪

車が雪の中に埋まってしまった。 チェーン付けるのも面倒なので、しばらくは徒歩。

_ 夜鍋

ひさびさに3時まで働いてしまった。

_ CookieStoreとセキュリティ(2)

ちょっと気になるのが、サーバが一度発行したクッキーは、HMACで使用する鍵を変えたりしない限り、ずっと有効だということだ。悪意のある第三者がクッキーを盗聴してリプレイを試みる、というケースについては、盗聴できたという時点で他のセッションストアの場合もセッションハイジャックが可能になるので、CookieStoreがとりわけ危険だというわけではない。気になるのは、ユーザがセッションの状態を任意の時点に戻すことができる点だ。アプリケーションの作りによっては悪さができそうな気もするのだけれど、実際のところどうなのだろう。

[Cookieとセキュリティより引用]

と書いたけど、問題になりそうな具体例を思い付いた。

RailsによるアジャイルWebアプリケーション開発 のサンプルのショッピングカートアプリケーションでは、カートの格納先にセッションを使用しているが、選択された商品をカートに格納する際に商品の価格をコピーする。 *1 これは、商品の価格が変更されても、カートに入っている商品の価格はカートに入れた時点の価格のままにする、という仕様になっているためだ。

ここで問題となるのが、CookieStoreではいつでもセッションの状態を 任意の時点に戻すことができることだ。 カートの内容も当然その時点に戻るので、最安値の時のセッションデータ を保存しておいて後で使用すれば、いつでも最安値で商品を購入できてしまう。

対策は簡単で、カートの保存先をDBにすればよい。

まとめると、CookieStoreに格納すべきでないデータは、以下のようなデータだ。

• ユーザに知られてはまずいデータ
• アプリケーションの動作に重大な影響を及ぼし、状態が変わりうるデータ。

後者については「アプリケーションの動作に重大な影響を及ぼす」だけだと、ログインユーザのIDすら格納できなくなるので、「状態が変わりうる」という条件を追加しないと使いものにならない。 ユーザIDに対応するユーザ情報(管理権限があるか、いつまで有効か、など)は「状態が変わりうる」のでCookieStoreに格納してはいけない。 ユーザIDについても、欠番になったIDを再利用しているような場合では問題が発生する。

上記のような判断をきちんとできる自信のない人はCookieStoreを使わない方がよい。 幸いCookieStoreにはサイズの上限があるので、あまりセッションに情報を格納しないスタイルにプログラマを誘導できるかもしれない。

_ CookieStoreの有効期限

以下のようにセッションの有効期限をサーバ側でチェックすることができる。

before_filter :check_session_lifetime

private

def check_session_lifetime
  if session[:updated_at] &&
    session[:updated_at] + 1.hour < Time.now
    reset_session
    # 実際にはユーザに適切なフィードバックを返す。
    raise "session expired"
  end
  session[:updated_at] = Time.now
end

ただし、セッションに格納する情報に注意する必要があることには変わりない。

_ Ruby on Rails の注文の多い料理店に入ってしまった話

Rails周りの不幸な出来事の原因はいろいろあると思うけど、その原因の一つはRailsプログラミング(あるいはRubyプログラミング・Webアプリケーションプログラミング)がその見かけほど簡単なものではないことだと思う。

Railsの見かけはどんどん簡単になっていく。scaffoldからpaginationが消えてすっきりしたり、MySQLをセットアップしなくてもSQLiteがデフォルトになってすぐに使えたり、CookieStoreがデフォルトになってセッションファイルでディスクを溢れさせるようなこともなくなった。 でも現実は厳しくて、何も考えずに「安心安全素敵」なWebアプリケーションができるわけもなく、さっきも書いたような罠があちこちに潜んでいる。 RubyもRailsも、もともと初心者が何も考えずにプログラムを書けるように作られているわけではない。 CやLispやJavaでもちゃんとしたプログラムが書ける人が、もっと楽にプログラミングできるように作られているだけだ。 見かけの簡単さにつられてプログラムを書きはじめた初心者の周りでは色々な問題が起こる。

でも本当の不幸の原因は、技術的なことよりも、平鍋さんの言葉を借りると「問題対私たち」という構図を作ることが難しいことにあるのではないかと思う。 毎日顔を合わせるチームのメンバの間でさえ「あなた対私」という構図に なりがちなのだから、会ったこともない人たちとコミュニケーションを取る場合はなおさらだ。 「それはお前がマヌケだからだよ!」と言いたくなることもある。 できる人・真面目な人ほど大変だろう。自分はダメな人間なので返事すら書かないことが多い。

とか書いてたら、Linuxとタコの話を思い出した。ぐぐったら生越さんの記事が出て来た。自分もこういう姿勢で人ではなく問題そのものに向き合えるようにしたい。 そのためには、場合によっては直接相手にしないことも適切な対応だろう。*1 スルー力という言葉は嫌いだけど。

あとは蛇足。

池上君は実は大学のクラスメートだった。でも在学中に話をする機会は少なかった。理由は池上君が現実逃避をしながらも無事卒業したのに対して、自分は バンド活動やRubyといった現実逃避に明け暮れたあげく、ついには数学科をドロップアウトしてしまったからだ。

文学部哲学科に変わったものの、一年留年して卒論をでっちあげて卒業した後、こうしてRubyを仕事にしてしまっている。今も現実逃避の真最中というわけ。ここまで来たら精一杯逃げ続けるしかない。

池上君も僕を見習ってもうちょっといい加減に生きたらいいと思うよ。 Rails 2.0ではCSRF対策のコードがデフォルトで入ったし、世界はちょっとずつマシになっている。

_ RailsでMySQLを使う際のcollation周りの問題について

RailsでMySQLを使う時のcollation周りの注意点のメモ。

デフォルトのcollation設定

Railsでrake db:create:allとかすると、デフォルトではcollationがutf8_unicode_ciになるが、大文字小文字や半角全角を区別しないだけならまだしも「パ」と「バ」の区別もされない。たぶん、欧米の人にはutf8_unicode_ciの方が都合がいいんだろうけど。

以下のページの手順でutf8_general_ciやutf8_binに変更しておくとよい。

• ActiveRecordでデフォルトの照合順序を変更する

validates_uniqueness_ofのcase_sensitiveオプション

以下のページで指摘されているように、validates_uniqueness_ofのcase_sensitiveオプションはデフォルトがtrueなので、大文字小文字を区別しないcollationのテーブルでもBINARYキーワード付きで大文字小文字を区別しない検索をしてしまう。

• 参考: Rails でユニーク制約 その２

collationが*_ciの時はいちいちcase_sensitiveオプションを指定しないといけないけど、DRYじゃない。

collationを参照してデフォルトの動作を変えるプルリクエストを送ってみたけど、あまり反応がない。 RDBMSによってデフォルトの動作を変えたくないのかもしれないけど、それならデフォルトのcollationをutf8_binにするべきだ。

このあたりRailsでMySQLを使っている人は不満に思っていないのだろうか。それともHerokuの影響で今時はみんなPostgreSQLなんだろうか。

_ キューブのバッテリー交換

妻のキューブ(Z12)の車検でバッテリー交換に3万8千円かかるとのことだったので、エクシーガ同様にネットで購入して自分で交換した。

アイドリングストップ車なので、純正バッテリーはS-95だった。PanasonicだとN-S100/A2が適合。

Panasonic ( パナソニック ) 国産車バッテリー カオス アイドリングストップ車 + 標準車対応 N-S100/A2

購入先は前回と同じホームセンターセブンにしたけど、今回はなぜかAmazonより楽天の方が安かったのでそちらにした。

走行距離: 52498km