On Wed, 19 Dec 2001 [EMAIL PROTECTED] wrote:
> Date: Wed, 19 Dec 2001 17:19:20 -0500
> From: [EMAIL PROTECTED]
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Contrary Login Use Case
>
> In the standard use case for declarative security:
>
> 1. The user accesses a page
> 2. Tomcat uses web.xml-based Security Constraints and session data about
> authenticated users to determine whether to fulfill the request or redirect
> to a login or error page.
>
> This is good. But let's say a business analyst decides that in her webapp,
> every user should see page Foo without logging in. In addition a button
> shall be provided in Foo so that the lowly unauthenticated user can be
> authorized to see the page in its full glory, with all the superuser bells
> and whistles. (An example could be how Jive Forums work out of the box.)
>
> In this case, say we are starting at Page A, clicking on a link to some
> login servlet/jsp, and after authenticating, refreshing Page A. This seems
> to me like an awkward case for declarative security, but I don't expect
> sympathy from this hypothetical business analyst. So has anyone advice for
> how to do this? TIA.
>
Here's one approach that should work:
* Make sure that page A is not in the area protected
by a security constraint (so the unauthenticated user
can see it).
* Make the link on A point to a url (call it B) that is
within the protected area.
* Have the servlet or JSP page that B points at do an
immediate redirect back to A.
* When the user clicks the link, they will be authenticated
(because B is protected) and immediately transported
back again to A.
This kind of thing should work for either BASIC or FORM-based
authentication.
Craig
--
To unsubscribe: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
