この記事には
今回作るアプリケーションの仕様書を記載しています。
今回作るアプリケーション
title | name |
---|---|
アプリ名 | Rails6とNuxt.jsで作るユーザーJWT認証付きシングルページアプリケーション |
OS | macOS |
開発環境 | Docker |
サーバーサイド | Rails apiモード |
フロントエンド | Nuxt.js spaモード |
データベース | postgreSQL |
本番環境 | Heroku |
バージョン管理 | GitHub |
バージョン
tool | version |
---|---|
macOS | 10.15 |
Docker | 19.03以上 |
DockerComopse | 1.25.5 |
Rails | 6.0系 |
Nuxt.js | 2.14以上(ブログ記事ではv2.13を使用) |
Dockerコンテナ設計
開発環境の全体像
GitHubリポジトリ管理
本番環境へのデプロイ設計
ユーザーテーブル設計
カラム | 型 | デフォルト | NULL | 長さ | 内容 |
---|---|---|---|---|---|
name | String | false | 30 | ユーザー名 | |
String | false | 255 | メースアドレス | ||
password_digest | String | false | 72 | パスワード | |
activated | Boolean | false | false | メール認証フラグ | |
admin | Boolean | false | false | 管理者フラグ |
-
name
... ユーザー名。これは一意性のアカウント名ではなくニックネーム的な扱いです。
入力必須、30文字制限を付けます。
-
email
.. ユーザーメールアドレス。会員登録、ログインに使用します。
-
password
... ユーザーパスワード。会員登録、ログイン、ユーザー削除などの重要な操作に使用します。
-
activated
... メール認証フラグ。メールが認証されたユーザーは
true
になります。 -
admin
... 管理者フラグ。今回は使用しませんが、管理者だけが行える操作、管理画面の表示切り替えなどに使います。
ユーザー名の考え方
TwitterやQiita、GitHubなどユーザーがコンテンツを不特定多数に公開できるようなWebサービスの場合、ユーザー名を一意性のユーザーIDとして扱った方が良いでしょう。
他のユーザーがIDで検索することができたり、メールアドレスに変えてログインすることができたり、マイページのURLとして利用することができたり。
利便性が高まります。
ただ今回は、プライベートな業務アプリを想定しているため、個人を認識するためだけに使用します。
ユーザー名に一意制約や英数字必須などのバリデーションは設けません。
このように、どんなアプリケーションを作りたいのかでユーザー名の使用目的も変化します。
自分が作りたいサービスに良く似たサービスを見つけ、研究することをおすすめします。
ユーザー認証設計
今回のユーザー認証設計はこの手順になります。
- ユーザーが新規会員登録を行います。
- ユーザーテーブルに
activated: false
の状態で保存されます。 - 登録されたメールアドレスに期限付きの認証用URLを送信します。
- 期限以内に認証用URLをクリックした場合
activated: true
になり、認証を完了します。
- 認証用URLの期限が切れた場合
- ユーザーは1に戻り、もう一度会員登録を行います。
activated: false
の状態のユーザーはテーブルに保存されたままになります。
メールアドレスの一意性
今回のユーザー認証設計の場合、email
カラムに一意制約を付けると期限切れのユーザーは二度と新規会員登録できなくなります。
そこで同じメールアドレスは何度でも保存可能とし、認証済みのユーザーが既に存在する場合は保存不可とします。
これにより認証済みメールアドレスの一意性を保ちます。