Ran into the same issue with v6.6.8 and v6.6.14. Also removed the line in InitialFlowSetupAction.java that sets empty cookie and I get proper session now. But this does not look like a correct fix.
On Monday, January 11, 2021 at 4:00:17 PM UTC-6 Ulrich Mayring wrote: > Ray, > thanks a lot for your comments. I believe this more or less settles the > issue that we have a bug here, but it doesn't bite everyone. So I suppose > those, who are unaffected, can just carry on. > > We have fixed the issue in our overlay by simply removing the code that > sets the "empty" cookie. If you ever find that the order of cookies changes > on you, you can do the same thing. Our test suite is green, so I guess that > for our purposes this rather brute-force fix will work. I have no idea what > it would take to fix this in CAS main, but I did notice that the code to > remove a cookie was changed from using the Servlet API to a custom > implementation, where the header is set manually. So perhaps going back to > using the Servlet API (response.addCookie) would be enough. > > On Monday, 11 January 2021 at 17:25:28 UTC+1 Ray Bon wrote: > >> Ulrich, >> >> You are correct. >> And I do receive the cookies with the expired cookie first. >> >> Ray >> >> On Sat, 2021-01-09 at 11:39 -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. >> >> Ray, >> the section you refer to applies to the "Cookie" header the browser sends >> back. However, I was talking about the "Set-Cookie" header sent by the >> server. Its semantics are defined in section 4.1.2 of the RFC and it >> clearly states that the server can delete a cookie by sending a Set-Cookie >> header with an expired date. >> >> What's more, RFC 6265 clearly states that the server SHOULD NOT include >> more than one Set-Cookie header field in the same response with the same >> cookie-name. So CAS clearly is in violation of that. Most user-agents will >> probably react to that by accepting the last Set-Cookie header and so the >> order of those headers really matters. >> >> Therefore my question to you was whether you are receiving the >> "Set-Cookie" headers in a different order than I am, because that would >> explain why your browser processes them differently. >> >> Kind regards, >> Ulrich >> On Friday, 8 January 2021 at 21:01:44 UTC+1 Ray Bon wrote: >> >> Ulrich, >> >> According to, https://tools.ietf.org/html/rfc6265, in particular 4.2.2, >> the order of cookies in the header should not matter. >> Is it possible that the app server is setting/modifying the order? >> I am using tomcat 9. >> >> Ray >> >> On Fri, 2021-01-08 at 10:01 -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. >> >> 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. >> >> -- >> >> >> 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/b926e5bf-6fc0-4ed5-bc54-046f34db9ab7n%40apereo.org.
