This page looks best with JavaScript enabled
⚠️

ゲストログインについての議論の過程

 ·   ·  ☕ 2 分で読めます
✏️

よくあるゲストログイン

ゲストユーザーをあらかじめ作成しておいて、そのユーザーとしてログインする。

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

Share on

END
END
@aiandrox

 
目次