Zestaw plików cookie nie działa w IE11/10 po wyczyszczeniu pamięci podręcznej

Question

Mam obecnie problem, w którym po wyczyszczeniu pamięci podręcznej/plików cookie IE10 & IE11 nie ustawi ponownie pliku cookie. Żądania i odpowiedzi wyglądają niemal identycznie, ale po wyczyszczeniu pamięci podręcznej plik cookie nigdy nie jest przekazywany, mimo że wydaje się być ustawiony prawidłowo.

Herezje jak płynie moja metoda logowanie:

1. VerifyLogin() -> Fail: Go To Login page 
        -> Pass: Call rest of the AJAX Methods // Enter Login Credentials and submit 
2. Authentication() -> Fail: Prompt the user 
        -> Pass: set forms auth cookie and navigate back to original page, where it will call VerifyLogin() again 

Ten raz Authentication() przechodzi następnie powinny one przemknąć VerifyLogin() bez problemu i kontynuować korzystanie z produktu. Wszystkie połączenia będą teraz miały przekazany plik cookie uwierzytelniania formularzy.

W wystąpieniu im widząc, że się nie powiedzie, wywołanie uwierzytelnienia przechodzi i otrzymuje wartość 200 OK (i ma nagłówek odpowiedzi zestawu plików cookie), ale funkcja VerifyLogin() przestaje działać, ponieważ nie przekazała pliku cookie .

Naprawdę ciężko mi było to odtworzyć, ale do tej pory kroki w zakresie reprodukcji są następujące. Zaczyna się to bez uruchamiania instancji IE. Nie jestem w 100% pewien, że jest to dokładnie ten sam problem, którego doświadczają klienci, ale wydaje się, że ujawnia ten sam problem, który widzą.

1. Uruchom IE
2. Przejdź do strony indeksu witryny i odsyłane do logowania (sprawdź zawiodły)
3. Logowanie przy użyciu poświadczeń, uwierzytelnianie() zwraca 200 OK i ma odpowiedzi zestaw pliku cookie nagłówek. Następnie nawiguje i wywołuje funkcję VerifyLogin(), która przechodzi. Plik cookie jest wysyłany w żądaniu i wszystko się udaje. Kolejne połączenia wszystkie działają.
4. wyczyścić pamięć podręczną i ciasteczka
5. Przejdź do strony indeksu witryny i odsyłane do logowania (sprawdź powiodło się tak jak powinien)
6. logowania z poświadczeniami, uwierzytelnianie() zwraca 200 OK i posiada zestaw nagłówek odpowiedzi na cookie. Następnie nawiguje i wywołuje funkcję VerifyLogin() w tym momencie. Plik cookie nie jest przekazywany w żądaniu, mimo że został wcześniej ustawiony w odpowiedzi na Uwierzytelnianie(). Jeśli zamknę i uruchomię ponownie IE, będzie działać ponownie.

Tak więc, podobnie jak po raz drugi, odpowiedź typu set-cookie nie jest ustawieniem pliku cookie.

Po pierwsze, heres sekcje relent mojego pliku web.config i jak ustawić plik cookie formularzy.

web.config:

<authentication mode="Forms"> 
     <forms enableCrossAppRedirects="true" name="Gator.Express.Auth" timeout="2880" /> 
    </authentication> 

metoda setAuthenticationCookie:

public void SetAuthenticationCookie(string userName, CookieData cookieData) 
     { 
      //In order to pickup the settings from config, we create a default cookie and use its values to create a 
      //new one. 
      var cookie = FormsAuthentication.GetAuthCookie(userName, true); 
      var ticket = FormsAuthentication.Decrypt(cookie.Value); 

      if (ticket == null) 
       throw new Exception("Error setting authorisation cookie. Decryption of default cookie failed."); 

      var jsonToken = JsonConvert.SerializeObject(cookieData); 

      var newTicket = new FormsAuthenticationTicket(ticket.Version, ticket.Name, ticket.IssueDate, ticket.Expiration, 
       ticket.IsPersistent, jsonToken, ticket.CookiePath); 
      var encTicket = FormsAuthentication.Encrypt(newTicket); 

      cookie.Value = encTicket; 

      HttpContext.Current.Response.Cookies.Add(cookie); 
     } 

Teraz poniżej oto żądań i odpowiedzi w porządku.

Authentication Pracy Zapytanie

POST http://localhost:55733/api/Authentication HTTP/1.1 
Accept: application/json, text/javascript, */*; q=0.01 
Content-Type: application/x-www-form-urlencoded; charset=UTF-8 
Referer: http://localhost:61496/Login.html 
Accept-Language: en-GB 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko 
Connection: Keep-Alive 
Content-Length: 35 
DNT: 1 
Host: localhost:55733 
Pragma: no-cache 

Username=michaelGator&Password=XXXX 

# Authentication robocza Response

HTTP/1.1 200 OK 
Cache-Control: no-cache 
Pragma: no-cache 
Content-Type: application/json; charset=utf-8 
Expires: -1 
Server: Microsoft-IIS/8.0 
X-AspNet-Version: 4.0.30319 
Set-Cookie: Gator.Express.Auth=01020FCCF4658183D208FE0F4CC8BA1385D208000C6D00690063006800610065006C004700610074006F00720000012F00FF; path=/; HttpOnly 
Set-Cookie: Gator.Express.Auth=0102054E17668183D208FE05CEEABA1385D208010C6D00690063006800610065006C004700610074006F007200377B002200530073006F004100630063006F0075006E0074004900640022003A002200300030003000300030003000300030002D0030003000300030002D0030003000300030002D0030003000300030002D0030003000300030003000300030003000300030003000300022007D00012F00FF; expires=Sun, 05-Jul-2015 08:28:39 GMT; path=/; HttpOnly 
X-SourceFiles: =?UTF-8?B?QzpcV29ya2luZ1xnYXRvci5nYXRvcndlYnNlcnZpY2VcU291cmNlXEdhdG9yV2ViU2VydmljZVxhcGlcQXV0aGVudGljYXRpb24=?= 
Access-Control-Allow-Origin: http://localhost:61496 
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization, token 
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS 
Access-Control-Allow-Credentials: true 
Date: Fri, 03 Jul 2015 08:28:39 GMT 
Content-Length: 14 

"michaelGator" 

# robocza VerifyLogin Zapytanie

GET http://localhost:55733/api/VerifyLogin HTTP/1.1 
Referer: http://localhost:61496/ 
Accept: */* 
Accept-Language: en-GB 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko 
Connection: Keep-Alive 
DNT: 1 
Host: localhost:55733 
Cookie: Gator.Express.Auth=0102054E17668183D208FE05CEEABA1385D208010C6D00690063006800610065006C004700610074006F007200377B002200530073006F004100630063006F0075006E0074004900640022003A002200300030003000300030003000300030002D0030003000300030002D0030003000300030002D0030003000300030002D0030003000300030003000300030003000300030003000300022007D00012F00FF 

# odpowiedź VerifyLogin robocza

HTTP/1.1 200 OK 
Cache-Control: no-cache 
Pragma: no-cache 
Expires: -1 
Server: Microsoft-IIS/8.0 
X-AspNet-Version: 4.0.30319 
X-SourceFiles: =?UTF-8?B?QzpcV29ya2luZ1xnYXRvci5nYXRvcndlYnNlcnZpY2VcU291cmNlXEdhdG9yV2ViU2VydmljZVxhcGlcVmVyaWZ5TG9naW4=?= 
Access-Control-Allow-Origin: http://localhost:61496 
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization, token 
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS 
Access-Control-Allow-Credentials: true 
Date: Fri, 03 Jul 2015 08:28:39 GMT 
Content-Length: 0 

Poniżej jest tu nieprodukcyjnym zestaw żądań i odpowiedzi. Zauważ, że metoda uwierzytelniania zwraca 200 OK i polecenie set-cookie, ale w następnym potwierdzeniu połączenia logowania, coookie zniknął.

# żądanie uwierzytelnienia - Powroty, jak powinien, ale część z nieprodukcyjnym zestaw wniosków

POST http://localhost:55733/api/Authentication HTTP/1.1 
Accept: application/json, text/javascript, */*; q=0.01 
Content-Type: application/x-www-form-urlencoded; charset=UTF-8 
Referer: http://localhost:61496/Login.html 
Accept-Language: en-GB 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko 
Connection: Keep-Alive 
Content-Length: 35 
DNT: 1 
Host: localhost:55733 
Pragma: no-cache 

Username=michaelGator&Password=XXXX 

# Authentication response- Zwraca tak jak powinien, ale część z nieprodukcyjnym zestaw wniosków

HTTP/1.1 200 OK 
Cache-Control: no-cache 
Pragma: no-cache 
Content-Type: application/json; charset=utf-8 
Expires: -1 
Server: Microsoft-IIS/8.0 
X-AspNet-Version: 4.0.30319 
Set-Cookie: Gator.Express.Auth=01022054EB9B8183D208FE20D4BEF01385D208000C6D00690063006800610065006C004700610074006F00720000012F00FF; path=/; HttpOnly 
Set-Cookie: Gator.Express.Auth=01028447109C8183D208FE84C7E3F01385D208010C6D00690063006800610065006C004700610074006F007200377B002200530073006F004100630063006F0075006E0074004900640022003A002200300030003000300030003000300030002D0030003000300030002D0030003000300030002D0030003000300030002D0030003000300030003000300030003000300030003000300022007D00012F00FF; expires=Sun, 05-Jul-2015 08:30:10 GMT; path=/; HttpOnly 
X-SourceFiles: =?UTF-8?B?QzpcV29ya2luZ1xnYXRvci5nYXRvcndlYnNlcnZpY2VcU291cmNlXEdhdG9yV2ViU2VydmljZVxhcGlcQXV0aGVudGljYXRpb24=?= 
Access-Control-Allow-Origin: http://localhost:61496 
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization, token 
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS 
Access-Control-Allow-Credentials: true 
Date: Fri, 03 Jul 2015 08:30:10 GMT 
Content-Length: 14 

"michaelGator" 

# nieprodukcyjnym VerifyLogin Zapytanie - uwaga, ciasteczko nie przechodzi się

GET http://localhost:55733/api/VerifyLogin HTTP/1.1 
Referer: http://localhost:61496/ 
Accept: */* 
Accept-Language: en-GB 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko 
Connection: Keep-Alive 
DNT: 1 
Host: localhost:55733 

# nieprodukcyjnym VerifyLogin odpowiedź - nie zawodzi jak żadne formy Cookie został przekazany się

HTTP/1.1 401 Unauthorized 
Cache-Control: no-cache 
Pragma: no-cache 
Content-Type: application/json; charset=utf-8 
Expires: -1 
Server: Microsoft-IIS/8.0 
X-AspNet-Version: 4.0.30319 
X-SourceFiles: =?UTF-8?B?QzpcV29ya2luZ1xnYXRvci5nYXRvcndlYnNlcnZpY2VcU291cmNlXEdhdG9yV2ViU2VydmljZVxhcGlcVmVyaWZ5TG9naW4=?= 
Access-Control-Allow-Origin: http://localhost:61496 
Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept, Authorization, token 
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS 
Access-Control-Allow-Credentials: true 
Date: Fri, 03 Jul 2015 08:30:10 GMT 
Content-Length: 71 

{"$id":"1","Message":"Authorization has been denied for this request."} 

ktoś ma jakieś pomysły na ten temat?

Answer 1

Wydaje się dostać się dwa cookie uwierzytelniania, co sugeruje, że implementacja jest zderzeniu z czymś, co ASP.Net stara się zautomatyzować dla Ciebie.

Jest FormsAuthentication.SetAuthCookie który tworzy i ustawia ciasteczko, i myślę, że to już stosowane, więc:

1. FormsAuthentication.SetAuthCookie dostaje ciasteczko (już ustawione w tej samej odpowiedzi).
2. Twoje pożary SetAuthenticationCookie.
3. To wywołuje FormsAuthentication.GetAuthCookie i przetwarza (osadza zserializowane dane JSON w nowym pliku cookie) oryginału.
4. Zadzwoń pod numer HttpContext.Current.Response.Cookies.Add, aby utworzyć drugi plik cookie.
5. Oba ciasteczka są dostarczane w nagłówku o tej samej nazwie

Nie usunięciu oryginalnego pliku cookie, Net i nie wie, jak przetworzyć przetworzony plik cookie.

myślę, że masz dwie opcje:

1. Podziel się swoimi danymi JSON w zupełnie oddzielnym pliku cookie z inną nazwą.
2. Odłóż własne ciasteczka od podstaw i nie używaj żadnej metody .Net's FormsAuthentication.

Osobiście osobiście wybrałbym ten pierwszy jako najprostszy i najszybszy do wdrożenia.

Warto również eksperymentować z nazwami plików cookie - nie jestem pewien, czy wszystkie przeglądarki obsługują okresy w nazwach plików cookie, ale wszystkie są wrażliwe na wielkość liter.

Wreszcie coś, co warto sprawdzić - to prawie never worth setting a cookie's path in .Net, ponieważ IIS traktuje URL jako wielkość liter, ale przeglądarki traktują nazwy plików cookie jako małe i małe litery.

Answer 2

1. Dlaczego odpowiedź wysyła dwa nagłówki SetCookie z tą samą nazwą pliku cookie? Wydaje się to ... błędne i mylące.

2. Należy uważać, aby nie podać IE zbyt wiele danych w plikach cookie. Twoje wartości cookie są dość długie! Istnieje limit plików cookie wynoszący ~ 4k. To łączna liczba plików cookie dla Twojej domeny. Jeśli jest dłuższy, to IE nie odeśle go.

HTH