On Thu, 18 Jul 2002, Mete Kural wrote:
> Date: Thu, 18 Jul 2002 08:46:46 -0700 (PDT)
> From: Mete Kural <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: Re: Struts/Container-Managed Authentication Question
>
> Hello Craig,
>
> --- "Craig R. McClanahan" <[EMAIL PROTECTED]> wrote:
> > If you are using container-managed security, you
> > either declare a security
> > constraint (to force a login) or you don't -- there
> > is no middle ground.
> > However, if the user went to your second sub-app
> > first, and then went to
> > the first one, the fact that they have logged in is
> > visible to your
> > application, because getRemoteUser() will still
> > return the logged-in
> > user's identity.
>
> That's exactly what I want to happen. To preserve the
> loggedinness of the user even when they go out of the
> protected area into the public area.
>
> > There is no such mechanism that is portable across
> > containers. If you
> > want to use container managed security, you should
> > architect your
> > application inside its boundaries -- otherwise, you
> > should roll your own.
>
> Hmm.. I hope the JCP will include such a mechanism in
> Servlet 2.4. It would be nice to enable pre-processing
> on the form-based login submission in a servlet and
> then submit that to the container. Perhaps this is not
> a valid use case, but it seems to me that it may be
> attractive in certain scenarios.
>
It's not going to make it for Servlet 2.4 (which is currently in public
review, so you can see the proposed changes for yourself). Dealing with
*all* of the issues required to make some sort of authentication plugin to
containers is probably a year's worth of of Expert Group work to define an
appropriate specification.
> > Quite frankly, I'm not convinced your use case is
> > very compelling, but I
> > undoubtedly don't understand the whole picture,
> > either.
>
> Think about Amazon.com. On Amazon, you can surf
> through the shopping pages with or without being
> logged in to your Amazon account. If you're logged in,
> some special features are enabled such as personal
> book recommendations on the sides of the pages. If
> you're not logged in it just treats you like a default
> customer that it doesn't know about. In this case, it
> is necessary to provide a login mechanism to better
> serve the customer even if login is not required.
>
Nothing stops you from accomplishing exactly this functionality. The
page you describe would *not* be protected by a security constraint -- but
the logic that produces that page can tell if a user is logged in or not
(call request.getUserPrincipal() or request.getRemoteUser()) and vary the
generated HTML based on whether this value is null or not.
> >
> > Craig
>
> Thanks,
> Mete
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
