最近よく見かける初心者エンジニアが転職の際に作る今時のポートフォリオに必須だと噂の「ゲストログイン」について

おはようございます。ritou です。

f:id:ritou:20210131121026p:plain

タイトル長くてすみません。

QiitaでID連携や認証まわりの投稿記事を見ていると、最近「ゲストログイン」という文字列が目に止まることが増えたので何か書いておきます。

ゲストログインとは

「ゲストログイン」の検索結果 - Qiita

実はそんなに引っかかりませんが、このゲストログインと呼ばれる機能、実装者により内容もバラバラです。 どれが正解ってのもない気はしますが、1/31ぐらいの検索結果からどんな認識なのかを見てみます。

qiita.com

ポートフォリオ必須といわれているゲストログイン。

そうなの?

それとは異なり今回のゲストログインはあらかじめ設定されたデータでUserを新しく作成します。 なので「ゲストログイン」より「簡単新規作成」の方が言葉的に近いかもしれません。

  def guest
    user          = User.new(user_params)
    user.name     = "ゲストユーザー"
    user.email    = SecureRandom.alphanumeric(15) + "@email.com"
    user.password = SecureRandom.alphanumeric(10)
    user.save
    sign_in user
    redirect_to how_to_path
  end

ランダムデータで新規登録&ログインさせる系っぽい。

qiita.com

ポートフォリオを作成する際はゲストログイン機能が必須と言われています。

やっぱり、そうなんだ?

Google認証やTwitter認証を頑張って導入しても、自分のアカウントを使うことが心理的なハードルになって、アプリを良く見てもらえない可能性が出てしまいます。

ソーシャルログインに心理的ハードル...ザワザワ

const user = { name: 'ゲストユーザー', email: 'guest@example.com' };

予め用意してたユーザーでセッション生成っぽい。

qiita.com

今回はポートフォリオを見てもらう確率を上げるために必須な、簡単ログインの実装方法を書いていきます。

また必須言うてる。これあれじゃないの?スクールでそう言われた系じゃないの?

  # emailでユーザーが見つからなければ作ってくれるという便利なメソッド
  user = User.find_or_create_by(email: 'guest@example.com') do |user|
  # 自分はユーザー登録時にニックネームを必須にしているのでこの記述が必要
  user.nickname = "ゲスト"
  # 英数字混合を必須にしているので、ランダムパスワードに、英字と数字を追加してバリデーションに引っかからないようにしています。
  user.password = SecureRandom.alphanumeric(10) + [*'a'..'z'].sample(1).join + [*'0'..'9'].sample(1).join
  end

ニックネーム、メアド固定のゲストさんで(最初は登録しつつ)ログイン状態に。パスワードはなんとなく設定する。

qiita.com

新規登録で mail: guest@guest, password: 111111で登録していること

この人でログインさせる。

qiita.com

たくさん読まれてるやつ。自分もコメントしてみたけどもなんだかもうカオス。 上記の予め用意していたアカウント系のリスクが書いてある。

qiita.com

転職活動用のポートフォリオ等にゲストログイン機能があると、多忙な採用担当の方の負担が減り、アプリを利用してもらえる確率が高まるメリットがあります。

利用した気にさせることが大事っぽい!

ゲストログイン用のユーザー(ゲストユーザー)の登録されている

予め用意されている系

※セキュリティをしっかり固める場合、ゲストユーザーのアカウントを通常のユーザーアカウントと一緒に、usersテーブル/Userモデルで管理するのはあまり望ましくありません。

これはわからん。一緒でもいいだろ。

最後に、セキュリティ的な対策です。 もしあなたの開発しているアプリに、ユーザー名やメールアドレス等を編集できる 「ユーザープロフィール編集機能」がある場合、 ゲストユーザー用アカウントのものに関しては変更できないようにした方が良いと思います。

ゲストユーザーを扱うためにアプリにも分岐入れて判断とかが必要。

と言うところで、どうやら

  • ポートフォリオにゲストログインは必須
  • とは言え定義はなんかふんわりしてる
  • **予め用意したユーザーでログインさせる系が多い

ってぐらいな感じです。

本当にこの程度の機能でアピールになるのかは採用側の経験者の意見も聞きたいところですが、 控えめに言うと フレームワークが標準で提供していない機能を追加するだけでも価値はあるでしょうし、想定外のことが起きてそれに対応することも経験としては重要な気はします。

みたいなことをTwitterで言ってたら質問来てました。

せっかくなのでこれぐらいまで実装したら実用的かも?ってのを書きます。

実用的なゲストログインとは

そもそも「ゲストログイン」と言うか「ゲストユーザー」機能ってのの実用的、汎用的な要件はどうなんでしょう。

  • ECサイトで会員登録をせずに商品を購入するゲスト購入
  • ゲーム系のサービスで会員登録をせずにある程度まで使えるお試しプレイ

あたりを考えてみると、

  • メアド確認やパスワード設定など、新規登録をせずともある程度もしくはフルでサービスが利用できる
  • 他の端末、セッションからは同じユーザーでログインできない/紐づけられたデータを流用できない
  • サービスが気に入ったら改めて新規登録を行い、データは引継ぎつつ全てのサービスを利用できたりできなかったり

みたいなところが要件として出てくるのではないかと考えます。 それを設計/実装に落とそうと思うと

  • Userモデル
  • セッション管理
  • アクセスコントロール
  • 本登録処理とデータ引き継ぎ

あたりになります。それぞれのポイントを整理してみましょう。

Userモデル

まぁ、こんなのは一例でしかないわけでありますが、Userモデルに対する要件としては

  • ゲストユーザーであることを判定できる
  • メアドなどを識別子とする場合は空
  • パスワードなどのクレデンシャルが空
  • ニックネームなどプロフィールは登録可能

ぐらいでしょう。

小規模なアプリにありがちなUserモデルであれもこれも含むてんこ盛りモデルだったりすると "必須" 項目になっているものがあり、なかなか対応が困難になる場合もあるかもしれませんが、あまりランダムな値などを入れるのは望ましくないでしょう。

上記の記事でメアドやパスワードにランダムな値をいれるような実装もみられましたが、実際のプロダクトで "設定することでログイン可能になる" 場合は "知らないからいいだろう" と言う話でもないでしょう。

これは極端な例ですが、規模が大きくなることを想定したアプリなどで細かくテーブルを分けるようにするなら、

  • 識別子を払い出す : User(ID発行は既存のものと一緒で良い)
  • 識別子とロール : UserRole としてゲスト状態を保持
  • 識別子とメアドを紐付ける : UserEmail を持たない
  • 識別子と認証方式、クレデンシャルを紐づける : UserCredential を持たない
  • 識別子とプロフィール情報 : UserProfile は持つ

みたいな管理をすることで、ゲストユーザーの要件に対応できそうです。

ゲストユーザー用のモデルを用意する方法もあり得るとは思いますが、この後言及するアクセスコントロールの部分やデータ引き継ぎなどを実装する際に既存のアプリの機能に大きな改修が入らないように気をつける必要があります。

セッション管理

ECのゲスト購入であれば、購入フローで必要な値を引回す必要があります。 これは未ログイン状態のセッションに紐づけることでも実装できますが、この後言及するアクセスコントロールをしっかり実装できるならば、ゲストユーザーによる処理を開始する際に

  • ゲストユーザーを作成
  • セッションとの紐付け

を行うことで実現できそうです。

アクセスコントロール

ビジネス向けに比べて比率は少ないかもしれませんが、コンシューマ向けのサービスでもユーザーのロールを意識してサービスの利用制限を行う例はあるでしょう。 例えばゲームなどでいわゆるユーザーランクによって利用できる機能が解放されると言うことはそれに近いかもしれません。ゲストユーザーを扱う際も同様です。 上記の記事でも触れられていたものもありましたが 「ゲストユーザーが利用できない機能」を決めておき、利用制限をしっかり行うこと も重要でしょう。

本登録処理とデータ引き継ぎ

ゲームなどのゲストログインでは

  • ゲストユーザーの利用が制限された機能を利用しようとした
  • 利用可能なゲームのポイントを失った

と言うあたりで本登録処理を促し、そのまま設定などを引継いで利用できるような実装が必要となりそうです。 ECサイトでは購入フローが完了した後などに会員登録を促して継続的な利用を促したりもするかもしれません。

Userモデルのところで意識したゲストユーザーと通常のユーザーの違いを意識して、既に設定してあるプロフィール情報や同一セッションでユーザーが入力した情報は生かしつつ不足している部分を埋める実装が必要となるでしょう。

まとめ

  • 最近目に付くゲストログインについて調べた
  • ここまでやれば実用的かな?ってとこを説明した
  • スクールかなんか知らんけど、ゲストログインを課題にするならもうちょい詳しく教えろ

転職を考えている初心者エンジニアの皆さんの成功と、より一層のご活躍をお祈り申し上げます。

以上です。

おまけ画像

f:id:ritou:20210201034652p:plain

f:id:ritou:20210201034706p:plain

ではまた!