Replies: 2 comments
-
I couldn't remember, so I looked up the pull request. I think initially, I only did a cookie response. I'm guessing things used to do both, based on this comment: https://github.com/Flask-Middleware/flask-security/pull/401#pullrequestreview-509748462 I really only use cookies, due to security reasons like you said, so it makes sense to remove returning the token as a response. |
Beta Was this translation helpful? Give feedback.
-
Thanks for your quick reply - so I was the one confused back then! I think I will remove it as part of the upcoming release which has a few other small backwards incompatible changes. |
Beta Was this translation helpful? Give feedback.
-
@baurt - Hey - I know this is a long time ago - but I was looking at the tf_validity_token code and I realized that it doesn't quite conform to other views are handled. In particular whether the tf_validity_token is sent as a cookie or in the response body is based on whether the client uses forms or json - but everything else in flask_security doesn't make that distinction - of course sessions are always cookies, as are remember cookie and CSRF cookie (if configured for SPA).
If a client isn't web-based and is using token authentication, and aren't processing cookies, then there really isn't any reason for the tf_validity_token that I can figure out. Furthermore, having the client have to store the tf_validity_token from the JSON response is its own security concern.
Do you recall your thinking here? As a next step I would like to always return the cookie - and still, for backwards compatibility, return in a JSON response.
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions