Ah, I understand the logging better then. Not only is it logging it's own error, but it's recording the one thrown by the remote server when the logout request fails.
I think I should build that into the spec for client app deployers, i.e. use a client that accepts single log out, or build it into your custom client. Kim ~=|=~ Kim Cary Chief Information Security Officer Pepperdine University On Mon, Dec 14, 2009 at 5:48 AM, Scott Battaglia <[email protected]>wrote: > On Fri, Dec 11, 2009 at 12:39 PM, Kim Cary <[email protected]>wrote: > >> Thanks all, let me just check what's happening here: >> >> CAS server sends single signout to all apps with service tickets for the >> user. >> Some apps don't give the expected response (and give server errors on >> receiving the SSO traffic over https). >> The CAS server doesn't get the expected response from SSO and throws an >> error (OR the CAS server logs the server error from the external app in its >> server log). > > > The CAS server logs the errror (and its own generated error). The error is > not shown to the user though. > > Cheers, > Scott > > > >> >> >> Kim >> >> ~=|=~ >> >> Kim Cary >> Chief Information Security Officer >> Pepperdine University >> >> >> >> On Fri, Dec 11, 2009 at 5:41 AM, Scott Battaglia < >> [email protected]> wrote: >> >>> Created CAS-828 to track it. >>> >>> Cheers, >>> Scott >>> >>> On Fri, Dec 11, 2009 at 8:35 AM, Marvin Addison < >>> [email protected]> wrote: >>> >>>> > The alternative is that if this list agrees we can change the logging >>>> level >>>> > of that error message and possibly not include the entire stack trace >>>> ;-) >>>> >>>> +1 for some change here. It's important to log it, but the stack >>>> trace is both verbose and virtually useless. We just need to know >>>> what URL failed and the HTTP response code. Suggested message text >>>> off the top of my head: >>>> >>>> WARN Single sign out failed for http://example.com/app/?data. >>>> Application returned HTTP 500 response. >>>> >>>> We also see lots of connection failures in our environment, which >>>> should be treated similarly. I'd recommend logging this at WARN since >>>> it has security implications. >>>> >>>> M >>>> >>>> -- >>>> 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 >>> >>> >> -- >> >> 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 > > -- 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
