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
(First off, I'm not 100% whether this is a bug, a feature request, or me not understanding something, so apologies if I categorized it incorrectly).
I have a REST API that uses JWT authentication for non-browser clients, but want to support cookie-based authentication for web clients. To support this, I am calling UnsafeSkipCheck if no authentication / session cookie is present in the request (and JWT authentication will be used instead where I do not worry about CSRF).
However, calling UnsafeSkipCheck exits so early that no CSRF token is ever generated, which means that GET requests will not be responded to with a X-CSRF-Token header, and the client has essentially no way of obtaining a CSRF token.
Is there a reason why skipping the check prevents a token from being generated altogether? Am I just approaching this wrong?
I can call UnsafeSkipCheck much more selectively to bypass this issue, but that doesn't feel correct.
Versions
Go version: go version go1.19 darwin/arm64
package version: v1.7.1
The text was updated successfully, but these errors were encountered:
Describe the bug
(First off, I'm not 100% whether this is a bug, a feature request, or me not understanding something, so apologies if I categorized it incorrectly).
I have a REST API that uses JWT authentication for non-browser clients, but want to support cookie-based authentication for web clients. To support this, I am calling
UnsafeSkipCheck
if no authentication / session cookie is present in the request (and JWT authentication will be used instead where I do not worry about CSRF).However, calling
UnsafeSkipCheck
exits so early that no CSRF token is ever generated, which means that GET requests will not be responded to with a X-CSRF-Token header, and the client has essentially no way of obtaining a CSRF token.Is there a reason why skipping the check prevents a token from being generated altogether? Am I just approaching this wrong?
I can call
UnsafeSkipCheck
much more selectively to bypass this issue, but that doesn't feel correct.Versions
The text was updated successfully, but these errors were encountered: