A login stores the username in the session cookie, which cannot carry a value past about 4096 bytes, so a username of about 2 KB or more could never log in and the login answered 500. Usernames are now limited to 1024 bytes, about half of what the cookie can carry. The User model rejects a longer one with ErrUsernameTooLong, and a check constraint on the users table rejects it for any path that bypasses the model. The comment on MaxUsernameBytes gives the arithmetic. Model: opus-5-5
This commit is contained in:
@@ -339,11 +339,9 @@ const storedUserPassword = "correct-horse-battery-staple"
|
||||
// storedFillBytes is the raw length of the client-chosen value in
|
||||
// those accounts' usernames. It is well past the 512-byte field
|
||||
// budget, so the line is still truncated, but short enough that the
|
||||
// session cookie a successful login writes stays inside
|
||||
// securecookie's 4 KB limit: the cookie is written BEFORE the
|
||||
// "user logged in" line, so an 8 KB username answers 500 and never
|
||||
// reaches it.
|
||||
const storedFillBytes = 1024
|
||||
// whole username, markers and fill name included, stays within
|
||||
// database.MaxUsernameBytes.
|
||||
const storedFillBytes = 960
|
||||
|
||||
// storedFill builds a username fill of storedFillBytes raw bytes out
|
||||
// of repetitions of ch, with both markers at its far end.
|
||||
|
||||
Reference in New Issue
Block a user