RubyのTime.nowなどでUTCの時間を取得する

RubyではTime.nowで現在のタイムゾーンに基づいた時間を取得することができる。例えばTokyoを設定していれば日本時間が取得される。

特定の環境下において、UTCで時間を取得したい場合にはTime.now.utcを使用する。

puts Time.now.utc.to_s # 2014-08-27 06:13:50 UTC
puts Time.now.to_s # 2014-08-27 15:13:50 +0900

一般的な利用シーンでは使う機会はないと思われるが、多言語対応のためにデータベースにUTCで時間を保存しているケースにおいて、データの引き出しなどには日本時間は使用できないため、Time.now.utcを使う事がある。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA


別言語・別フレームワークで管理していたユーザーのパスワードハッシュをRailsへ移行するケースの対応策案

既存のプロジェクトをRailsに移行する場合、通常のデータはRails用に再変換を行ったり、プログラムについては書き直せば済むが、ユーザーの入力したパスワードのハッシュは復号化できず、Railsの認証用ハッシュに書き換えることができない。

この記事では、Railsへユーザー認証を移行する仕組み案をまとめる。

対策案1 : 新旧ハッシュを共存させユーザーに意識させない

Rails移行後にユーザー登録を行ったユーザーに対しては、Railsのハッシュで認証を行い、それ以前に登録を行ったユーザーは古いハッシュで認証を行う方法。ユーザーの登録日時から新旧を割り出し、認証方式を切り替えて対応する。

古いハッシュで登録を行ったユーザーはログイン後にRailsのハッシュを生成し上書きを行えば、ユーザーに意識させることなくRailsの認証方式を利用できるようになる。

対策案2 : 旧システムにユーザー移行機能を設ける

旧システムの認証機能だけを別のページに残し、旧アカウントを持つユーザーにはそこからログインしてもらい、Rails用のアカウントへ移行する手続きを行ってもらう。

対策案1に比べて、Railsへの以降機能の記述を最小限に抑えることができる他、Railsのユーザー認証用gemなども意識することなく利用できる。ユーザーに与えるストレスも最小限で済む。

対策案3 : Railsの認証機能を利用しない

旧システムの認証機能をRails上で再現し、Railsで生成されるハッシュなどを利用せずに対応する。この場合Railsの認証機能の一部が利用できなくなる。

対策案4 : パスワード再設定機能を利用する

古いパスワードは全て破棄し、新しいパスワードを再発行してもらう。パスワード再設定用メールアドレスだけでは、古いメールアドレスを設定しているユーザーがいる可能性があるため、再設定用メールアドレスだけではなく、ユーザーの本人確認が別の手段でも行えるようなサービスでのみ有効。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です