定期的なテーブルのクリーンアップ

ユーザ登録で仮登録、本登録のステップを踏むケースでは仮登録で放置されるとデータベースにゴミが残りますので、これを定期的に削除します。

クリーンアップメソッドをモデルに追加

Userモデルに２４時間以上経っていて、status がfalseのレコードを削除するメソッドを追加します。

  def self.cleanup
    User.delete_all(["status = ?  and  update_at < ?",false,1.days.ago]);
  end

ここで status = false と直接記載するとsqlite3ではエラーになります。sqlite3ではfalseは'f'として保存しているので status = 'f' と書けばエラーにならないのですが、これではほかのDBとの互換性がとれません。このようにプレースホルダをつかうと違いを吸収してくれるようです。続きを読む

勘違い、railsのセッション管理

Railsのセッションクッキーの有効期限ってブラウザの立ち上がっている間だけだったんですね。 もっと永続的な有効期限を使っていると思っていました。

続きを読む

セッション固定攻撃対策

コントローラのテストの前にセッション固定攻撃(Session Fixation Attack)の対策をやってみます。 以下のサイトを参考にしました。

Journal InTime - CSRF対策 , Login GeneratorのSession Fixation Attack対策 , クッキーのパス , セッションファイルの作成場所

決定てきな対策は無いみたいなのですが、二つの方法がメジャーなようです。

1. セッションにＩＰアドレスを保存しておき、ＩＰアドレスに変化があったらセッションが不正とみなす。ただし、 この方法は攻撃者ではない正しいユーザの場合でもＩＳＰからの割り当てアドレスが変更になると無効となってしまいます。
2. ログインする前にセッションがある場合はログイン成功後にログイン前のセッションを廃棄し、新たにセッションを生成する。 こうすればログインに成功したセッションだけが有効となります。

今回は２のみ実装します。１は一長一短ありますが、 ユーザが動作を選択できるようにするなどすれば利便性もそれほど損なわれずに実装可能なのではないかと考えています。ＩＰの保存は宿題。

続きを読む

ユーザコントローラの設計(1) - ログイン

ユーザ管理用のコントローラをつくります。 まず、ログイン、ログオフに必要なアクションを実装してみます。

• login_form / ログインフォームを表示
• login / メアドとパスワードによる認証
• logout / ログアウト

あぷりにユーザ管理用コントローラ"User"を追加します。

colinux:~/ror/test# script/generate controller User login_form login logout
      exists  app/controllers/
      exists  app/helpers/
      create  app/views/user
      exists  test/functional/
      create  app/controllers/user_controller.rb
      create  test/functional/user_controller_test.rb
      create  app/helpers/user_helper.rb
      create  app/views/user/login_form.rhtml
      create  app/views/user/login.rhtml
      create  app/views/user/logout.rhtml

colinux:~/ror/test/app/controllers# cat user_controller.rb
class UserController < ApplicationController

  def login_form
  end

  def login
  end

  def logout
  end
end

続きを読む

ユーザモデルのテスト-(2) ログインメソッドの実装

ユーザモデルにログインメソッドを追加しました。コントローラに実装するほうがベターな気もしましたが、ハッシュ化のロジックをモデルに隠蔽したほうがすっきりしそうなので、まずはモデルに追加する方向でやってみます。

require 'digest/sha1'
class User < ActiveRecord::Base
  attr_accessor :password,:email
  attr_accessible :name,:password,:email

  def before_create
    self.hashed_email = User.getHash(self.email)
    self.hashed_passwd = User.getHash(self.password)
  end

  def after_create
    @email = nil
    @password = nil
  end

  private
  def self.getHash(val)
    Digest::SHA1.hexdigest(val)
  end

  public
  def self.login(email,passwd)
    hashed_email = getHash(email)
    hashed_passwd = getHash(passwd)
    find_by_hashed_email_and_hashed_passwd_and_status(hashed_email,hashed_passwd,true)
  end
end

続きを読む

ユーザモデルのテスト開始

Userクラスのユニットテストにトライしてみます。まず Userの追加をテストします。
user_test.rbにtest_create というメソッドを追加。fixtureには以前に定義したように２レコード記載されています。よって、このテストが成功すればあらかじめ読み込まれた２レコードも含め合計３レコード作成されることになります。
続きを読む

ActiveRecord::Migration でbooleanを追加

ユーザアカウントの登録で仮登録中ステータスを関するためにusersテーブルにステータスを追加します。

colinux:~/ror/test# script/generate migration add_status
      exists  db/migrate
      create  db/migrate/004_add_status.rb

続きを読む

スキーマの変更

fixtureのデータがＤＢに入っているのは分かったのですが、lastlogin_atの値に日付情報が無いことが分かりました。これは列を time で定義してしまったからで、datetimeで設定する必要がありました。 migration を使って timeからdatetimeに変更してみます。

mysql> select * from users \G;
*************************** 1. row ***************************
           id: 1
 hashed_email: [e-mail]
hashed_passwd: __passwd__
   created_at: NULL
    update_at: NULL
 lastlogin_at: 00:00:00
         name: __nickname__
*************************** 2. row ***************************
           id: 2
 hashed_email: [e-mail]
hashed_passwd: __passwd__2
   created_at: NULL
    update_at: NULL
 lastlogin_at: 11:11:11
         name: __nickname__2

続きを読む

fixtureを使った初期データのセット

テストをする前にfixture がちゃんと動作するか確認してみました。結果としてこれだけでバグが見つかったのでやって良かった。

fixtureとはテストするためにあらかじめ用意するテストデータをセットする設定ファイルで YAMLフォーマットです。続きを読む

ActiveRecord::Migration のテスト

データベースをSQLではなく、ActiveRecord::Migration をつかうことによってＤＢに依存せず、RubyのソースコードのみでＤＢスキーマを管理することができます。

まずはテスト用のデータベース"test_development"を作成してmigration の動作を確認してみます。続きを読む

ユーザ管理設計開始

Railsの紹介サイトなんかではショッピングカートなど動くアプリを作ったのにちユーザ管理を後から追加する手順での説明が多いみたいですが、 それだと思わぬバグで他人のデータにアクセスできてしまったりするので、まず最初にユーザ管理を設計することにします。

本当はユーザ登録なしで使えればベストなんですけどね。メモ帳アプリなら内容をパスワードで暗号化できるようにしておき、 ＵＲＬとパスワードをメールで送るような仕組みにすればいいのかな？これもおもしろそうだが、 ひとまずおいておいてblogのユーザ管理の設計するべ。

続きを読む