サービス会員ログイン
服屋のショッピングモールサイトを運営していると考えてみてください。お客さまが自分で会員登録をして、会員だけがレビューを書いたりランク別の特典を受けられるようにしたいときがあります。そのためには「お客さまが自分で登録してログインする会員システム」が必要です。この会員システムを自分のサイトに組み込んでくれる Space の機能が ServiceLogin(自分のサービスにお客さまが直接登録して使うログイン設定)です。
ServiceLogin を有効にすると、お客さまは Google などのソーシャルアカウントで誰でも自分で登録できます。登録したお客さま一人ひとりが ServiceUser(自分のサービスに登録した会員)になります。ログインの手続きとログイン状態の維持は WEEGLOO が代わりに処理するため、パスワードを自分で保管したり、ソーシャルログインを一から作ったりする必要はありません。
このページでは ServiceLogin が何であり、運営チームのアカウントとどう違うのかをまず見たうえで、服屋の Space で ServiceLogin を実際に有効にして設定してみます。
会員は運営チームとは違います
WEEGLOO にはログインする人が二種類います。混同しやすいので、まず境界を引いておきます。
- 運営チーム/スタッフは商品を登録し、サイトを管理する人です。お客さまのように ServiceLogin で登録するのではなく、WEEGLOO アカウントでこの Space のメンバーになって(すでに中にいる人からの招待とロールの付与によって)入ります。運営チームの権限はロールと権限で扱います。
- ServiceUser はそのサイトを使うお客さま/会員です。自分が運営する服屋サイトでソーシャルアカウントを使って直接登録した人です。運営チームとはまったく別のログインです。
ひとことで言えば、運営チームは「お店を切り盛りする人」、ServiceUser は「お店に訪れたお客さま」です。ServiceLogin は、このお客さまたちが出入りする入口を作る作業です。
一緒に動く三つのもの
会員システムは三つのものがかみ合って動きます。
- ServiceLogin: ログイン設定そのものです。どのソーシャルログインを使うか、登録した会員にどの権限を初期値として与えるかといったことをここで決めます。
- ServiceUserRole: 会員に与える権限のまとまりです。会員が何を見られて何を書けるかを定めておきます。
- ServiceUser: 登録した会員一人ひとりです。お客さまが登録するたびに一つずつ作られます。
このページは入口を開ける ServiceLogin の設定に集中します。会員が実際に何を見て使えるか(権限)を定める ServiceUserRole は会員のロールと権限で別途扱います。下の設定で選ぶ デフォルトの Role が、まさにそのページで作るロールです。
ServiceLogin を有効にする
服屋の Space で会員ログインを有効にしてみます。
会員ログインの設定は 1 つの Space に 1 つだけあります。複数を新しく作るのではなく、この 1 つを有効にしておき、必要なときに直しながら使います。
ServiceLogin は最初は無効になっています。設定画面を開くと「ServiceLogin が無効になっています」という案内とともに 有効化 ボタンが表示されます。案内には「サイトで Google などのソーシャルログインを利用するには ServiceLogin を有効にしてください。OAuth とセッションは Weegloo が処理します。」と書かれています。
- 左メニューで サービス を開き、ServiceLogin を押してください。
- 基本情報 画面で 有効化 ボタンを押してください。
有効化 を押すと設定フォームが開きます。このフォームでソーシャルログインを一つ以上有効にして 保存 しなければ、会員ログインは実際には動作しません。
設定フォームを埋める
設定フォームは基本情報とソーシャルログイン設定に分かれています。まず基本情報を埋めます。
| 項目 | 何を書くか |
|---|---|
| サービス名 | ログインするときにお客さまに表示されるサービス名です。服屋なら店名を書きます。 |
| 連絡先メール | ログインに問題が起きたとき(例: 登録できる人数がいっぱいになったとき)にお客さまに見せる連絡先です。 |
| ログイン後の遷移先 URL | お客さまがログインを終えたあとに戻る、自分のサイトのアドレスです。 |
| デフォルトの Role | 新しく登録したお客さまに自動的に与えられる権限のまとまりです。隣の Role 管理 を押すと、権限を作る画面に移ります。 |
- サービス名 に、お客さまに見せる名前を入力してください。服屋なら
ぬくもりクローゼットのように店名を書きます。 - 連絡先メール に、問い合わせを受けるアドレスを入力してください。例:
help@nukumori-closet.com。 - ログイン後の遷移先 URL に、ログイン後にお客さまが戻る自分のサイトのアドレスを入力してください。例:
https://nukumori-closet.com/auth/callback。この欄にはhttps://...のような Web アドレスを入れます。モバイルアプリ(Android・iOS)にログインを組み込む場合は、アプリのアドレスをここにそのまま入れることはできず、つなぎ方が少し異なります。そのときに必要となる技術的な手順は Auth API で扱います。 - デフォルトの Role で、新しい会員に与える権限を選んでください。まだ作った権限がなければ、隣の Role 管理 で先に作ってから戻ってきてください。
デフォルトの Role に何を選べばよいか、会員にどの権限を与えるかは会員のロールと権限で扱います。
登録を受け付ける前に運営チームが一度確認したい場合は、新規サインアップに admin の承認を必須にする を有効にしておくことができます。このオプションを有効にすると、新しく登録したお客さまはすぐにはログインできず、運営チームが承認するまで待ちます。すでに登録している会員には影響しません。
- 登録するとすぐ誰でもログインできるようにするには、新規サインアップに admin の承認を必須にする を無効にしておいてください。登録を一件ずつ確認したい場合は有効にしておいてください。
ソーシャルログインを有効にする
お客さまがどのアカウントで登録するかは Login Providers で決めます。Google、GitHub、Facebook、GitLab、LINE、Kakao、Naver をそれぞれ有効にできます。
ソーシャルログインは二つの場所をつなぐ作業です。その提供元側(Google なら Google Cloud Console)に自分のサイトを登録し、そこで受け取った値を WEEGLOO に入力します。Google を有効にすると、画面がこの二つの手順をそのまま案内します。
- Google を有効にしてください。二つの手順の案内が表示されます。
- Step 1 に表示される Authorized redirect URI をコピーして、Google Cloud Console の OAuth クライアントに登録してください。このアドレスは、ログイン結果をどこへ返すかを Google に知らせます。
- Google Cloud Console で発行された値を、Step 2 の Client ID と Client Secret の欄に入力してください。
- ほかのソーシャルログインも使う場合は、GitHub や Facebook も同じやり方で有効にして値を入力したあと、保存 を押してください。
有効にしたソーシャルログインが一覧に有効な状態で表示され、保存 まで終えると、お客さまがそのアカウントでログインできるようになります。
provider ごとに違うもの: スコープとメール
連携の手順は、どの provider でも上と同じです。リダイレクトアドレスを登録する欄の名前は provider ごとに少しずつ違います(承認済みのリダイレクト URI、コールバック URL、Redirect URI など)。名前が違っても、値は provider を有効にしたときに出る案内の Step 1 に表示されるアドレスをそのまま貼り付ければよいです。
下の表のスコープ(ログイン時にお客さまへ求める情報の範囲)は、WEEGLOO がログインの時点で provider にリクエストする値です。Google と GitHub はコンソールであらかじめ指定するものがなく、お客さまがログインするときに同意すればよいです。それ以外の provider はコンソールであらかじめ有効にしておくものがあるので、表で確認してください。
WEEGLOO は、お客さまがログインするときに provider からメールアドレスも一緒に受け取り、会員に保存します。同じ Space では、一つのメールアドレスで一度だけ登録できます。表に書かれた準備はそのメールアドレスを受け取るためのものなので、飛ばさないでください。二つの値を受け取ってくる手順は provider ごとに違うため、表の右端にある連携ガイドで画面とともに扱います。
| provider | WEEGLOO がリクエストするスコープ | provider のコンソールで事前に有効にするもの | 連携ガイド |
|---|---|---|---|
email, profile | なし | 連携する | |
| GitHub | read:user, user:email | なし | 連携する |
email, public_profile | アプリの Permissions and features で email を追加する必要があります | 連携する | |
| GitLab | read_user | アプリを作るときにスコープで read_user にチェックを入れます | 連携する |
| Kakao | profile_nickname, profile_image, account_email | ビジネスアプリに切り替えたうえで、メールの同意項目の使用承認が必要です | 連携する |
| Naver | email, profile, nickname | アプリを登録するときに、提供情報にメールアドレスを含める必要があります | 連携する |
| LINE | profile, email | チャネルでメールの権限を申請して承認を受ける必要があります | 連携する |
登録した会員を見る
お客さまが登録すると、その会員は サービス の ServiceLogin 下の Users で確認できます。ここで登録した会員の一覧を見て管理します。
先ほど 新規サインアップに admin の承認を必須にする を有効にしておいた場合、新しく登録した会員はこの画面で承認を待ちます。会員を有効にしてあげると、そのときからログインできるようになります。
同じ画面で、会員のログインを止めたり、一人の会員にだけ別の権限を与えたり、会員を名簿から外したりできます。それぞれの手順はサービス会員を管理するで扱います。
サイトが複数あるときの会員ログイン
一人の人が、まったく別のサービスをいくつも運営することもあります。服屋のぬくもりクローゼットを運営しながら、業種のまったく違う街角のパン屋まちかどベーカリーのサイトも一緒に切り盛りすると考えてみてください。二つのサイトは、訪れるお客さまも扱う内容も違います。服屋に登録したお客さまがパン屋の会員である理由はありません。
会員ログインは Space 1 つに 1 つずつ置きます。ですから、このように別々のサイトはそれぞれ Space を作り、その Space で会員ログインを別々に設定します。会員名簿も Space ごとに分かれ、服屋の会員とパン屋の会員は別々の会員として管理されます。
ある Space の会員ログインは、その Space で運営するサイトで使われます。1 つの会員ログインを複数のサイトに組み込んで一度に通す方式ではありません。会員に一度のログインで一緒に使ってほしい画面があるなら、その画面を 1 つのサイトにまとめてください。
次にやること
- 会員のロールと権限: 登録した会員が何を見て使えるかを定める ServiceUserRole を作り、上で選んだ デフォルトの Role につなげます。
- API リファレンス: 登録した会員のログインを自分のサイトのコードに組み込むには、公式のクライアント SDK やリクエスト形式といった技術仕様が必要です。会員が見て使うコンテンツをプログラムから直接扱うときの仕様もここで扱います。