Different workflow here. I access my application and it redirects to the CAS Login Page. On the CAS Login Page I can choose whether to log in directly (via CAS protocol) or externally (via Azure). To that end there is a button that will take me to the Azure login page.
However, my browser will also have seen the "empty" cookie, since I'm passing through the CAS login page. But I don't think that can have any effect - what difference should it make to the browser, whether a cookie has been seen before? Have you checked in which order you receive the two cookies? Perhaps the "empty" cookie comes first in your case, so it is then overwritten by the "full" cookie? My cookie is also named TGC-1.2.3, I'm using the CAS default as well. cheers, Ulrich On Friday, 8 January 2021 at 18:29:19 UTC+1 Ray Bon wrote: > Ulrich, > > Same versions of chrome and firefox on linux. > When I use delegated auth to azure, I first pass through the cas log in > page and it redirects to azure. Thus my browser has already 'seen' the > empty TGC. > Is this your flow, or do you go to azure first? > > Also, does your TGC have a suffix, '-1.2.3'? > I am using the default cas setting that has no suffix, the cookie label is > 'TGC'. This should not matter, but stranger things have happened. > > Ray > > On Fri, 2021-01-08 at 01:21 -0800, Ulrich Mayring wrote: > > Notice: This message was sent from outside the University of Victoria > email system. Please be cautious with links and sensitive information. > > I have tested this with Firefox 84 and Chrome 87.0.4280.88 and in both > cases no cookie is sent with the next request, thus failing to login the > user. > > As far as I understand, the server is allowed to send multiple > "Set-Cookie" headers with different values. The client (browser), however, > is only allowed to send one "Cookie" header back. He can concatenate the > multiple values into that one field, though. But it appears that in my case > the browser looks at the two Set-Cookie headers seperately. The first one > is accepted as a new cookie, but the second one without a value is > apparently interpreted as "delete this cookie". Thus no cookie is sent with > the next request. > > If I understand you correctly, then in your case the browser is sending > the correct TGC-Cookie, even though you also receive the two Set-Cookie > headers? > > Kind regards, > Ulrich > On Thursday, 7 January 2021 at 19:22:14 UTC+1 Ray Bon wrote: > > Ulrich, > > I see the two TGCs on return from azure. I can not tell which arrived > first, but the stored TGC does have a value, and subsequent login does send > this value. > Could this be related to browser behaviour? > > I tested in firefox and chrome. The empty cookie has Expires=1970... and > Max-Age=0; the one with a value has no Max-Age and no Expires but does have > a SameSite. > > Ray > > On Thu, 2021-01-07 at 05:00 -0800, Ulrich Mayring wrote: > > Notice: This message was sent from outside the University of Victoria > email system. Please be cautious with links and sensitive information. > > > 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? > > -- > > > Ray Bon > Programmer Analyst > Development Services, University Systems > 2507218831 <(250)%20721-8831> | CLE 019 | [email protected] > > I respectfully acknowledge that my place of work is located within the > ancestral, traditional and unceded territory of the Songhees, Esquimalt and > WSÁNEĆ Nations. > > -- > > Ray Bon > Programmer Analyst > Development Services, University Systems > 2507218831 <(250)%20721-8831> | CLE 019 | [email protected] > > I respectfully acknowledge that my place of work is located within the > ancestral, traditional and unceded territory of the Songhees, Esquimalt and > WSÁNEĆ Nations. > -- - 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/4c422211-2286-4e9f-bcf9-0429da8c6fa6n%40apereo.org.
