Phil, Thanks for putting on the right trail -- I think I have it figured out -- when exploring cookies in the browser, we discovered that our application was generating more than one cookie, for each URL.
Example: one cookie for foo.com/app/mydepartment/, another cookie for foo.com/app/search/ another one for foo.com/app/wildcard/....etc. So I looked at your README again, and see that there is a CASScope directive that can be used. I added CASScope /app/ in the <Files> section that requires CAS auth, and initial tests show this to work. Thanks! DW On Tue, Mar 8, 2011 at 4:14 PM, Phil Ames <[email protected]> wrote: > 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
