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
We have experienced random 403s on our app and I'm trying to find the root cause. I think the source is go/csrf due to expired cookies, but haven't yet confirmed this. I am using logrus to log completed requests in chi via middleware. If there is a CSRF issue, I would like to add the reasoning to the log something like ... go.csrf.error='csrf expired' ....
I am having some difficulty getting this to work in a test environment. I think here the request context is cleared. So, in my request completed logrus hook doesn't see the CSRF 403 information in the request context.
I know the CSRF rejection reasoning is being provided back to the client via text, but this use case is an app that is doing background updates. The client doesn't see the reasoning error. Also, it might not be best practice to expose this information to the client. The only other solution I can think of is to make a custom HTTP error handler but I am trying to avoid this. Any advice here?
Expected Behavior
No response
Steps To Reproduce
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered:
Is there an existing issue for this?
Current Behavior
We have experienced random 403s on our app and I'm trying to find the root cause. I think the source is go/csrf due to expired cookies, but haven't yet confirmed this. I am using logrus to log completed requests in chi via middleware. If there is a CSRF issue, I would like to add the reasoning to the log something like
... go.csrf.error='csrf expired' ...
.I am having some difficulty getting this to work in a test environment. I think here the request context is cleared. So, in my request completed logrus hook doesn't see the CSRF 403 information in the request context.
I know the CSRF rejection reasoning is being provided back to the client via text, but this use case is an app that is doing background updates. The client doesn't see the reasoning error. Also, it might not be best practice to expose this information to the client. The only other solution I can think of is to make a custom HTTP error handler but I am trying to avoid this. Any advice here?
Expected Behavior
No response
Steps To Reproduce
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: