The very first request in your logs doesn't have a MOD_AUTH_CAS_S cookie because the user has not made a round trip to the CAS server, received a ticket, and been issued a MOD_AUTH_CAS_S cookie by mod_auth_cas itself.
Because there is no MOD_AUTH_CAS_S cookie, mod_auth_cas treats this as an unauthenticated request, and redirects the user to the CAS server for authentication. You can see that when it comes back from the CAS server, there is a "Set-Cookie: MOD_AUTH_CAS_S=[...]" header in the reply. Unfortunately, due to the way that mod_auth_cas and HTTP work, the way this redirection to and back from the CAS server is accomplished uses HTTP 302, which results in a GET request, thereby converting the HTTP verb from POST to GET. If I had to venture a guess, it would be that whatever page you visit which contains the <form> tag to POST to the authenticated URL is available without authentication. Does that help clarify why this is behaving this way? -Phil On Tue, Mar 8, 2011 at 4:05 PM, Duane Winner <[email protected]> wrote: > Hi Phil, > > I'm still not clear about this; Why isn't there a MOD_AUTH_CAS_S cookie? > > I do have CASCookiePath /tmp/cas/ directive and can see the cookies > being cached on the server, and there are no issues with GETS and > navigating the webapp after a user is logged on, it's just that first > POST that wants to validate again against the client's CAS server? I > should also note that after that first POST generates the application > error, the user can hit back page, submit again, and then it's fine. > > You state that "For this to work as you expect, your users will need > to log in via CAS before submitting POST requests to the > application.", but that is what we are doing -- I only submitted the > headers and logs for the POST action, not the entire session. The > entire application requires CAS authentication, and there are no > issues navigating the application or GETS, it's just the first POST. > > Am I still missing an apache directive? > > Thanks, > DW > > > > On Tue, Mar 8, 2011 at 3:19 PM, Phil Ames <[email protected]> wrote: > > In the first request, there is no MOD_AUTH_CAS_S cookie. This is what > > results in the user being redirected to the CAS server. The CAS server > > redirects it back to the supplied service URL (this is a GET request), > which > > is why the POST data is lost. This is essentially the same as supplying > an > > invalid (read: expired) MOD_AUTH_CAS_S cookie. > > For this to work as you expect, your users will need to log in via CAS > > before submitting POST requests to the application. Alternatively, since > > all the parameters are being passed in the query string anyway, you could > > modify the application to run the appropriate search (I'm guessing that's > > what it's doing) in the GET handler instead of POST. > > -Phil > > > > On Tue, Mar 8, 2011 at 3:10 PM, Duane Winner <[email protected]> > wrote: > >> > >> Got it. > >> > >> Anything in particular I should be looking for in the logs specific to > >> CAS? I'm not sure what I'm looking for at this point, but I have > >> captured the submit transactions that generates the application error > >> in the apache logs. I've also captured the http headers in the > >> browser. I can attach them if it something that would help. > >> > >> Thanks, > >> DW > >> > >> > >> On Tue, Mar 8, 2011 at 2:25 PM, Phil Ames <[email protected]> wrote: > >> > Please make sure the VirtualHost has LogLevel debug. > >> > > >> > On Tue, Mar 8, 2011 at 2:24 PM, Duane Winner <[email protected]> > >> > wrote: > >> >> > >> >> I just added the CASDebug On directive a few minutes ago > >> >> > >> >> -- where should I see debugging output? I'm looking in the apache > logs > >> >> and not seeing anything additional > >> >> > >> >> On Tue, Mar 8, 2011 at 2:20 PM, Phil Ames <[email protected]> > wrote: > >> >> > No, those are the timeouts I'm referring to. Do you have HTTP > traces > >> >> > of > >> >> > when this problem occurs, as well as CASDebug On/LogLevel debug > logs? > >> >> > -Phil > >> >> > > >> >> > On Tue, Mar 8, 2011 at 1:56 PM, Duane Winner <[email protected] > > > >> >> > wrote: > >> >> >> > >> >> >> Thanks for the reply. > >> >> >> > >> >> >> I'm not specifying either of these as an apache directive, but > >> >> >> according to the README, the defaults are way beyond the window in > >> >> >> which I've tested this and replicated the error (under 5 minutes). > >> >> >> > >> >> >> Directive: CASTimeout > >> >> >> Default: 7200 (2 hours) > >> >> >> Directive: CASIdleTimeout > >> >> >> Default: 3600 (1 hour) > >> >> >> > >> >> >> Or are you referring to something else I should be looking at? > >> >> >> > >> >> >> Thanks again, > >> >> >> -DW > >> >> >> > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Tue, Mar 8, 2011 at 1:49 PM, Phil Ames <[email protected]> > >> >> >> wrote: > >> >> >> > It's possible that the user's mod_auth_cas session has expired, > >> >> >> > and > >> >> >> > they > >> >> >> > were redirected to the CAS server to obtain a new ticket. This > >> >> >> > redirect > >> >> >> > causes the loss of the POST data, and results in an HTTP GET > when > >> >> >> > the > >> >> >> > CAS > >> >> >> > server redirects the user to the service URL. > >> >> >> > -Phil > >> >> >> > > >> >> >> > On Tue, Mar 8, 2011 at 12:58 PM, DW <[email protected]> > wrote: > >> >> >> >> > >> >> >> >> Hello, we host a web-based application, and a client of ours > has > >> >> >> >> a > >> >> >> >> CAS > >> >> >> >> server so we installed mod_auth_cas when the asked for > >> >> >> >> Single-Sign-On. > >> >> >> >> > >> >> >> >> I compiled and installed mod_auth_cas-1.0.8.1 on apache 2.2, > and > >> >> >> >> it > >> >> >> >> works > >> >> >> >> for the most part, but we are running into issues where we have > a > >> >> >> >> submission > >> >> >> >> form and when submitted our application generates an error. A > >> >> >> >> trace > >> >> >> >> shows > >> >> >> >> that what should have been a POST was converted to a GET. If we > >> >> >> >> turn > >> >> >> >> off > >> >> >> >> CAS/SSO, then everything works fine. > >> >> >> >> > >> >> >> >> Can any provide any insight? > >> >> >> >> > >> >> >> >> global: > >> >> >> >> LoadModule auth_cas_module > >> >> >> >> /usr/local/apache/modules/mod_auth_cas.so > >> >> >> >> CASCookiePath /tmp/cas/ > >> >> >> >> > >> >> >> >> In virtualhost section: > >> >> >> >> CASLoginURL https://foo.com/cas/login?view=showx > >> >> >> >> CASValidateURL https://foo.com/cas/serviceValidate > >> >> >> >> CASCertificatePath > >> >> >> >> /home/vhosts/bar/profile/ssl/gd_bundle.certificate > >> >> >> >> CASValidateServer Off > >> >> >> >> > >> >> >> >> > >> >> >> >> Thanks, > >> >> >> >> DW > >> >> >> >> -- > >> >> >> >> You are currently subscribed to [email protected] as: > >> >> >> >> [email protected] > >> >> >> >> To unsubscribe, change settings or access archives, see > >> >> >> >> http://www.ja-sig.org/wiki/display/JSG/cas-user > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> > > >> > > > > > > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
