On Wed, 17 Jul 2002, Mete Kural wrote:
> Date: Wed, 17 Jul 2002 18:32:17 -0700 (PDT)
> From: Mete Kural <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Struts/Container-Managed Authentication Question
>
> Hi,
>
> My Struts-based webapp has two sub-apps.
>
> In the first sub-app, anybody can surf through without
> having to be logged in, but if you are logged in, some
> special features are enabled (ex: "Hello Mr. ..").
>
> In the second sub-app, you have to be logged in to
> access the pages therein.
>
> For the entirety of the second sub-app, obviously a
> security-constraint should be declared in web.xml. But
> the first sub-app is open to anybody, although login
> is encouraged (i.e. not required). For that reason, I
> can't put a security-constraint for the first sub-app
> in web.xml, but how am I going to authorize users who
> want to log in while they're in the first sub-app in a
> container-managed manner??
>
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.
> Basically what I want to do is to log a user in with
> the container from a LoginAction class, rather than
> the good-old "j_security" way. Maybe this one should
> be asked to the Tomcat group, but in case some of you
> may know, Is there a way to log a user in with the
> container through a method interface inside an Action
> class instead of dispatching the request to
> j_security_constraint? I couldn't find such a method
> interface in the Servlet 2.3 specs.
>
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.
Quite frankly, I'm not convinced your use case is very compelling, but I
undoubtedly don't understand the whole picture, either.
> I'll appreciate any insight on this.
>
> Thanks,
> Mete Kural
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
