| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
| |
This is, again, groundwork for logic that requires more than just a database connection.
The login process has been changed to be more conventional, attempting login _before_ account creation rather than after it. This was not previously possible, because the data access methods used to perform these steps did not return enough information to carry out the workflow in that order. Separating storage from password validation and hashing forces the issue, and makes it clearer _at the App_ whether an account exists or not.
This does introduce the possibility of two racing inserts trying to lay claim to the same username. Transaction isolation should ensure that only one of them "wins," which is what you get before this change anyways.
|
| |
|
|
|
|
| |
This is a jumping-off point for adding logic that needs more than just the DB for state, such as chat message handling.
The name sucks, but it's the best I've got.
|
| |
|
|
| |
the value in that record used to verify logins.
|
| |
|
|
|
|
|
|
| |
issued.
This lets us shorten the expiry interval - by quite a bit. Tokens in regular use will now live indefinitely, while tokens that go unused for _one week_ will be invalidated and deleted. This will reduce the number of "dead" tokens (still valid, but _de facto_ no longer in use) stored in the table, and limit the exposure period if a token is leaked and then not used immediately.
It's also much less likely to produce surprise logouts three months after installation. You'll either stay logged in, or have to log in again much, much sooner, making it feel a lot more regular and less surprising.
|
| |
|
|
|
|
|
|
| |
1. Stop rejecting login attempts when there's an identity cookie already set.
This looked like a good idea, but in practice it's not a sufficient check, as it doesnt' ensure the identity cookie is actually valid. Validating it is an option, but the do-nothing alternative (which I went with) is that a login request while already logged in overwrites your identity cookie, instead. It's less code, semantically not bonkers, and doesn't _appear_ to introduce any interesting user security issues.
2. Redirect to / after successful login/logout, instead of dropping the user on a useless text page.
|
| | |
|
|
|
valid or not.
This is mostly a proof of concept for the implementation of form login implemented in previous commits, but it _is_ useful as it controls whether the / page shows login, or shows logout.
From here, chat is next!
|
