0

We have a web service to which users can sign in and out. A cookie is used to determine whether a user is signed in or not.

The service expose multiple "sites", each identified by a subdomain. For example:

  • http://customer1.ourservice.com/
  • http://customer2.ourservice.com/

There are two ways to sign in; either "service wide" or "site specific".

"Service wide" sign in requests are sent to a special subdomain (http://globalauth.ourservice.com/). Such sign in requests result in a Set-Cookie header like the following:

Set-Cookie: OUR-COOKIE=<<cookie-value>>; 
            expires=Wed, 03 May 2017 11:25:58 GMT; 
            domain=.ourservice.com; 
            path=/; 
            httponly

(Line breaks added here to make it easier to read)

The domain=.ourservice.com setting makes the cookie available to all subdomains.

"Site specific" sign in requests are sent to the site specific subdomain. They result in a Set-Cookie header like the following:

Set-Cookie: OUR-COOKIE=<<cookie-value>>; 
            expires=Wed, 03 May 2017 11:23:42 GMT; 
            path=/; 
            httponly

Sign out requests are always sent to a site specific subdomain and are supposed to remove cookies for both "side wide" sign in and "site specific" sign in.

A sign out request result in a Set-Cookie header like the following:

Set-Cookie: OUR-COOKIE=; 
            expires=Mon, 02 May 2016 11:26:54 GMT; 
            path=/; 
            httponly,
            OUR-COOKIE=; 
            expires=Mon, 02 May 2016 11:26:54 GMT; 
            domain=.ourservice.com; 
            path=/; 
            httponly

The idea here is that both the site specific and the service wide cookie shall be cleared and expired.

It works when when a "service wide" sign in was used, but does not work when a "site specific" sign in was used.

A site specific cookie is simply not removed from the browser.

How do we properly instruct the browser to expire/remove the cookie no matter whether it was issued with a domain setting or not?

Mårten Wikström
  • 11,074
  • 5
  • 47
  • 87

1 Answers1

0

It turns out that this is due to a WCF-related bug in .NET framework 4.0 and 4.5.

The specification, RFC 6265, does not allow multiple comma separated cookies to be transmitted in a single Set-Cookie header. Instead, multiple Set-Cookie headers should be used (one for each cookie).

We are using HttpResponseHeadersExtensions.AddCookies to add cookies. The documentation for that method clearly says:

Each Set-Cookie header is represented as one CookieHeaderValue instance.

However, it turns out that multiple CookieHeaderValue instances are indeed merged into a single, comma separated, Set-Cookie header – which is unsupported by the specification.

See the following related posts on StackOverflow:

A quote from the latter post:

The fact that "Set-Cookie" is munged into a single cookie line is logged as a bug within Microsoft for .NET Framework 4.0 and also Framework 4.5. Within the Microsoft WCF development group, the bug is listed as "closed" and "won't fix".

According to Microsoft, the only workaround is to move from self-hosted to hosting within IIS and then using the (IIS) Response object directly (different code path that does not have the bug).

This is bad news for us, as we are currently tied to using the self-host code path. We'll have to find a way around this bug.

Community
  • 1
  • 1
Mårten Wikström
  • 11,074
  • 5
  • 47
  • 87