Store CSRF token in a cookie #331
No reviewers
Labels
No labels
Component: User interface
Component: Wymeditor
Help wanted
Level: Difficult
Level: Easy
Level: Moderate
Pagetype: Festival
Pagetype: Mailinglist
Pagetype: Peer reviewed article
Pagetype: Text
Privacy GDPR AVG
status: has conflicts
Status: Needs changes
Status: Needs discussion
Status: Needs review
Status: Ready to merge
Status: Waiting for response
Type: Bug
Type: Enhancement
Type: Question
Usecase: De Stadsbron
Usecase: Koppelting
Usecase: MeetjeStad
Value: Coders
Value: Security
Value: Users
Value: Visitors
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
harmen/hypha!331
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "csrf-in-cookie"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This is a subset of PR #316, with just the commits needed to move the CSRF token into a cookie. This was originally just a cleanup, but it has since been shown that having the CSRF token in the session can cause dataloss when visitors submit a (lengthy) comment and the session has expired since they first loaded the article page. In that case, the CSRF token will be invalid and the request rejected rather forcefully, losing the submitted comment.
Moving the CSRF token to a cookie ensures that the token survives until the browser closes, which should prevent this dataloss.
Would it make sense to add this global/static var to
$O_O?Feels weird to have such a state variable lying around :-)
r edundant parentheses (non blocking comment :-) ) maybe triple
===?namingwise I would expect get to be just a getter (not meddling with state) the regeneration breaks that expectation. Maybe getOrGenerateCsrfToken / retrieveCsrfToken?
redundant parentheses, maybe triple ===?
Hm, I'm not so sure. This sneakily hidden state is not ideal, exposing this state globally through
$O_Odoes not seem correct either: This is really an implementation detail ofexecutePostedCommand. I think it would be good to just keep it like this now, and fix this in a future refactor (the way post commands are handled is expected to change anyway, once all datatypes are converted to the "new style").I like extra parenthesis to emphasize what is being returned, though thinking about it, I can't really put down in words why it would actually help :-) I guess it's a habit that's more relevant when assigning an expression to a variable, not really needed for return. Triple === is a good idea.
Good point, fixed.
Fixed.
Fixed.
Thanks for the review. I've fixed most of your comments. I also noticed a missing
global $O_O;that broke login (it got left behind splitting off commits into this new PR), that's also fixed now.Cool, just wanted to double check :-)
I did a bit more testing, and will merge this now.