ores.iam.signup_messages
Table of Contents
The signup protocol messages.
The response is the door's answer. The policy behind it — the switch, the tenant
a registration lands in, and the party and role a new account receives — is
settled in
registration and onboarding
defaults, and the path the call takes is
the entry journeys. The read that
tells a screen whether to offer the form at all is a separate subject,
iam.v1.ops.registration_policy.
1. Includes
#include <string>
2. Messages
2.1. signup_request
2.1.1. principal
2.1.2. password
2.1.3. email
2.1.4. hostname
/** * @brief The address the registration arrived at. * * The address names the tenant the account lands in: the service resolves * it by hostname and uses the tenant flagged @c is_registration_default * only when the address names none. Without it a registration lands in the * system tenant by omission, which is the defect the survey found. */
2.2. signup_response
2.2.1. success
2.2.2. message
2.2.3. account_id
2.2.4. account_status
/** * @brief The state the account was created in: @c active or @c pending. * * An account is active when its tenant nominated a default party, so it * received an association and can sign in at once. It is pending when the * tenant nominated none: the account exists, but it waits for an * administrator to finish setting it up. */
2.2.5. party_id
/** * @brief The party the account received, when the tenant nominated one. * * Empty when the account is pending, because a pending account has no * association yet. */
2.2.6. role_id
/** * @brief The role the account received: the tenant's nominated default. * * Empty when the tenant nominated no role. */
2.2.7. error_code
/** * @brief The stable code a client branches on. * * Empty when the registration succeeded. The message beside it is for a * person and may change; this is what a screen branches on, so a refusal is * a value rather than a sentence to match. The codes a registration can * answer with are collected on the Entry journeys page. */