Join the Mozilla’s Test Days event from Dec 2–8 to test the new Firefox address bar on Firefox Beta 134 and get a chance to win Mozilla swag vouchers! 🎁

Kërkoni te Asistenca

Shmangni karremëzime gjoja asistence. S’do t’ju kërkojmë kurrë të bëni një thirrje apo të dërgoni tekst te një numër telefoni, apo të na jepni të dhëna personale. Ju lutemi, raportoni veprimtari të dyshimtë duke përdorur mundësinë “Raportoni Abuzim”.

Mësoni Më Tepër

64-bit browser is scrubbing out ltpatoken from cookie

  • 2 përgjigje
  • 1 e ka hasur këtë problem
  • 4 parje
  • Përgjigjja më e re nga astuer

more options

when trying to login to a server configured for single sign-on, all works well using a 32-bit browser, the server responds with the ltpatoken and the browser correctly re-uses the received ltpatoken in it's next requests to the server. BUT when using a 64-bit browser, on the same workstation, connecting to the same server, the browser suddenly scrubbs out the ltpatoken from the cookie which breaks the flow and the user cannot open the web application as blocked on the login prompt.

Has anyone an idea what can cause this strange behavior. My browser settings are standard, I didn't change anything. But could it be that 64-bit has some strickter security setting which makes the browser think the ltpatoken in the cookie isn't correct ? we don't have the security bit set on the token, the domain accompanying the token is correct, so not sure what else to check as all works fine switching to 32-bit browser !

when trying to login to a server configured for single sign-on, all works well using a 32-bit browser, the server responds with the ltpatoken and the browser correctly re-uses the received ltpatoken in it's next requests to the server. BUT when using a 64-bit browser, on the same workstation, connecting to the same server, the browser suddenly scrubbs out the ltpatoken from the cookie which breaks the flow and the user cannot open the web application as blocked on the login prompt. Has anyone an idea what can cause this strange behavior. My browser settings are standard, I didn't change anything. But could it be that 64-bit has some strickter security setting which makes the browser think the ltpatoken in the cookie isn't correct ? we don't have the security bit set on the token, the domain accompanying the token is correct, so not sure what else to check as all works fine switching to 32-bit browser !

Zgjidhje e zgjedhur

I finally found the cause of this issue. Security has been enforced on 64-bit browsers and additionally in Windows10. The following RFC 6265 was implemented (which isn't implemented in 32-bit browsers and not generally on windows7 workstations) which includes a check on the cookie attribute "Domain" against the public domain suffix list (https://publicsuffix.org/list/public_suffix_list.dat). I my case the token domain was included in this list which caused the browser to reject the cookie. After modifying the token dns domain to a value not included in the public domain list, the problem was solved !

Lexojeni këtë përgjigje brenda kontekstit 👍 0

Krejt Përgjigjet (2)

more options

astuer said

When using a 64-bit browser, on the same workstation, connecting to the same server, the browser suddenly scrubbs out the ltpatoken from the cookie which breaks the flow and the user cannot open the web application as blocked on the login prompt...

I'll guess at this. What about turning OFF Content Blocking or reducing the Blocking? (My settings, attached. Try other setups.)


~Pj

more options

Zgjidhja e Zgjedhur

I finally found the cause of this issue. Security has been enforced on 64-bit browsers and additionally in Windows10. The following RFC 6265 was implemented (which isn't implemented in 32-bit browsers and not generally on windows7 workstations) which includes a check on the cookie attribute "Domain" against the public domain suffix list (https://publicsuffix.org/list/public_suffix_list.dat). I my case the token domain was included in this list which caused the browser to reject the cookie. After modifying the token dns domain to a value not included in the public domain list, the problem was solved !