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.
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
