runtime: [Cookie] SocketsHttpHandler/CookieContainer does not accept cookies from Twitter, fails request

I tested ASP.NET’s Twitter OAuth handler with the new SocketsHttpHandler (dotnet --version: 2.1.300-preview2-008251) and found that the CookieContainer does not accept cookies from Twitter and it fails the request rather than ignoring them.

System.Net.CookieException: An error occurred when parsing the Cookie header for Uri 'https://api.twitter.com/oauth/request_token'. ---> System.Net.CookieException: Cookie format error.
   at System.Net.CookieContainer.CookieCutter(Uri uri, String headerName, String setCookieHeader, Boolean isThrow)
   --- End of inner exception stack trace ---
   at System.Net.CookieContainer.CookieCutter(Uri uri, String headerName, String setCookieHeader, Boolean isThrow)
   at System.Net.CookieContainer.SetCookies(Uri uri, String cookieHeader)
   at System.Net.Http.CookieHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.AuthenticateAndRedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.FinishSendAsyncBuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
   at Microsoft.AspNetCore.Authentication.Twitter.TwitterHandler.ObtainRequestTokenAsync(String callBackUri, AuthenticationProperties properties) in d:\github\AspNet\Security\src\Microsoft.AspNetCore.Authentication.Twitter\TwitterHandler.cs:line 197
   at Microsoft.AspNetCore.Authentication.Twitter.TwitterHandler.HandleChallengeAsync(AuthenticationProperties properties) in d:\github\AspNet\Security\src\Microsoft.AspNetCore.Authentication.Twitter\TwitterHandler.cs:line 140
   at Microsoft.AspNetCore.Authentication.AuthenticationHandler`1.ChallengeAsync(AuthenticationProperties properties) in d:\github\AspNet\Security\src\Microsoft.AspNetCore.Authentication\AuthenticationHandler.cs:line 227
   at Microsoft.AspNetCore.Authentication.AuthenticationService.ChallengeAsync(HttpContext context, String scheme, AuthenticationProperties properties)

Reference app: https://github.com/aspnet/Security/blob/4e3e8bb109f3d1b3d95f7af4775a386d291c2b96/samples/SocialSample/Startup.cs#L111

The cookies in question are:

set-cookie: guest_id=v1%3A151966890829154034; Expires=Sat, 07 Mar 2020 00:28:24 UTC; Path=/; Domain=.twitter.com
set-cookie: personalization_id="v1_Xfcbmc7S2QFG3YSiebMfA=="; Expires=Sat, 07 Mar 2020 00:28:24 UTC; Path=/; Domain=.twitter.com

And it appears to be the UTC time zone that causes it to fail.

var cookieContainer = new CookieContainer();
cookieContainer.SetCookies(new Uri("http://example.com"), "key=value; Expires=Sat, 07 Mar 2020 00:28:24 UTC");

Where GMT works:

 cookieContainer.SetCookies(new Uri("http://example.com"), "key=value; Expires=Sat, 07 Mar 2020 00:28:24 GMT");

If SocketsHttpHandler becomes the default then this behavior will regress new and existing server apps using Twitter logins.

Fix: Unreadable cookie values must at a minimum be ignored. They should not fail the request. I recall this is the behavior of .NET HttpClient/HttpWebRequest, and CookieCutter already has an option for this.

Workaround, ignore cookies, they’re optional for this flow:

.AddTwitter(o =>
{
   ...
   o.BackchannelHttpHandler = new HttpClientHandler() { UseCookies = false };
})

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 21 (20 by maintainers)

Most upvoted comments

Tested in Firefox, Chrome, and Edge that setting a cookie with Expires UTC is accepted. Tried to test IE but the internet doesn’t seem to know where cookies are stored now, the cookies location moved in the Creators Update.

I don’t think supporting UTC is a good idea. it is not part of any standard and even it is better to get who is using it to fix such usage. I am seeing Twitter already did that which make sense. you may look at following link for some similar discussion

https://stackoverflow.com/questions/25658897/is-utc-a-valid-timezone-name-for-rfc-1123-specification

The issue is if we start to support such that case, users will wonder why we don’t support any other zone abbreviations too which will be sane to have DateTime parser go this route. I suggest this can be supported by other library doing more custom things but not really in the core.

@golf1052 wants to pick it up, assigning to you …

That said, I think we probably should accept “UTC”; I don’t see any real downside.

Fix: Unreadable cookie values must at a minimum be ignored.

Yes, the handler (SocketsHttpHandler) should ignore unreadable cookies and continue with the request.

But we should also consider making a fix to Cookie parsing. Perhaps the use of the “UTC” timezone is a valid construct but our cookie parser just doesn’t know how to handle that.