On Mon, Aug 1, 2011 at 11:24 PM, Andrew Petro <[email protected]> wrote: > If an administrator disables a service from proxying, he expects that > disabling to immediately take effect. If he doesn't want to stop it from > proxying, he wouldn't be disabling it. He wants to interrupt the user's > proxying experiences. If users are presently proxying via an application > that shouldn't be proxying (such that the admin is disabling it from > proxying), that's more likely to be a problem than to be a valid user > experience. > > Applications using PGTs already need to cope with PGTs expiring or otherwise > becoming invalid (e.g. CAS server failure or accidental but explicit user > logout from the CAS server). I'd think expiration or accidental user logout > would expose the user to this user experience interruption far more > frequently than would tightening up this edge case. > > I think toggling a service's ability to proxy in the services registry > should cause its already granted PTs if any to become invalid, should cause > its already granted PGTs if any to become invalid, and should cause it to be > unable to acquire PGTs going forward (that much is current behavior). This > is just what it naturally means for a service to be unable to proxy. A UX > note advising that things don't work as one would expect is less helpful > than just making them work as expected. > > In short, yes, I think this deserves a JIRA and should be addressed, though > I agree it's a fringe edge case and doesn't warrant a critical immediate > fix. > >> I suppose there could be an option for a hard/soft set. > > Please no. > > I considered (and rejected) an argument for not addressing this edge case > because it would increase cas server code complexity more than is justified. > I reject this argument for just the reason you articulate, that the present > behavior is too surprising and should be made to align with expectations. > > But adding the behavior and then making it toggled by additional > configuration? Let's not add the complexity of more configuration for this. > > I just don't see a plausible use case for wanting a service to continue its > existing proxying but be disabled from proxying going forward -- a real > usage of this feature would involve first retiring use of proxied services > from the application being disabled from proxying. If an application's still > legitimately relying on proxying, you wouldn't be disabling it.
Yes, that's what I was fishing for...a plausible use case. I'm convinced we should just tighten up the the behavior and invalidate current PGT/PT of Services that become marked as Can't Proxy. I agree that would likely be most consistent with expected behavior. Bill > > Andrew > > On 08/01/2011 11:15 PM, William G. Thompson, Jr. wrote: >> >> For me I think it comes down to expectations. I was surprise, and >> confused for a bit, when I set the Can't Proxy option, yet was still >> getting proxy tickets. >> >> If you setting this option against a live services, I imagine that >> folks would expect the user experience to get interrupted. >> >> I suppose there could be and option for a hard/soft set. >> >> Bill >> >> >> >> On Mon, Aug 1, 2011 at 9:28 PM, Scott Battaglia >> <[email protected]> wrote: >>> >>> I'm on the fence on this. On the one hand, you'll interrupt the user's >>> experience. On the other hand, its probably technically more correct to >>> disable it (or at least put a note that says that these items take affect >>> going forward and do not affect existing sessions) >>> >>> On Mon, Aug 1, 2011 at 5:16 PM, William G. Thompson, >>> Jr.<[email protected]> >>> wrote: >>>> >>>> Folks, >>>> >>>> Ran into what may be an edge case, but likely easy to fix. Would >>>> like to get your thoughts prior to filing a jira. >>>> >>>> I'm using a sample CasApp that can get a PGT and PT for targetService. >>>> Everything working fine. >>>> >>>> * enable Services Management with proper config, everything still >>>> working >>>> fine. >>>> >>>> Test Case (edge case?): >>>> * Login in to CasApp (get PGT), then disallow proxy on CasApp via >>>> Services Management. >>>> * (haven't logged out of CasApp yet), still fetching PTs with the >>>> previously received PGT. >>>> >>>> Should CAS stop issuing PTs for a PGT from a service that has been >>>> marked as not allowed to proxy in Services Management? >>>> >>>> Bill >>>> >>>> -- >>>> 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-dev >>> >>> -- >>> 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-dev > > > -- > 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-dev > -- 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-dev
