Thanks for your reply. Perhaps unnecessary redirects, redirects that
happen when a user is logged in already, could be avoided by storing
data via the session with the webapp?
Marvin Addison wrote:
anyone can easily overcome the
ominous resistance for those documents to be understood.
In all fairness, most open source project documentation suffers more
from incompleteness and factual errors than obscurity. But it
doubtless has the same effect on the reader, though, of causing
confusion instead of enlightenment.
the subject still leaves me
confused with the browser never sending the cookie to the webapp but to CAS
instead. How does the webapp know when to redirect the browser to the CAS
login page?
A CAS-enabled application _always_ redirects to the CAS login page on
a new session. It's that simple. You only see the login form if you
don't currently have a valid SSO session or you have to reauthenticate
(e.g. renew=true) for some other reason. Once you have a valid SSO
session, CAS issues a redirect to the original application with a
ticket parameter appended to the request URL. The CAS client securing
the application extracts the ticket and validates it out of band from
the browser.
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
