よくあるゲストログイン
ゲストユーザーをあらかじめ作成しておいて、そのユーザーとしてログインする。
Sorceryを使った実装を例とする。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
class UserSessionsController < ApplicationController
before_action :require_login, only: :destroy
def destroy
logout
end
def guest_login
user = User.find_by!(role: :guest) # こんなのとか
user = User.find(User::GUEST_USER_ID) # こんな感じでUserを取得する
auto_login(user)
redirect_to root_path
end
end
|
メリット
すでに作成したゲストユーザーを利用できるので設計が楽。
デメリット
誰にも見れる情報を委ねることになるので、性善説によることになる。
別の人が同時に同じユーザーの情報を編集することがありうるので、開いていたページへのリンクが消えるようなことが起こりうる。
提案するゲストログイン
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
class UserSessionsController < ApplicationController
before_action :require_login, only: :destroy
def destroy
logout
current_user.destroy! if current_user.guest?
end
def guest_login
redirect_to root_path, alert: 'すでにログインしています' if current_user # ログインしてる場合はユーザーを作成しない
random_value = SecureRandom.hex
user = User.create!(name: random_value, email: "test_#{random_value}@example.com", role: :guest)
auto_login(user)
redirect_to root_path, notice: 'ゲストとしてログインしました'
end
end
|
こんな感じで、ゲストログイン時に新たにユーザーを作成するようにする。
ゲストユーザー用のデータが欲しい場合は、「関連データを作成する」メソッドをUserモデルに生やすとかすればいいんじゃないかな。
メリット
ログインするたびに新規ユーザーを作成するので、それぞれのゲストユーザーのデータが競合しない。
デメリット
非アクティブユーザーが増える。
データベースに負担がかかる?
まとめ
ということにより、後者の設計の方がいいのではないか?という結論に至った。
このアイデアを出してくれた@krpk1900_devさん、ありがとうございました。
私が思いつかない視点でした。(記事にしろと言ったのにしなかったので、私が横取りしました)
で、まあ結局「ゲストログインとかいう、普通のサービスにないもののためにがっつり設計するのってどうなの?」みたいなことも出てきたけど。
追記
これとかいいんじゃね?っておすすめしてもらった。
最近よく見かける初心者エンジニアが転職の際に作る今時のポートフォリオに必須だと噂の「ゲストログイン」について - r-weblife