2016-05-03 11 views
0

Wir haben einen Webservice, mit dem sich Benutzer an- und abmelden können. Ein Cookie wird verwendet, um festzustellen, ob ein Benutzer angemeldet ist oder nicht.Wie läuft der Cookie ordnungsgemäß ab?

Der Dienst enthält mehrere "Sites", die jeweils durch eine Subdomäne identifiziert werden. Zum Beispiel:

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

Es gibt zwei Möglichkeiten, um sich anzumelden; entweder "service wide" oder "site specific".

"Dienstweite" Anmeldeanforderungen werden an eine spezielle Subdomäne gesendet (http://globalauth.ourservice.com/). Ein solches Zeichen in Anfragen führen zu einem Set-Cookie Header wie folgt aus:

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

(Zeilenumbrüche hier hinzugefügt, um es einfacher zu lesen)

Die domain=.ourservice.com Einstellung macht das Cookie für alle Sub-Domains zur Verfügung.

"Site-spezifische" Anmeldeanforderungen werden an die standortspezifische Subdomäne gesendet. Sie führen zu einem Set-Cookie Header wie folgt aus:

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

Sign out-Anforderungen werden immer an eine ortsspezifische Sub-Domain gesendet und sollen Cookies entfernen, für beide "Seiten-wide" Zeichen in und "site specific" Zeichen in.

ein Zeichen aus Anfrageergebnis in einem Set-Cookie Header wie folgt aus:

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 

die Idee dabei ist, dass sowohl die ortsspezifische und das breite Service-Cookie wird gelöscht und abgelaufen.

Es funktioniert, wenn eine "Service Wide" Anmeldung verwendet wurde, funktioniert aber nicht, wenn eine "Site-spezifische" Anmeldung verwendet wurde.

Ein standortspezifisches Cookie wird einfach nicht aus dem Browser entfernt.

Wie weisen wir den Browser ordnungsgemäß an, den Cookie ablaufen zu lassen/entfernen, unabhängig davon, ob er mit einer domain Einstellung ausgestellt wurde oder nicht?

Antwort

0

Es stellt sich heraus, dass dies auf einen WCF-Bug in .NET Framework 4.0 und 4.5 zurückzuführen ist.

Die Spezifikation RFC 6265 ermöglicht nicht die Übertragung mehrerer kommagetrennter Cookies in einem einzelnen Header Set-Cookie. Stattdessen sollten mehrere Set-Cookie Header verwendet werden (einer für jeden Cookie).

Wir verwenden HttpResponseHeadersExtensions.AddCookies, um Cookies hinzuzufügen. Die Dokumentation für diese Methode deutlich sagt:

Jeder Set-Cookie-Header als ein CookieHeaderValue Instanz dargestellt wird.

jedoch stellt sich heraus, dass mehrere CookieHeaderValue Instanzen in der Tat zu einem einzigen verschmolzen werden, durch Komma getrennt, Set-Cookie Header –, die von der Spezifikation nicht unterstützt wird.

Auch die folgenden verwandten Beiträge auf Stackoverflow:

Ein Zitat aus diesem Beitrag:

Die Tatsache, dass "Set-Cookie" in einer einzigen Cookie-Zeile munged wird als Fehler in Microsoft für .NET Framewo protokolliert rk 4.0 und auch Framework 4.5. In der Microsoft WCF-Entwicklergruppe wird der Fehler als "geschlossen" und "wird nicht behoben" aufgeführt. Die einzige Problemumgehung ist laut Microsoft, von Self-Hosted zu Hosting innerhalb von IIS zu wechseln und dann das (IIS) Response-Objekt direkt zu verwenden (anderer Codepfad, der den Fehler nicht hat).

Dies ist eine schlechte Nachricht für uns, da wir derzeit mit dem Self-Host-Code-Pfad verbunden sind. Wir müssen einen Weg finden, diesen Fehler zu umgehen.