openhands
179484642f
Gitea Actions Runner Test / test-job (push) Successful in 2s
CI / check (push) Successful in 28s
CI / tests-integration (push) Successful in 1m42s
CI / tests-unit (push) Failing after 1m45s
CI / tests-ui (push) Successful in 2m29s
CI / preflight (push) Skipped
CI / deploy (push) Skipped
Closes the four HIGH/MEDIUM items left open after the previous pass. Login lockout - The only login limits were keyed on the client IP, so a distributed attempt could grind on one account indefinitely. Added a per-account lockout with a budget of 8 failures per 15 minutes. - The bucket is keyed on the RESOLVED account id, not on the submitted string: users may sign in with either username or e-mail and neither the lookup nor the input normaliser folds case, so an input-keyed bucket would hand out a fresh budget per spelling of the same account. - precheckLogin and NextAuth's authorize share the bucket, so the pre-check cannot be used to buy extra attempts and a client that skips it entirely is still bounded. Both check the lockout BEFORE verifying the password: the success path clears the counter, which would otherwise walk a locked account straight back in on the right password. - A successful login clears the failures, which needs two new primitives in rate-limit.ts: peekRateLimit (read-only, does not consume a unit) and clearRateLimit. - Fixed a latent inconsistency while doing so: the in-process bucket capped its counter at the limit while Redis' INCR kept climbing, so the two backends disagreed about how far over the limit a key was. Both now track the true count. Mail lookup index - Added an index on users.mail (0035). Password reset, e-mail verification and the resend cooldown all resolve a single account from a submitted address and were full table scans of `users`. Deliberately non-unique: legacy rows can hold the same address more than once, so a unique index would fail to apply. Resend captcha - /verify's resend form triggers real outbound mail and was reachable with only a cooldown. It now runs the configured captcha before the account lookup and before any send. Client message payload - The root layout serialised the whole catalogue into every page. pages.admin and admin are ~177 KB of the ~235 KB and are unreachable from the public route group, so that layout now installs its own provider with the staff namespaces removed. Nested providers replace rather than merge, which is why this has to live in the segment layout. /admin, /mod, /client and /admin-next keep the full set; a guard test fails if a public page ever references a staff namespace.
19 lines
1.0 KiB
SQL
19 lines
1.0 KiB
SQL
-- 0035_users_mail_index.sql
|
|
-- Index on users.mail.
|
|
--
|
|
-- The authentication paths all look an account up by mail: password reset,
|
|
-- e-mail verification, duplicate-address detection and the verify/resend
|
|
-- cooldown all resolve a single user from a submitted address. Without an index
|
|
-- each of those is a full table scan of `users`, which grows with every
|
|
-- registration.
|
|
--
|
|
-- Deliberately NOT unique. Legacy rows predate the duplicate-address handling
|
|
-- and can legitimately contain the same address more than once, so a unique
|
|
-- index would fail to apply on an existing database. The lookup is made
|
|
-- deterministic by ordering on `id` (see requestReset / the verify page), which
|
|
-- is stable without the index and correct with it.
|
|
--
|
|
-- The column is VARCHAR(500), which exceeds the 767-byte InnoDB prefix limit on
|
|
-- older row formats, hence an explicit 191-character prefix: enough to make the
|
|
-- lookup selective and still indexable everywhere.
|
|
CREATE INDEX IF NOT EXISTS `users_mail_index` ON `users` (`mail`(191)); |