ユーザーのモデルを作成する

■第6章
第5章では、新しいユーザーを作成するためのスタブページを作ったところで終わった。本章では、一番重要なステップであるユーザー用のデータモデルの作成と、データを保存する手段の確保について学んでいく。

Railsでは、本番アプリケーションに適した認証システムを自分で構築するアプローチも選択できる。筆者曰く、自分自身で認証システムを構築した経験があれば仕組みを理解し、必要に応じて変更することがずっと容易になるらしい。

6.1 Userモデル

ユーザー登録でまず初めにやることは、それらの情報を保存するためのデータ構造の作成。 Railsは、データベースの細部をほぼ完全に隠蔽し、切り離してくれる。 本書ではSQLiteを開発環境で使い、また、PostgreSQLを(Herokuでの)本番環境で使う。

6.1.1 データベースの移行

この節での目的は、簡単に消えることのないユーザーのモデルに構築。 Railsはデータを保存する際にデフォルトでリレーショナルデータベースを使う。リレーショナルデータベースは、データ行で構成されるテーブルからなり、各行はデータ属性のカラム(列)を持ちます。

$ rails generate model User name:string email:string

今回はnameやemailといった属性を付けたUserモデルを使いたいので、このコマンドを打つ。name:stringやemail:stringオプションのパラメータを渡すことによって、データベースで使いたい2つの属性をRailsに伝える。

*コントローラ名には複数形を使い、モデル名には単数形を用いるという慣習を頭に入れておく

今回のコマンドの結果で、マイグレーションと呼ばれる新しいファイルが生成される。

db/migrate/[timestamp]_create_users.rb

class CreateUsers < ActiveRecord::Migration[5.1]
  def change
    create_table :users do |t|
      t.string :name
      t.string :email

      t.timestamps
    end
  end
end

マイグレーションファイル名の先頭には、それが生成された時間のタイムスタンプが追加された。複数の開発者によるチームでは、複数のプログラマが同じ整数を持つマイグレーションを生成してしまい、衝突を起こしていた。現在のタイムスタンプによる方法であれば、基本衝突は避けられる。

マイグレーションはchangeメソッドの集まり。このメソッドはcreate_tableというRailsのメソッドを呼び、ユーザーを保存するためのテーブルをデータベースに作成する。

t.timestampsは特別なコマンドで、created_atとupdated_atという２つの「マジックカラム(Magic Columns)」を作成します。これらは、あるユーザーが作成または更新されたときに、その時刻を自動的に記録するタイムスタンプ。

rails db:migrate

このコマンドでマイグレーションの実行。development.sqlite3というファイルが生成される。これはSQLite5データベースの実体である。

DB Browser for SQLiteをダウンロードしてusersテーブルを確認するとこんな感じに。

6.1.2 modelファイル

ApplicationRecordはActiveRecord::Baseを継承している。

6.1.3 ユーザーオブジェクトを作成する

データベースを変更したくない時は、コンソールをサンドボックスモードで起動。

$ rails console --sandbox

ここからはコンソールで作業。

>> User.new
=> #<User id: nil, name: nil, email: nil, created_at: nil, updated_at: nil>

引数なしで呼んだ場合は、すべての属性がnilのオブジェクトを返す。

userを作ってみる。

>> user = User.new(name: "Michael Hartl", email: "mhartl@example.com")
=> #<User id: nil, name: "Michael Hartl", email: "mhartl@example.com",
created_at: nil, updated_at: nil>

nameとemail属性がちゃんと設定された。

valid?メソッドでuserオブジェクトが有効か確認。

>> user.valid?
true

現時点ではデータベースに格納されていないので、saveメソッドを使って保存。

>> user.save
   (0.1ms)  SAVEPOINT active_record_1
  SQL (7.1ms)  INSERT INTO "users" ("name", "email", "created_at", "updated_at") VALUES (?, ?, ?, ?)  [["name", "Michael Hartl"], ["email", "mhartl@example.com"], ["created_at", "2022-02-12 10:41:35.029896"], ["updated_at", "2022-02-12 10:41:35.029896"]]
   (0.1ms)  RELEASE SAVEPOINT active_record_1
=> true

idが更新され、マジックカラムには現在の日時が代入されている。

>> user
=> #<User id: 1, name: "Michael Hartl", email: "mhartl@example.com", created_at: "2022-02-12 10:41:35", updated_at: "2022-02-12 10:41:35">

6.1.4 ユーザーオブジェクトを検索する

データベースに保存されているかどうかを確認するために、User.findを使う。

User.find(1)
  User Load (0.2ms)  SELECT  "users".* FROM "users" WHERE "users"."id" = ? LIMIT ?  [["id", 1], ["LIMIT", 1]]
=> #<User id: 1, name: "Michael Hartl", email: "mhartl@example.com", created_at: "2022-02-12 10:41:35", updated_at: "2022-02-12 10:41:35">

User.findにユーザーのidを渡している。その結果、Active Recordはそのidのユーザーを返す。他にもいろんなメソッドがある。

6.1.5 ユーザーオブジェクトを更新する

更新の方法は基本的に2つ。1つは属性を個別に代入する方法。

>> user           # userオブジェクトが持つ情報のおさらい
=> #<User id: 1, name: "Michael Hartl", email: "mhartl@example.com",
created_at: "2016-05-23 19:05:58", updated_at: "2016-05-23 19:05:58">
>> user.email = "mhartl@example.net"
=> "mhartl@example.net"
>> user.save
=> true

変更をデータベースに保存するために最後にsaveを実行する必要がある。

もう1つの方法はupdate_attributesを使うケース。

>> user.update_attributes(name: "The Dude", email: "dude@abides.org")
=> true
>> user.name
=> "The Dude"
>> user.email
=> "dude@abides.org"

このメソッドは、属性のハッシュを受け取り、成功時には更新と保存を続けて同時に行う。

6.2 ユーザーを検証する

nameとemailにあらゆる文字列を許すのは避けるべきなので、これらの属性値に、何らかの制約を与える。検証 (Validation) という機能を通して、こういった制約を課すことができるようになっている。

6.2.1 有効性を検証する

まず有効なモデルのオブジェクトを作成し、その属性のうちの1つを有効でない属性に意図的に変更します。そして、バリデーションで失敗するかどうかをテストする、といった方針で進めていく。

6.2.2 存在性を検証する

最も基本的なバリデーションは「存在性 (Presence)」。

user_test.rbにname属性の存在性に関するテストを追記。

user.rbに、空白が入らないようにバリデーションを追加する。

class User < ApplicationRecord
 validates :name, presence: true
end

そうしたら、空白を弾くように。

$ rails console --sandbox
>> user = User.new(name: "", email: "mhartl@example.com")
>> user.valid?
=> false

user.errors.full_messagesで、なんでエラーになったのか見れる。

emailでも同様のことをやる。

6.2.3 長さを検証する

これでUserモデル上に名前を持つことを強制されるようになった。名前の長さにも制限を与える。

名前は50文字まで、emailは255文字まで。

user_test.rbに追記。

test "name should not be too long" do
  @user.name = "a" * 51
  assert_not @user.valid?
end

test "email should not be too long" do
  @user.email = "a" * 244 + "@example.com"
  assert_not @user.valid?
end

user.rb長さのバリデーション追加。

class User < ApplicationRecord
  validates :name,  presence: true, length: { maximum: 50 }
  validates :email, presence: true, length: { maximum: 255 }
end

6.2.4 フォーマットを検証する

有効なメールアドレスかどうかの判定をする。

メールアドレスのバリデーションは扱いが難しく、エラーが発生しやすい。

user_test.rbで有効なメールフォーマットをテストする。

test "email validation should accept valid addresses" do
    valid_addresses = %w[user@example.com USER@foo.COM A_US-ER@foo.bar.org
                         first.last@foo.jp alice+bob@baz.cn]
    valid_addresses.each do |valid_address|
      @user.email = valid_address
      assert @user.valid?, "#{valid_address.inspect} should be valid"
    end
  end

以下のコードでどのメールアドレスでテスト失敗したのか特定できるように。

assert @user.valid?, "#{valid_address.inspect} should be valid"

次は無効性についてテスト。フォーマット検証には、formatを使う。

validates :email, format: { with: /<regular expression>/ }

メールフォーマットを正規表現で検証する。

class User < ApplicationRecord
  validates :name,  presence: true, length: { maximum: 50 }
  VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-.]+\.[a-z]+\z/i
  validates :email, presence: true, length: { maximum: 255 },
                    format: { with: VALID_EMAIL_REGEX }
end

正規表現VALID_EMAIL_REGEXは定数。大文字で始まる名前はRubyでは定数を意味する。残る制約は、メールアドレスが一意であることを強制することだけとなった。

6.2.5 一意性を検証する

メールアドレスの一意性を強制するために (ユーザー名として使うために)、validatesメソッドの:uniqueオプションを使う。

一意性のテストのためには、メモリ上だけではなく、実際にレコードをデータベースに登録する必要がある。

user_test.rbに重複するメールアドレス拒否のテスト。

  test "email addresses should be unique" do
    duplicate_user = @user.dup
    @user.save
    assert_not duplicate_user.valid?
  end

@userと同じメールアドレスのユーザーは作成できないことを、@user.dupを使ってテストしている。

大文字小文字を区別しない一意性のテストも必要。

duplicate_user.email = @user.email.upcase

このコードを上のコードに追加。

ここまでやったことは、あくまでもアプリケーションレベルで一意性を強制しただけであるため、素早く2回連続でクリックしたなどのデータベースレベルでは一意性を強制したことにならない。

emailインデックスを追加すると、データモデリングの変更が必要になる。 今回は、既に存在するモデルに構造を追加するので、次のようにmigrationジェネレーターを使ってマイグレーションを直接作成する必要がある。

$ rails generate migration add_index_to_users_email

メールアドレスの一意性のマイグレーションは未定義なので、[timestamp]_add_index_to_users_email.rbに次のように定義。

class AddIndexToUsersEmail < ActiveRecord::Migration[5.1]
  def change
    add_index :users, :email, unique: true
  end
end

usersテーブルのemailカラムにインデックスを追加するためにadd_indexというRailsのメソッドを使っている。

最後に、データベースをマイグレート。

$ rails db:migrate

データベースによって、メールアドレスの大文字と小文字を区別せずにバリデーションが効かないという問題がある。

これを、user.rbでbefore_saveというコールバックで解決する。

class User < ApplicationRecord
  before_save { self.email = email.downcase }
  validates :name,  presence: true, length: { maximum: 50 }
  VALID_EMAIL_REGEX = /\A[\w+\-.]+@[a-z\d\-.]+\.[a-z]+\z/i
  validates :email, presence: true, length: { maximum: 255 },
                    format: { with: VALID_EMAIL_REGEX },
                    uniqueness: { case_sensitive: false }
end

6.3 セキュアなパスワードを追加する

最後の砦である「セキュアなパスワード」に取り掛かる。セキュアパスワードという手法では、各ユーザーにパスワードとパスワードの確認を入力させ、それをハッシュ化したものをデータベースに保存する。

今回の「ハッシュ化」は、ハッシュ関数を使って、入力されたデータを不可逆なデータにする処理を指す。

ハッシュ化することで、仮にデータベースの内容が盗まれたり覗き見されるようなことがあっても、パスワードの安全性が保たれる。

6.3.1 ハッシュ化されたパスワード

セキュアなパスワードの実装は、has_secure_passwordというRailsのメソッドを呼び出すだけでほぼ終わるっぽい。

class User < ApplicationRecord
  .
  .
  .
  has_secure_password
end

このメソッドを追加すると、次のような機能が使えるようになる。

・セキュアにハッシュ化したパスワードを、データベース内のpassword_digestという属性に保存できるようになる。 ・2つのペアの仮想的な属性 (passwordとpassword_confirmation) が使えるようになる。また、存在性と値が一致するかどうかのバリデーションも追加される。 ・authenticateメソッドが使えるようになる (引数の文字列がパスワードと一致するとUserオブジェクトを、間違っているとfalseを返すメソッド) 。

has_secure_password機能を使えるようにするには、モデル内にpassword_digestという属性が含まれていることが条件となる。

今回はUserモデルにそれを追加する。そのために以下のコマンドを実行。

$ rails generate migration add_password_digest_to_users password_digest:string

上のコマンドではpassword_digest:stringという引数を与えて、今回必要になる属性名と型情報を渡している。

また、has_secure_passwordを使ってパスワードをハッシュ化するためには、最先端のハッシュ関数であるbcryptが必要になる。bcrypt gemをGemfileに追加。

6.3.2 ユーザーがセキュアなパスワードを持っている

$ rails test

を実行してもREDに。

セットアップメソッドでいろいろと情報が足りてないらしい。 user_test.rbにパスワードとパスワード確認を追加。

 def setup
    @user = User.new(name: "Example User", email: "user@example.com",
                     password: "foobar", password_confirmation: "foobar")
  end

これでテストはGREENに。

6.3.3 パスワードの最小文字数

今回は簡潔にパスワードが空でないことと最小文字数 (6文字) の2つを設定する。

パスワードの長さが6文字以上であることを検証するテスト。

test "password should be present (nonblank)" do
    @user.password = @user.password_confirmation = " " * 6
    assert_not @user.valid?
  end

  test "password should have a minimum length" do
    @user.password = @user.password_confirmation = "a" * 5
    assert_not @user.valid?
  end

また、空のパスワードを入力させないために、存在性のバリデーションも追加。

6.3.4 ユーザーの作成と認証

以上でUserモデルの基本部分が完了。次章でユーザー情報表示ページを作成するときに備えて、データベースに新規ユーザーを1人作成しておく。

今度はrails consoleでサンドボックスでないパターン。

>> User.create(name: "Michael Hartl", email: "mhartl@example.com",
?>             password: "foobar", password_confirmation: "foobar")

うまくデータベースに保存されていました。

感想

この章から難易度がまた一段と上がった気がします。たまにエラーも出ましたが無事解決できました。 半年前くらいにインターンを始めようとしたときに「バックエンドとフロントエンド、どっちに興味があるの？」と聞かれた時、何もわかんなかったのが、この章で、バックエンドの人ってこんな感じのことやってんだろうなーとなんとなくですがわかった気がします。

疑問・単語集

*rails testを実行しようとしたら

Migrations are pending. To resolve this issue, run:
        bin/rails db:migrate RAILS_ENV=test

とエラーになってしまいました。以下のコードを実行したらうまくいきました。

$RAILS_ENV=test rails db:drop
$RAILS_ENV=test rails db:create
$RAILS_ENV=test rails db:migrate

• Qiitaの記事は[こちら](https://qiita.com/toruuu00/items/191bc916482ed35b7272
• 第５章の記事はこちら
• 第７章の記事はこちら