Before posting a bug report I'd like to hear your opinions - perhaps I'm on the wrong page.
When authenticating with an application that uses CAS, the first thing that happens is that the CAS login form appears. Before that form is sent to the browser, CAS is internally trying to delete any TGC-Cookies that might exist. This happens in line 95 of this class: https://github.com/apereo/cas/blob/6.2.x/support/cas-server-support-actions/src/main/java/org/apereo/cas/web/flow/login/InitialFlowSetupAction.java The result is that the following header is sent to the browser (JSON notation as copied from the Firefox Dev Tools): "name": "set-cookie", "value": "TGC-1.2.3=\"\"; Version=1; Path=/mycas/; Secure; HttpOnly; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:00 GMT; Comment=\"CAS Cookie\"" The reason for that "empty" cookie is probably that the only way to delete a cookie as per the Servlet API is to set a new one with an empty value. Apparently CAS is trying to do that here. It doesn't matter much, because we are talking only about the login page, but this becomes important later on. When I login via CAS protocol, i.e . POSTing my credentials to https://cas-server/mycas/login?locale=de <https://172.16.16.16:8443/ooscas/login?locale=de> I'll get back a proper TGC cookie and am authenticated: "name": "set-cookie", "value": "TGC-1.2.3=eyJhbG...; Path=/mycas/; SameSite=None; Secure; HttpOnly" However, when I do the same thing via external authentication (Azure OpenID Connect), I am entering the OAuth2 Authorization Code flow and arrive at POSTing to the URL https://cas-server/mycas/login?code=0.ATAAHe5... - in other words, I am not sending my credentials, but an Authorization Code I have obtained from Azure. Upon POSTing to that URL I am getting both of the above-mentioned headers back. So the browser is getting the "full" TGC-Cookie and an "empty" one. Because the "empty" one arrives last, the browser sends it for its next request and obviously authentication fails at that point. I have debugged into the CAS code and found that the above-mentioned code in line 95 of InitialFlowSetupAction is called again during authentication, which results in the extra "empty" header. Bottom line: the TGC cookie is not removed properly, resulting in two "set-cookie" headers. But this only breaks external authentication. When authenticating directly with CAS the cookie removal code is not called during authentication and thus we only have one "set-cookie" header. I have noted that the code to remove cookies was changed between CAS 5.3 (where this issue does not exist) to CAS 6.2. So what do you think? Is this a bug or do I misunderstand something about cookie handling or CAS? -- - Website: https://apereo.github.io/cas - Gitter Chatroom: https://gitter.im/apereo/cas - List Guidelines: https://goo.gl/1VRrw7 - Contributions: https://goo.gl/mh7qDG --- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/e5c2787d-cf5e-4113-a742-0153a6f02d10n%40apereo.org.
