Class SeedPasswordCheck

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).

The users a new database is given (createBaseTables.sql) have passwords that are written in that file, so everyone who has the product knows them. The comment table of the script documents them, and a second table the users the script no longer inserts but a database made by an earlier version still has. For every such user that is a member of the administrators group and still has that password, a BUILT server (Tycho, Jenkins, shipped, signed or not)

• replaces the password of iiziAdmin by a generated one (AP-1), hashed as every password is, that the account must change at its next sign-in (AP-2, change_pw); the password is shown once on the console and written to InitialAdminPassword.FILE_NAME in the server's working directory, readable by the server's account only (AP-3);
• DISABLES the former seeded backup administrator iiziAdmin BACKUP (BK-2; not deleted; a database made since 2026-10-08 has no such account, BK-1);
• makes the next sign-in of any other such administrator change the password before anything else, as before;
• DISABLES, the same way, a seeded user that is no administrator (user, iiziRun Developer, iiziRun Developer 2) that still has its public password (SG-4 (a), CC-FIX-SIGNIN-V5-REPAIRS, 2026-10-13): an application that admits the group Default would admit it with a documented password. To use such an account, give it another password in ServerAdmin;

each with a WARNING naming the account - never a password - at every start. Until the change the account reaches no page of ServerAdmin (AdministratorAccess.sessionRefusal(IAuthenticatedUser)). A start that finds the file of an earlier start while the account no longer has that password deletes it.

Development mode (SystemConfig.isDevelopmentMode, code run from Eclipse, not built into jars) is a developer installation that keeps the public passwords on purpose (AP-6, BK-3): the WARNING is still logged, but nothing is generated, nothing is disabled, the change is not forced, and a change_pw an earlier start set on such an account is cleared. A seeded user that is no administrator is not even named: a developer installation keeps the three development users on purpose (APP-D-14).

The way back that proves access to the machine (AP-5): the start option -D"iizi.admin.reset"=<account> generates a new password for that administrator at the start, in either mode, shown and written as above, the forced change set and a lock-out cleared; it is ignored with a WARNING when the account is not a member of the administrators group.

The passwords are read from the comment tables of the script, where the ruling lets them be, and are compared through the hash the database holds: no password is in this class, and none is logged. An account whose password was changed is not named again.