Skip to content
This repository has been archived by the owner on Nov 22, 2018. It is now read-only.

React to SameSite addition to CookieOptions #141

Merged
merged 1 commit into from
Jun 2, 2017

Conversation

JunTaoLuo
Copy link
Contributor

#127 We should be setting the default to strict?

{
HttpOnly = true,
Domain = _options.CookieDomain,
SameSite = SameSiteEnforcementMode.Strict
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not familiar with this option, Let's have a conversation with @blowdart - we need to understand what should be the default and if this should be configurable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Spoke offline, I think this should remain as strict as we expect the cookie to be created by requests from the same site as subsequent requests. There's no need to make this configurable.

@JunTaoLuo
Copy link
Contributor Author

Updated based on @blowdart's recommendation to make this option configurable. This is ready to merge.

@rynowak
Copy link
Member

rynowak commented Jun 1, 2017

Sorry, what's the reason for making this configurable?

@rynowak
Copy link
Member

rynowak commented Jun 1, 2017

If we're going to make this configurable we should attach an Action<CookieOptions> to AntiforgeryOptions and be done. Then users are empowered to do whatever they want and we don't end up duplicating all of CookieOptions on AntiforgeryOptions.

/// </summary>
public string CookieDomain { get; set; }
public Action<CookieOptions> ConfigureCookieOptions { get; set; }
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is now a breaking change that requires an announcement.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Get @Eilon to sign off on the breaking change, I don't get to approve these

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added him as a reviewer and will speak with him about the breaking change. Can you review the rest of the PR?

@@ -80,6 +84,8 @@ public void SaveCookieToken(HttpContext httpContext, string token)
}
SetCookiePath(httpContext, options);

_options.ConfigureCookieOptions?.Invoke(options);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I call the new ConfigureCookieOptions last after everything else is set. If we don't want users to be able to override Secure or Path on the CookieOptions, we can move this up, though I don't see why we might want that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we also want to configure the cookie path and secure in the delegate?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally I think allowing you to set both is fine. RequireSSL is also enforced on the validation side, so if you mess it up, you'll just get a 400.

We should double check with @blowdart

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consistency is good, but folks are already using the old way. I assume you don't want to remove the existing path, just add a way to set it here to?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, not changing the existing behaviour. Calling the configure delegate here allows the user to overwrite what we set but as @rynowak mentioned, they will be doing so at their own risk.

@JunTaoLuo JunTaoLuo requested a review from Eilon June 1, 2017 23:56
@@ -364,7 +364,7 @@ public void SaveCookieToken_NonNullAntiforgeryOptionsCookieDomain_UsesOptionsCoo
.Returns("/index.html");
var options = new AntiforgeryOptions();
options.CookieName = _cookieName;
options.CookieDomain = expectedCookieDomain;
options.ConfigureCookieOptions = cookieOptions => cookieOptions.Domain = expectedCookieDomain;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change the name of this test to reflect the change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Member

@rynowak rynowak left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit: from me, let's get @Eilon and @blowdart to approve of what's changing here

@@ -54,12 +54,21 @@ public string CookieName
public PathString? CookiePath { get; set; }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be obsolete too, it's redundant with ConfigureCookieOptions

var options = new CookieOptions
{
HttpOnly = true,
Domain = null,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

still use the obsolete domain property

@@ -69,9 +69,13 @@ public void SaveCookieToken(HttpContext httpContext, string token)
Debug.Assert(httpContext != null);
Debug.Assert(token != null);

var options = new CookieOptions();
options.HttpOnly = true;
options.Domain = _options.CookieDomain;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We still need to use _options.CookieDomain - it's not being removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah yes

@JunTaoLuo
Copy link
Contributor Author

JunTaoLuo commented Jun 2, 2017

🆙📅 edit oops need to ignore obsolete errors

Domain = null,
SameSite = SameSiteMode.Strict
};

// Note: don't use "newCookie.Secure = _options.RequireSSL;" since the default
// value of newCookie.Secure is populated out of band.
if (_options.RequireSsl)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is misleading, remove it.

@JunTaoLuo
Copy link
Contributor Author

JunTaoLuo commented Jun 2, 2017

As per discussion with @Tratcher, we will probably adopt this approach for other components that duplicate settings on CookieOptions, potentially updating things like Session. Will file an issue in HttpAbstractions to track. Filed aspnet/HttpAbstractions#853.

- allows configuration of CookieOptions such as SameSite without explicit duplication of the option on AntiforgeryOptions
@JunTaoLuo JunTaoLuo changed the base branch from dev to rel/2.0.0-preview2 June 2, 2017 21:35
@JunTaoLuo JunTaoLuo merged commit 5870fce into rel/2.0.0-preview2 Jun 2, 2017
@JunTaoLuo JunTaoLuo deleted the johluo/samesite branch June 2, 2017 22:15
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants