Elanoryaアカウント
登録フォームの送信は、セッションではなく確認ステップへの引き渡しです
このアプリでは、登録とサインインは別々の出来事です。登録の呼び出しはアカウントを作成し、確認ステップへ送ります。セッションが確立するのは、確認コードが受理されたときです。その途中でアプリを閉じても、もう行き止まりにはなりません。登録に使ったメールアドレスが端末に記憶されているからです。
登録の呼び出しが行うことと、やり残すこと
ふだんは一緒に届く二つの出来事が、ここでは別々です。両者を切り分けておけば、画面がその後に行うことはすべて説明がつきます。
- 呼び出しはアカウントを作成します。
- その部分は送信の時点で完了します。もう一度送信するものは残っておらず、フォームを再送しても残りの手順は進みません。
- 呼び出しはセッションを確立しません。
- セッションは後から、確認コードが受理されたときに来ます。apps/jewelry-mobile/src/features/auth/auth-provider.tsxの登録呼び出し「await apiRegister(email, password)」の箇所で確認しました。
- 引き渡しは意図されたもので、テストもあります。
- 登録画面のテストは、送信が成功した後に「'/(auth)/verify'」へ移動することを期待しています（apps/jewelry-mobile/src/features/auth/register-screen.test.tsx）。そこへ着地する画面は、仕様どおりにふるまっています。
- ビルドが備えている場合の外部アカウントでのサインインは、この形をとりません。
- その経路は二段ではなく一段でアカウントの確定を済ませます。特定のビルドがそれを備えているかどうかは、このページでは述べません。
- 確認せずに戻っても、締め出されはしません。
- 確認ステップを離れたユーザーも、未確認の状態のままアプリに入れます。その状態で何が許されるかは別の主題であり、ここでは開きません。
確認画面と、すでに持っているメールアドレス
確認画面は、誰を確認しているのかを知っていても知らなくても働くように書かれています。メールアドレスが分かっているときはコードだけを尋ねます。すでに持っているものを尋ね直すのは無駄な打鍵だからです。分かっていないときは、先にメールアドレスの入力欄を出します。これがあるおかげで、フォームから直行したのではなく画面へ直接たどり着いた人でも使えます。
どちらの表情も同じ画面で、どちらになるかはメールアドレスが手元にあるかどうかで決まります。二人の出品者がこの手順を違うふうに説明し、どちらも正しいということが起こるのは、そのためです。
メールアドレスは二つの手順の間、端末に保持されます。その保存の脇にあるコメントが、何を置き換えたのかを記録しています。以前は、一度の作業で確認を終えられなかったユーザーに進む道は一つしかなく、それは最初から登録し直すことでした（apps/jewelry-mobile/src/features/auth/pending-email-storage.tsで確認）。ですから、アプリを閉じる、電話に出る、登録の途中で端末を置く、といったことで失われるのはコードの入力であって、登録ではありません。
保存されたメールアドレスが、その端末上でアカウントより長く残ることはありません。サインアウト時と、アカウントが削除されたときに消去されます。人に渡した端末が、この手順で前の持ち主のメールアドレスを差し出すことはありません。
確認ステップへのたどり着き方と、残っている作業
以下の行はすべて同じ画面です。違うのは、たどり着いた時点で画面が何を知っているかだけです。
| たどり着き方 | 画面が表示するもの | まだ必要なこと |
|---|---|---|
| 登録フォームから直行した | コードの入力欄。登録したメールアドレスはすでに把握されている | コードを入力する。受理された時点でセッションが確立する |
| 登録と確認の間にアプリを閉じた | 同じコードの入力欄。メールアドレスは端末から復元される | コードを入力する。登録のやり直しは不要で、効果もない |
| アプリがメールアドレスを持たない状態で画面に着いた | コードの入力欄の前に、メールアドレスの入力欄 | メールアドレスを入力し、その後にコードを入力する |
| 確認せずに戻った | アプリ本体。アカウントは未確認の状態 | 確認は未了のまま。その状態は専用のページで説明されている |
引き渡しが読み違えられる場所と、その代償
どれもセッションで終わらなかったフォームについての無理のない推測ですが、それぞれに具体的な代償があります。
確認画面に着いた後、登録フォームをもう一度送信する。
アカウントは最初の送信で作成されています。確認画面のまま先へ進めてください。二度目の登録が生むのはセッションではなく、二つ目のメールアドレスです。
途中でアプリが閉じたので、最初からやり直す。
画面を開き直すと、メールアドレスは端末から復元されます。残っているのはコードの入力だけです。
メールアドレスの入力欄を、前の手順が失われた証拠と読む。
入力欄は、画面がまだメールアドレスを持っていないときにだけ現れます。それはたどり着き方についての言明であって、その前に何が起きたかについての言明ではありません。
アカウントが生きていると信じる前に、ウェルカム通知を待つ。
通知は新規の登録または初回のサインインに属し、一度だけ表示されます。アカウントがすでに存在していたとサーバーが伝えた場合は、まったく出ません。
次の人が「そのまま続けられる」ように、共用の工房端末でセッションを残しておく。
保存されたメールアドレスはサインアウト時とアカウント削除時に消去されますし、次の人は自分自身として登録するかサインインするべきです。
このページが立てる主張の限界
ここでの根拠は、モバイルクライアントの登録と確認のふるまいです。次のものはその外側にあります。
- メールアドレスが未確認のあいだ、アカウントに何ができて何ができないか、そして再送の操作がどうふるまうか。どちらも未確認の状態に属し、専用のページで説明されています。
- セッションを持たない段階でどの画面が開くかを決める遷移の規則。これは別の主題であり、ここでは述べ直しません。
- 確認に関するパラメータ全般。コードの長さ、コードが使える時間、許される試行回数。いずれもサーバー側にあり、クライアントからは読み取れません。
- ウェルカム通知が表示しうる金額、パッケージ名、価格、通貨。このページは通知とその二つの調子に名前を与えるだけで、通知が伝える内容には触れません。
- そもそもビルドが外部アカウントでのサインインの経路を備えているかどうか。一段で済む形を条件つきで述べているのは、出荷されたビルドがどの提供元を持つのかをクライアントのコードが明かさないためです。
- アカウント削除がサーバー側で何をするか。ここで述べる削除の影響は端末上のものだけで、保存されたメールアドレスが消去されることに限られます。
よくある質問
登録フォームを完了したのに、アプリがサインインさせてくれません。失敗したのでしょうか。
いいえ。登録の呼び出しはアカウントを作成し、セッションを確立しないまま返ります。その後、登録画面が確認ステップへ送ります。セッションが確立するのは確認コードが受理されたときなので、サインインしていないのは手順の設計であって、エラーではありません。
登録してからコードを入力するまでの間にアプリが閉じました。登録し直す必要がありますか。
いいえ。登録に使ったメールアドレスは端末に保存され、確認画面が復元します。残っているのはコードの入力だけです。メールアドレスが保持されるようになる前は、この状況を抜ける唯一の方法が登録のやり直しでした。
確認画面がメールアドレスを尋ねてくるのはなぜですか。
メールアドレスの入力欄は、画面がまだアドレスを持っていないときにだけ表示されます。これがあるおかげで、画面へ直接たどり着いた人でも確認を終えられます。アドレスが分かっているときは、入力欄はまったく表示されません。
確認の後、ウェルカムメッセージを見ませんでした。何か見落としたのでしょうか。
ウェルカム通知は新規の登録または初回のサインインに結びついており、二つの調子のいずれかで一度だけ表示されます。再訪のユーザーは目にしませんし、アカウントがすでに存在していたとサーバーが伝えた場合はまったく現れません。