On Tue, Aug 2, 2011 at 8:39 AM, Scott Battaglia <[email protected]> wrote: > I think you're misunderstanding the tool. Its not an emergency shut off > valve. Its a configuration tool (and its forward looking). > If: > 1. You change the pattern matching, it doesn't go invalidate all services > that no longer match (nor does it ask them to stop using the attributes)
I'm not sure what you mean by "go invalidate all services". If I change the URL for a service in SM, CAS will immediately stop vending STs for that URL, no? Likewise, if I disable the service in SM, those changes will have immediate effect. > 2. You change the attributes (it doesn't go ask all the services to stop > using them, nor does it push out new ones to the existing services). > etc. Do you mean "stop using" the ones the services already has, or "push out new ones" to services with existing sessions? Yes, of course, and I don't think that would be a likely expectation of someone using SM. > Likewise if you say this service isn't allowed to proxy, it won't issue new > proxy granting tickets for that service. Sure, and I would also expect CAS to stop honoring PT requests from that service. Bill > > On Tue, Aug 2, 2011 at 8:36 AM, William G. Thompson, Jr. <[email protected]> > wrote: >> >> 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 >> > > -- > 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
