You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 14, 2022. It is now read-only.
Wondering your thoughts on this. recently, my redis provider went down for a sec, and sent my app into a downward spiral of death. i've since added in better error handling for when the session isn't available, and also a check to see if first the req.csrfToken() function exists, so the app won't crash. is that pretty much the extent of it?
That's an interesting question, actually. It seems currently if your store is offline, then this module will pass the misconfigured csrf error down your pipeline to just 500. So, clearly if you are getting a POST and need to validate a token or add a token to a view, then you can't do much but 500, but otherwise, you could carry on, but doing a global app.use(csurf()) would prevent that from happening...
Your currently solution sounds fine to me, but I think we need to do something here to make this ess of a footgun.
What we can do is if the request doesn't qualify as one that needs validation (i.e. is a GET and not like a POST), then we can delay the error until the req.csrfToken() call. This would mean that even if you are using a global csurf(), requests that have nothing to do with CSRF tokens will still work out-of-the-box.
Wondering your thoughts on this. recently, my redis provider went down for a sec, and sent my app into a downward spiral of death. i've since added in better error handling for when the session isn't available, and also a check to see if first the
req.csrfToken()
function exists, so the app won't crash. is that pretty much the extent of it?and for sessions:
The text was updated successfully, but these errors were encountered: