Skip to main content

Website sign-in

A user signs in on the website with an email address and password, or with a phone number and a one-time code sent by SMS. Either way the website keeps the resulting Supabase Auth access token in the browser and attaches it to calls to the application API. The API's side of this exchange is described in Authentication.

User journey​

Email and password​

  1. The user opens the sign-in page and enters an email and password.
  2. On success the forms are replaced by a Sign out action and the role actions below.
  3. On failure the user stays on the form. The page does not tell the user whether the email or the password was wrong, or why sign-in failed.

Phone number​

  1. The user enters a phone number in international format, such as +380501234567, and chooses Send code. Spaces, brackets and dashes are ignored.
  2. The user enters the code from the SMS and chooses Sign in. A first sign-in with a number creates the Supabase Auth user, so the same flow signs up and signs in.
  3. Send a new code is available after a one-minute cooldown, and Use another number returns to the first step.

The page shows a fixed message when a number is malformed, too many codes were requested, phone sign-in is unavailable, or a code is wrong or expired. It never shows the auth service's own error text. A malformed number is rejected in the browser without contacting Supabase.

After sign-in​

Signing in grants no professional or client access by itself. A signed-in user gets two explicit actions:

  • Become a professional enrolls the user as a professional (POST /users/me/professional-enrollment). Professional routes are refused until this succeeds or the user has enrolled through the professional Mini App.
  • Create client account creates a client account whose verified phone is the one Supabase Auth confirmed during phone sign-in (details). An email user sees a prompt to sign in with a phone number instead.

Choosing Sign out ends the Supabase session, discards the access token, and returns the sign-in forms with empty fields.

OAuth, magic links, MFA and Telegram login are not offered on the website.

Website and Telegram accounts are separate​

A phone sign-in creates its own Supabase user. It is not linked to a Supabase user created by a Telegram Mini App launch, even when the Telegram client shared the same phone. The two identities have separate professional enrollments, client accounts, appointments and claims. Signing in with the same phone never selects or merges the other account.

Linking the two needs proof of both identities in one flow, and it is not available. An approach has been chosen for a later change, but nothing of it is built: confirming a phone on the Telegram-created user from the Mini App, and, when the website account came first, a single-use link code opened in the Mini App. Until that ships, treat the website and Telegram accounts as different people.

Local phone sign-in also does not work yet; see Configure phone sign-in.

Boundaries​

  • Browser only. The sign-in interface is client-side. The Nitro server does not read the session and stores no authentication secret.
  • Public configuration only. The browser needs the Supabase project URL and anon key (NUXT_PUBLIC_SUPABASE_URL, NUXT_PUBLIC_SUPABASE_ANON_KEY) and the API base URL. The service role key and JWT secret never belong in the website. See Environment variables.
  • No direct data access. The Supabase client is used for sessions only. Any request to its database endpoint (/rest/v1) is refused in the browser, so business data is read and written only through the application API.
  • Bearer header. The website's API client sets Authorization: Bearer <access_token> when a session exists and removes the header when it does not.
  • Unavailable auth. If the public URL or anon key is missing, sign-in always fails, phone sign-in reports itself unavailable, and sign-out does nothing.

Feature structure​

The slice follows Feature-Sliced Design:

  • features/sign-in holds the email form and the sign-out action.
  • features/phone-sign-in holds the two-step phone flow.
  • features/professional-enrollment and features/client-account-setup hold the two role actions.
  • pages/sign-in composes these and tracks whether the visitor is signed in.
  • The route under app/routes only mounts the page.
  • The auth client lives in shared/auth and the API client in shared/api.

Rollout requirement​

The Supabase project must allow email-and-password sign-in with email confirmation turned off. With confirmation on, a correct password does not return a session and the website treats it as a failed sign-in. Phone sign-in needs the Phone provider and an SMS provider; see Configure phone sign-in.