I agree that adjusting the order of the actions such that the service ticket is issued after the warning page is dismissed is a simple, straightforward solution. I also don't see how this change would affect fulfillment of the CAS protocol or break existing installs. I too would be surprised if folks didn't believe this is how it works already. I don't expect most adopters give this much thought.
Historically, default Service Ticket timeout was 5 minutes rather than 10 seconds, which would have masked this bugged ordering. I too have noticed that some CAS adopters remove the Warn feature, and wonder if the feature should be removed in a future release. Historically CAS didn't have a services registry to restrict which services were using CAS, such that perhaps there was more of a rugged individualist caveat emptor expectation that end users might want to police what services are using CAS to log them in. I'd say that expectation is questionable, in that most end users aren't prepared to cope with giving informed consent for these logins. That is, it's not clear that the warn feature is really adding value. This defect in CAS 3.4.x (that end users can easily subject themselves to a stack trace) and opportunity for CAS 3.5 (to improve the ordering such that STs are issued JIT, after any interstitial warning) both feel like they'd benefit from JIRAs so they can be tracked to completion. I agree that the order change is consistent with a soon CAS 3.5 release. Andrew On Dec 20, 2011, at 12:28 PM, William G. Thompson, Jr. wrote: > On Thu, Dec 15, 2011 at 10:58 AM, Marvin Addison > <[email protected]> wrote: >>> Your only option to support WARN is to increase the service ticket time out >> >> Would it be possible to swap the order of actions in the login flow >> such that the ticket is granted only _after_ the user's acceptance to >> proceed to the service from the warn view? This would have the >> additional benefit of avoiding extraneous ticket generation in case >> the user decides not to visit the service. > > I'm not a big fan the WARN feature as it is, but this seems to me the > most reasonable approach to the issue. Nothing immediately comes to > mind that would make this incompatible with the CAS2 protocol or break > any existing CAS installs using the WARN feature. I'd be surprised if > folks didn't believe this is how it works already. > > This change would be consistent with the 3.5 release scheduled for 1QTR2012. > > Bill > > >> >> 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
