Package com.iizix.server.user
package com.iizix.server.user
- ClassDescriptionThe registered e-mail address of an account: its one write, the rules of a change, its verified state, and the change the user asks for and confirms by a link (CC-ACCOUNT-EMAIL-PASSWORD).The delivery step of a mail:
Mail::queuein the server, a fake in the tests.Why a new address is refused.The mails about an account's e-mail address and password that are not a password reset (PasswordResetMail): the verification mail of an address and the confirmation link of a change of address the user asked for (CC-ACCOUNT-EMAIL-PASSWORD, AE-3 and SE-1), and the frame of the noticesAccountNoticescomposes - among them, since CC-FIX-SERVERADMIN-SD18-SD3 (SD-D-3), the notice to the old address of a changed address and the notice of a password an administrator set (AE-5), which were English-only texts here.The notice mails about changes to a user's account that are not the verification mail of an address or the confirmation link of a change of address - those areAccountMails- (CC-SERVERADMIN-SIGNOUT-DEVICES, the owner's rulings of 2026-10-13 05:01 and AM-1 of 05:09): every change to a user's account settings is told to the user by mail, in the user's language (English, French or Swedish), with what changed, when, from which client address and approximate place, by whom, and what to do if it was not the user.Who made the change.Where the change was made from: the client address and the approximate place, each null when unknown, the base of the links the mail carries - the origin the client session reached the server by, else the server's configured external URL (MailLinkBase, R-145), null when neither is known - and the device line the server has for the session (ClientDeviceName), null when unknown.What changed.What became of a notice.Handler class maintaining active user sessions.What an administrator changes on another user's account in ServerAdmin's Edit user (CC-ACCOUNT-EMAIL-PASSWORD, the owner's rulings AE-1 to AE-5 of 2026-10-11): the password and the registered e-mail address.The outcome of a sign-out of every device or a reset of the sign-in methods.What a sign-out of every device or a reset of the sign-in methods did.Ends the open sessions of a user in every application:UserSessionEnder.endAllin the server, a fake in the tests.The outcome of a change.The rule of who administers the server: a user in an ENABLED group namedGroupInfo.ADMIN_GROUP_NAME.What became of a real e-mail address an administrator entered (AdministratorAccess.setRealEmail(IAuthenticatedUser, String)).Instance holding data for the "authenticated" user.The device line the server has for a client session, from what the client says it is - never trusted, only shown: "Browser, Windows" for a Browser, "Apple iPhone15,2 (iOS 26.1)" for an iiziRun.The development-only reset of the administrator's sign-in factors (CC-SERVERADMIN-DEV-RESET, the owner's rulings RS-1 to RS-7 of 2026-10-08): a development server started with the system property-D"com.iizix.serveradmin.reset"="1" deletes, at every start while the option is set, what keeps everyone but the enrolled person out ofiiziAdmin- so that a rig, a second person or a Browser check can sign in to ServerAdmin on a developer's server once more.What a start did.What a start did, with the count per kind of what went.The device tokens: what a device holds instead of a password to sign its user in again, and to be trusted for MFA (CC-LOGIN-L5-DEVICE-TOKEN, SignIn L-5 = HUB-DESIGN 7.7 and 14 row B-6e, R-22; the owner's rulings T-3, RB-4 (a) and RB-5 (a)).A token as issued.What became of a presented token.What a presented token is.The generated initial password of an administrator of a built iiziServer (CC-ADMIN-FIRST-PASSWORD, the owner's rulings AP-1 to AP-7 and BK-1 to BK-3 of 2026-10-08): a built server never runs with the public administrator password ofcreateBaseTables.sql.The licence counter of a standalone iiziServer (LICENSE-V2-DESIGN.mdsections 6.1 to 6.3, 6.5 and 8.4; rulings R-6, R-19, LV-14, LV-15, LV-17, LV-19, RB-9 (a), T1-155): the users the server counts against its licence document'smaxUsers, the verdict for a new user, and the daily peaks the license server is told at every REFRESH.The verdict for one sign-in of a user not counted yet.Why a verdict is not a plainLicenseCounter.Verdict.ALLOW.What ServerAdmin shows (T1-154): the licence state, the users againstmaxUsers, the grace and what a new sign-in would meet now.The verdict for a sign-in of a user not counted yet (HUB-DESIGN 9.2'sLoginVerdict).The delivery of a mail a user is waiting for (CC-FIX-SIGNIN-ACCOUNT-MAIL): the mail is SENT now, not queued, so that the answer the user reads follows what the relay did - "Sent" when the relay accepted it, "not sent" with the reason when it refused it or could not be reached.The base URL of every absolute link the server mails for a client session (R-145, CC-FIX-SIGNIN-ACCOUNT-MAIL): the ORIGIN the client reached the server by - the scheme, the host name the Browser used and the client's port, as the web server read them of the connection at the WebSocket upgrade (SessionInfo.getExternalBaseURL(); a LAN client gets a LAN link, a client behind the front-end proxy gets the proxy's name and scheme) - and only when the session has none, the server's configured external URL (ServerShell.getExternalWebServerBaseURL(), which reads the thread's session first and the settingexternalHostNameafter it).Resets a user's password and mails the new one to the user's own registered e-mail address, and to nobody else.The reset step:BasicUserInfo::resetPassword.The send step:Mail::send.The accounts a self-service password reset names, and the one reset link mailed per account (EM-D-1, CC-FIX-SIGNIN-ACCOUNT-MAIL): the identifier the user typed names an account by its user name, else EVERY account that holds it as its registered e-mail address - a shared address is allowed (a personal account and an administrator account behind one support mailbox), and each account gets its own link, in a mail that names the account ("Dear"). The check of the administrators' passwords at every start of the server (the owner's rulings SA-2b and SA-2b-2 of CC-SERVERADMIN-SIGNIN, 2026-10-02; AP-1 to AP-7 and BK-1 to BK-3 of CC-ADMIN-FIRST-PASSWORD, 2026-10-08).An administrator found with the password of the script, and what was done.What the check did for an administrator found with the password of the script.What a check found and did.Holds back a client source - the remote address a sign-in attempt comes from - that has failed too often: at mostSourceThrottle.MAX_FAILURESfailed attempts per source in a window ofSourceThrottle.WINDOW_MS, after which every attempt from that source is refused until the window ends, whatever the user name.Helper class to perform user authentication.User authentication information with the authentication result.The request class for a User Profile Image.The URN User Profile Image Provider singleton class.The URN User Profile String Provider singleton class.Ends every open session of a user in every application of this server, as the user's own sign-out ends the one session it is made in (CC-SERVERADMIN-SIGNOUT-DEVICES, DV-1): every client of such a session is told to load the application again - which gives it a new session in which nobody is signed in - and the session is disposed of, at once when it has no client to tell, afterUserSessionEnder.GRACE_MSotherwise, so that what the clients were sent reaches them before their connection is closed.The UserSessions contains information about all sessions being run by the same user in the same application.The verification mail of a user's registered address, on the user's request (CC-FIX-SIGNIN-ACCOUNT-MAIL: "Resend" of S10 and of Account, the administrator's address of S32): the one engine behindIUserAuthenticationUI.resendVerificationMail, so that its outcome is what the screen says.What became of the request.The result: the outcome, why nothing was sent (null when sent), and whether the pending verification was created by this request.