Skip to content

Secure flag of CookieCsrfTokenRepository cookie #5414

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Juan-Bustamante opened this issue Jun 6, 2018 · 6 comments
Closed

Secure flag of CookieCsrfTokenRepository cookie #5414

Juan-Bustamante opened this issue Jun 6, 2018 · 6 comments
Assignees
Labels
in: web An issue in web modules (web, webmvc) status: duplicate A duplicate of another issue type: enhancement A general enhancement

Comments

@Juan-Bustamante
Copy link

Summary

Can we please allow for configuring the desired value of the "secure" flag for the XSRF-TOKEN cookie created by CookieCsrfTokenRepository?

Actual Behavior

The flag is always set based on the "isSecure" flag on the Http request:
cookie.setSecure(request.isSecure());

Expected Behavior

While using the request's "isSecure" flag is a reasonable default, when webapps sit behind firewalls, sometimes the firewall does the SSL, and the traffic between the firewall and the app is plain HTTP (not HTTPS). In this case the "isSecure" flag on the request is always false, but we still want th XSRF-TOKEN cookie to be secure (the firewall forwards all cookies to the app, and the browser sends the secure cookie to the firewall).

It would be nice if we could configure the desired value for the secure flag of the cookie, just like we can configure the value for the httpOnly flag of the cookie.

Configuration

Version

I'm currently on 4.2.6.RELEASE

Sample

@rwinch rwinch closed this as completed in 0c26d1b Jul 31, 2018
@Juan-Bustamante
Copy link
Author

Rob - it doesn't appear to me that the fix is indeed for this issue.

How does the change to "ServerHttpBasicAuthenticationConverter" enhance the "CookieCsrfTokenRepository"?

@izeye
Copy link
Contributor

izeye commented Aug 8, 2018

The commit looks meant to close #5614 , not this one.

@sasikumar-swaminathan
Copy link

@izeye, Indeed this issue was closed with the wrong commit I guess. I'm in desperate need of configurable secure flag for the exact same reason @Juan-Bustamante has mentioned above.
Should we somehow notify Rob Winch about it?

@zcwang3
Copy link

zcwang3 commented Dec 12, 2018

@rwinch do you close this issue intentionally or by accident?
it seems that the feature enhancement requirement is still there and not fixed.

Should we report a new issue with same content?

@rwinch rwinch reopened this Dec 12, 2018
@rwinch
Copy link
Member

rwinch commented Dec 12, 2018

@zcwang3 Thanks for pointing that out. It appears that the commit reference the wrong issue. I have reopened this ticket.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label May 7, 2019
@rwinch rwinch self-assigned this Jun 25, 2020
@rwinch rwinch added status: duplicate A duplicate of another issue in: web An issue in web modules (web, webmvc) type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged labels Jun 25, 2020
@rwinch
Copy link
Member

rwinch commented Jun 25, 2020

Closing in favour of gh-8749

@rwinch rwinch closed this as completed Jun 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web An issue in web modules (web, webmvc) status: duplicate A duplicate of another issue type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

6 participants