DACore · coming December 2026

How DACore login, 2FA, and devices work

DACore’s first job is a session you can trust. Email and password hit a signed POST, the account status is checked, two-factor can stand in the way, lockout slows guessing, and every browser can be listed and revoked. You do not rebuild that in a Shop module. You consume it, then gate your routes with your own rights middleware. Framework Auth still exists underneath — see the AI blog on authentication and 2FA. DACore is the product UI and the extra guards around it.

Common mistakes

Login flow

Routes live under the configured prefix (fallback /dacore). POST bodies on that prefix go through #DACore:AuthTest@check! so the signed channel is required, the same family of check as <fo-rm> on the public site. Email and password are verified through framework Auth::login, including remember-me when you allow it. Inactive accounts (status !== 1) are logged out immediately. An IP that the user’s IP firewall rejects never gets a session — the Auth layer returns that as a dedicated error. Hooks DACore.login.before and DACore.login.after exist if another module must annotate the attempt without forking Login.php.

Two-factor

A user record can enable TOTP (authenticator app), email OTP, and SMS OTP. Enrollment uses a QR code with configurable colors; you can show the secret as text when the operator needs a manual entry. After password success, Auth::loggedStage() == 2 means the TOTP (or email) step is still required. Dangerous plugin installs can demand a second step-up (TOTP, email, or SMS) even though the operator is already logged in — that challenge is not “confirmTwoFactor while already fully logged”. PHP verifies the code before the ZIP is applied.

Registration of a new user can pre-enable email + TOTP with an unconfirmed secret so the first login finishes enrollment instead of shipping an unprotected admin.

Lockout and audit

LoginGuard plus settings in dacore_settings cap attempts per IP (default three) and lock for a configurable number of minutes (default fifteen). Every attempt is stored: email, IP, user agent, a short browser label, success or reason. Super-admins get a global login log. That is the difference between “we have 2FA” and “we can see who tried the door”.

Session guard

After login, every authenticated request under the prefix runs UserRuntime::enforceSession(): account still active, current device not revoked, URL firewall allows this path, last-seen stamp updated. Permissions can refresh from the database on a timer (default 300 seconds) without forcing a full re-login, then fire DACore.permissions.refresh. If an admin deactivates a user, the next request ends the session. You do not wait for the cookie to expire.

Devices

Each browser gets a device UID in a DSM namespace. On login DACore inserts a row: session id, copy of the remember-me token, IP, user agent, an automatic “browser · OS” label, optional custom name, created and last seen, revoked flag. Operators list devices on “My devices” or on a user detail tab. Revoke drops the remember-me token and the guard will reject that browser. Login history can attach IP geolocation (cached) so a strange country is visible without building a geo product yourself.

What your module does

Nothing in this list is copied into Shop. Shop assumes Auth::isLogged() === true on admin routes, then asks whether the user has Shop.orders.edit. Device revoke, lockout, and 2FA enrollment stay DACore screens. If you need a second confirmation before deleting an order, follow AIRULES: overlay is UX, PHP verifies.