On Tue, Aug 2, 2011 at 10:42 AM, William G. Thompson, Jr. <[email protected]>wrote:
> 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. > Nope it won't. It won't vend NEW service tickets (just like disabling proxying won't vend new PGTs). It however, will not stop existing sessions from working. > > > > 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. > So what you're saying is in some instances you expect it to be instantaneous and affect services and in some instances you don't? > > > 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 > > -- 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
