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. > -- - 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/dd37a69a-0536-4ab6-9ad2-3561e60b66dan%40apereo.org.
