Le 2011-11-05 06:13, Marvin Addison a écrit :
I guess what I was really looking for is a way of making sure the handlers
get run again.
I can say from experience that you can do just about anything you can
imagine with Spring Webflow. We don't have any documentation on the
makeup of the CAS login webflow because it's basically
self-documenting. (Assuming the reader has general SWF background.)
Is there a way of having those run during authentication, AND during any
redirection to the service, AND store information in the session for
later
retrieval?
Your mention of session is concerning. Storing data in the SWF flow
scope is synonymous with session storage (since it uses that under the
hood), but it's important that you understand the scope of the login
webflow is relatively short. It begins when the user first hits the
login form, and in the case of successful authentication ends with the
generation of a service ticket. The flow state effectively evaporates
at that point.
More generally, even if you were to store data directly in the
session, it would be unreliable at best since interaction with CAS is
sporadic and you'd likely have session timeouts where your session
data on the CAS server is lost. So if you mean session to be the
lifetime of a CAS SSO session, then both flow storage and underlying
session storage is unsuitable for your needs. At that point your
integration scenario becomes much more complex since you'd need to
store your data into a durable store like that used by TicketRegistry,
for example.
We have an issue that we want to deal with. The handlers we have, detect
if the user needs to change their password (due to a bad one, for example),
and a variety of other things regarding the state of their login account.
If there is something wrong with their account, we redirect them to a
service to change their password. So, in the case of the password check
handler, we can't just re-run it, because we no longer know the password,
because the SSO session is established. However, if we could store the
resulting "state" of the handlers, we wouldn't need to re-run them.
I'm not concerned with session timeouts, seeing that the original handlers
would run again during the authentication process.
All fine and dandy. But, if they simply hit the back button (to CAS), it
forwards them to the service they wanted to be at, rather than forcing them
back to the password manager.
I was hoping to solve this at the CAS level, rather than at the password
manager application level. IMO, it's a hack to mess around with forced
redirects at the password manager application, to render the browser back
button unusable. I could also do a JavaScript hack to clear the previous
history, but again, that's a hack. I'm not aware of any "proper" way of
preventing back buttons from working, other than maybe forcing a "post" to
CAS at the end, to force the browser to say "hey, you shouldn't do that".
After the password manager, we redirect back to CAS, with the original
service URL. I was hoping to append an extra parameter to CAS that I could
pick up, to wipe out the handler "state" mentioned earlier. This would
allow further passes through CAS to pass through un-interrupted.
If someone has an idea on how to deal with that, other than through CAS,
I'm all ears. :P
--
Trenton D. Adams
Senior Systems Analyst/Web Software Developer
Navy Penguins at your service!
Athabasca University
(780) 675-6195
:wq!
--
This communication is intended for the use of the recipient to whom it
is addressed, and may contain confidential, personal, and or privileged
information. Please contact us immediately if you are not the intended
recipient of this communication, and do not copy, distribute, or take
action relying on it. Any communications received in error, or
subsequent reply, should be deleted or destroyed.
---
--
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<http://www.ja-sig.org/wiki/display/JSG/cas-user>
