Registration and Login

AccountsService gives a downcity the shared account infrastructure, but email registration and login are available only when an email accounts provider is mounted and configured.

Before rendering an email form, ask the server which providers are enabled:

const providers = await guest.service("accounts").get("providers");

Render email registration or login only when the response contains an enabled email provider with type: "input". The form fields can come directly from that provider's inputs.

register

const session = await guest.service("accounts").action("register").invoke({
  email: "[email protected]",
  password: "password123",
  bureau_id: "demo",
});

login

const start = await guest.service("accounts").action("login/start").invoke({
  provider: "email",
  bureau_id: "demo",
});

await guest.service("accounts").action("login/continue").invoke({
  login_id: start.login_id,
  input: {
    email: "[email protected]",
    password: "password123",
  },
});

const session = await guest.service("accounts").get("login/result", {
  login_id: start.login_id,
});

Why bureau_id is included here

Because after successful login or registration, the service will usually request Federation to issue a user_token for that Bureau context.

So it needs to know:

• which downcity is currently being entered
• which downcity context the token should be issued for

What happens after login succeeds

Do not keep using the guest client forever. Switch into a normal user-context client:

const user = new City({
  role: "user",
  city_url,
  user_token: session.user_token,
});