-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
Run session token renewals in a database transaction #34379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run session token renewals in a database transaction #34379
Conversation
|
@ChristophWurst please fix for php-cs |
The session token renewal does 1) Read the old token 2) Write a new token 3) Delete the old token If two processes succeed to read the old token there can be two new tokens because the queries were not run in a transaction. This is particularly problematic on clustered DBs where 1) would go to a read node and 2) and 3) go to a write node. Signed-off-by: Christoph Wurst <christoph@winzerhof-wurst.at>
c721b4e to
c5922e6
Compare
|
@ChristophWurst @PVince81 how far back would we want to backport this? Asking since this might help with some large scale installations but might also hurt some in cases were long(er) running transactions might cause issues with raising the probability of deadlocks in a cluster setup. |
|
The used API exists since 24 |
|
Wrapping these related queries in a query is one of the proposed solution we received from the mariadb experts. Write and delete will always run on the main database node. The transaction will only cause the read to happen on the same. I think this should be fine. |
|
@ChristophWurst can you cover a backport to 24+ then? Thanks in advance 🙏 |
|
/backport to stable25 |
|
/backport to stable24 |
The session token renewal does
If two processes succeed to read the old token there can be two new tokens because the queries were not run in a transaction. This is particularly problematic on clustered DBs where 1) would go to a read node and 2) and 3) go to a write node.
Wrapping this code in a transaction makes sure that it all goes through or the insert/delete never happen, as it should.
This problem came up in a discussion with @rullzer.
This is best reviewed as https://github.com/nextcloud/server/pull/34379/files?w=1.