CAS SingleSignOutFilter problems

[Steve Podell]

Hi Scott,
   Yes Single Sign Out events are in the log, but the requests don't get 
made.  I use an "HTTP Analyzer" (http://www.ieinspector.com) to debug 
these things, and I see all the other requests, but not these logout 
requests.

 From the log (the URLs look right):
DEBUG 110408.123441 - Sending logout request for: 
https://mtdemo.iii.com:443/iii/mfrpro/j_acegi_cas_security_check
DEBUG 110408.123441 - Sending logout request for: 
https://mtdemo.iii.com:443/iii/encore/j_acegi_cas_security_check

Thanks,
Steve


Scott Battaglia wrote:
> If you turn on DEBUG logging for the CAS server, you should be able to 
> see messages that say "Sending logout request for: {serviceId}".  Can 
> you confirm that?
>
> Thanks
> -Scott
>
> On Thu, Apr 10, 2008 at 6:59 PM, Steve Podell <spodell at iii.com 
> <mailto:spodell at iii.com>> wrote:
>
>     I upgraded to CAS Server 3.2.1 RC2 and after some changes in our
>     code we are back up and running.   The problem is that I still
>     don't see any posts to the other registered services.   I don't
>     see any posts at all after logging out (going to /cas/logout). 
>     Just a series of GETs.
>
>     Is there some other configuration that is necessary to turn on the
>     POSTs for Single Sign Out?
>
>
>     Thanks,
>     Steve 
>
>     Scott Battaglia wrote:
>>
>>
>>     On Thu, Apr 3, 2008 at 5:40 PM, Steve Podell <spodell at iii.com
>>     <mailto:spodell at iii.com>> wrote:
>>
>>         CAS is working great for our webapps.  I need to add single
>>         signout to
>>         our setup to do some cleanup in the soon to be invalidated
>>         sessions on
>>         logout.  So I added the Single Sign out filter and listener
>>         as described
>>         here...
>>         http://www.ja-sig.org/wiki/display/CASC/Configuring+Single+Sign+Out
>>
>>         I am using cas-server-core-3.1.jar
>>
>>         When I set a debugger breakpoint in
>>         org.jasig.cas.client.session.SingleSignOutFilter, I can see
>>         requests
>>         coming through, but I never see a POST, so the request parameter
>>         "logoutRequest" is not acted on. I also don't see the
>>         artifactParameterName/"ticket" parameter coming through
>>         either, so the
>>         the session references are not being cached.
>>
>>         The wiki page
>>         http://www.ja-sig.org/wiki/display/CASUM/Single+Sign+Out
>>         mentions an ArgumentExtractor property called
>>         disableSingleSignOut, but
>>         I don't see where you would set it (and have not set it).
>>
>>         When I watch the requests on a http analyzer on my PC, there
>>         is an early
>>         POST on the login to cas that does contain the ticket on the
>>         response.
>>         But a client side filter would not see the response...?
>>
>>         -  Process : firefox.exe[2748]
>>         (COUNT=25)
>>
>>           8     13:03:14:453  0.264 s      POST    302     0    
>>         text/plain
>>         https:///iii/cas/login;jsessionid=3C16428223AD4231E9079B8B50804C19?service=https%3A%2F%2Fmtdemo.iii.com%3A443%2Fiii%2Fmfrpro%2Fj_acegi_cas_security_check
>>
>>         https://mtdemo.iii.com:443/iii/mfrpro/j_acegi_cas_security_check?ticket=ST-5-SfMWDEiDcVLVoLxsaEbYfcT3ZXTupEvGHHB-20
>>
>>         So some basic questions:
>>         1) This filter is client side cache of tickets and sessions?
>>
>>     The filter is a client side filter so it should be set on the
>>     applications.
>>
>>
>>         2) I should be seeing logoutRequest POSTs to the webapp so
>>         that the CAS
>>         client code can cache the tickets?
>>
>>     You'll only see the POST when you actually log out of CAS.
>>
>>
>>         3) I should be seeing POSTs with "ticket" as a request parameter?
>>
>>     No you should only be seeing GETs with tickets.
>>
>>
>>         4) This feature is in cas-server-core-3.1?
>>
>>     Your best bet is to use CAS Server 3.2.1 for Single Sign Out.
>>
>>
>>         5) The feature defaults to "on"? The ArgumentExtractor
>>         properties are
>>         already set up?
>>
>>     In CAS 3.2.1 it defaults  to on.  3.2 had an accidental bug
>>     flipping a ! so it was defaulted to off, but appeared to be on.
>>
>>     -Scott
>>
>>
>>         _______________________________________________
>>         Yale CAS mailing list
>>         cas at tp.its.yale.edu <mailto:cas at tp.its.yale.edu>
>>         http://tp.its.yale.edu/mailman/listinfo/cas
>>
>>
>>
>>
>>     -- 
>>     -Scott Battaglia
>>     PGP Public Key Id: 0x383733AA
>>     LinkedIn: http://www.linkedin.com/in/scottbattaglia 
>
>
>
>
> -- 
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas/attachments/20080411/349ffe19/attachment.html