Package com.iizix.user
package com.iizix.user
- ClassDescriptionProvider interface to retrieve an authenticated user for a client or application session.The form of an e-mail address the server and the SignIn module accept (CC-ACCOUNT-EMAIL-PASSWORD): one "@" with something before it, a domain with a dot after it, no whitespace, at most
EmailAddressForm.MAXIMUM_LENGTHcharacters - the check the SignIn module's sign-up has made since L-10a, in one place for every caller that takes an address (the sign-up, the change of address, ServerAdmin's Edit user).The state of the registered e-mail address of a user, asIUserAuthenticationUI.getEmailVerificationState(IClientSessionGyro)answers it (CC-LOGIN-L10A1-SERVER-GAPS, gap G-3 of the SignIn flow design): the address, and whether the user has verified it by opening the mailed link.The status of the address.Interface holding data for the "authenticated" user.Provider interface to retrieve an authenticated user for a client or application session.Details stored in the server database as details for a user.Login result from the user authentication engine.The proof that a sign-in verified a second factor: the MFA proof of HUB-DESIGN 7.4 (ruling RB-11),{method, verified, age}.A passkey of a user as the SignIn module shows it in "Sign-in & security": what the user needs to tell the passkeys apart, and no key material (CC-LOGIN-L8-PASSKEYS).The outcome of a passkey registration (CC-LOGIN-L8-PASSKEYS): the new passkey, and the sign-in the registration completed when the sign-in was waiting for a passkey (SigninResult.SUCCESS_PASSKEY_ENROLMENT_REQUIRED).Class holding profile picture information either in a URL or asInputStreamin case of OAuth 2.0 requirements to load the URL in an authenticated session.The User identifier class holds the information about a user or a returning user.A device a user is remembered on: one row of the user's device tokens, as the SignIn module lists them for the user to look through and to revoke (CC-LOGIN-L5-DEVICE-TOKEN, SignIn L-5; F-18 of the SignIn survey).The ways a user signs in, as the user's own pages and the second step of a sign-in show them (SignIn L-6; gap G-7 of the SignIn flow design): what is enrolled, since when, how many recovery codes are left - and never a secret: no setup key, no code, no hash.One second factor of a user.The entry of a user's authenticator app, as the app shows it: the issuer and the account of theotpauth://URI the enrolment's QR code carried (CC-FIX-SIGNIN-RECOVERY).The sign-in policy of an application: what the server environment sets, with what the application overrides (SignIn L-6; section 5 of the SignIn flow design, its decisions D-11, D-20 and D-31).What the policy says of the second factor.Enum for user sign in result.What a user needs to enrol an authenticator app as the second factor: the QR code to scan, the link that opens the app on a phone, and the setup key for an app that does neither.User exception class used when a user is not permitted an action.The User identifier class holds the information about a user or a returning user.The base of user information in the database.Locale strings for operations dealing with a user.Class holding the User Profile information, when signing in externally typically for an OAuth(2) authentication service provider, or when signing up internally (and externally).