You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Charles McClain <CM...@ATTBI.Com> on 2002/09/24 16:16:37 UTC
Logout in a container-managed security environment
All:
When I first converted my app to use the Struts framework, I cribbed the
login mechanism from the Struts example application. This worked
nicely; besides the initial login function, the combination of the
global "loginpage" forward and the app:checklogin tag (as well as the
login check in the Actions) forced the user to the application login
page if he tried to come into the application "in the middle" via a
bookmark or something. Finally, there was a "logout" action with a
session.invalidate() method call that also threw the user back to the
application login page.
After some reading which recommended container-managed security -- and
also after I decided I would like to use the Jakarta Taglibs
req:isUserInRole tag to vary menus, etc., by user role -- I switched
over to using a Tomcat security constraint.
Everything still works fine -- when the user links to the app "welcome"
page, Tomcat throws up a login dialog, and if he tries to come into the
app "in the middle" via a bookmark, he also is required to login via
Tomcat. However, since the application no longer has its own login page,
I seem to have lost the ability to log him out and require a re-login.
The logout action still performs the session.invalidate() method and
takes him to the "you have logged out" page, but I don't know how to
force the Tomcat login dialog; in other words, if I put a link back to
the "welcome" page on the "you have logged out" page, it just goes back
to the "welcome" page without requiring him to login again.
If he closes the browser, of course, he has to login again, but I'm
looking for the same kind of forced re-login behavior that the original
application-controlled login mechanism gave me.
Any ideas?
Charles McClain
Phone: 603.659.2046
email: cmcclain01@attbi.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logout in a container-managed security environment
Posted by Adam Sherman <ad...@tritus.ca>.
On 09/24/02 13:21:19 -0400, Rick Fincher wrote:
> Form based authorization just lets you use your own HTML page to login
> rather than the browser provided standard login. That lets you create a
> nice looking. more informative login for the user.
I've noticed that the major advantage of using FORM authentication over
BASIC, is that you can forcefully logout a user. With BASIC, you can't.
Period.
A.
--
Adam Sherman
President & Chief Technologist
Tritus CG Inc.
+1 (613) 797-6819
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logout in a container-managed security environment
Posted by Rick Fincher <rn...@tbird.com>.
Hi Charles,
Form based authorization just lets you use your own HTML page to login
rather than the browser provided standard login. That lets you create a
nice looking. more informative login for the user.
Here's a good article from OnJava.com about it.
http://www.onjava.com/pub/a/onjava/2001/08/06/webform.html
Rick
----- Original Message -----
> Eddie:
>
> Thanks for the reply. Yes, I am using BASIC authentication. You
> mention FORM-based authorization, and it sounded to me as if you were
> speaking of another version of container-managed authentication;
> however, I'm not familiar with it. Can you point me in the right
> direction, and I'll do the research?
>
> Also in passing, I should mention that one of the reasons I switched to
> container-managed authentication is that I anticipate my app having to
> run inside a client's portal, and I anticipate that I'll have to avoid a
> 2nd login; in other words, their users will login to the portal, and I
> won't have the option of requiring them to login again to my app.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logout in a container-managed security environment
Posted by Eddie Bush <ek...@swbell.net>.
It all falls under "Container-Managed Authentication". It's just a
different authentication method.
FORM-based authentication is what you see ... on a lot of sites :-)
(either that or custom [roll-your-own] authentication) where you get the
login prompt in the form of an actual page. The keys are:
- submit to action="j_security_check"
- field named "j_username"
- field named "j_password"
You would configure your security-constraints the same way you do now.
This is a servlet specification thing. The only thing that you
(should) have to change is the type of authentication (there is
additional configuration for form-based auth - must specify login page
and error page). Apart from the minor differences in configuration, it
really is as straight-forward as the above. Note that you'll have to
configure a realm for the container to lookup the users in. This could
be a flat-file, a DBMS, or JNDI resource. Of course, you could probably
"roll your own" here too (Tomcat lets you anyway), so you're not really
constrained to using only those provided. For more information on
realms, see your servlet container's user guide - that is container
specific (the configuration is anyway). Oh, nevermind - you had to do
that for BASIC as well - duh. Ok :-) That's really it.
Here is my form-based auth config - it should look strikingly similar to
what you already have ;-)
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/member/login/cmaLogin.jsp</form-login-page>
<form-error-page>/member/login/error.jsp</form-error-page>
</form-login-config>
</login-config>
I reference Jason Hunter's book Java Servlet Programming, and also Hans
Bergsten's book Java Server Pages (both from O'Reilly). Both of them
include information on this topic. I think I tend to refer to Hans'
book more often though ... though I'm not sure why :-) I think it's
because that's the one I have it bookmarked in. You should also be able
to reference the servlet specification itself.
Charles McClain wrote:
>Eddie:
>
>Thanks for the reply. Yes, I am using BASIC authentication. You
>mention FORM-based authorization, and it sounded to me as if you were
>speaking of another version of container-managed authentication;
>however, I'm not familiar with it. Can you point me in the right
>direction, and I'll do the research?
>
>Also in passing, I should mention that one of the reasons I switched to
>container-managed authentication is that I anticipate my app having to
>run inside a client's portal, and I anticipate that I'll have to avoid a
>2nd login; in other words, their users will login to the portal, and I
>won't have the option of requiring them to login again to my app.
>
--
Eddie Bush
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Logout in a container-managed security environment
Posted by Charles McClain <CM...@ATTBI.Com>.
Eddie:
Thanks for the reply. Yes, I am using BASIC authentication. You
mention FORM-based authorization, and it sounded to me as if you were
speaking of another version of container-managed authentication;
however, I'm not familiar with it. Can you point me in the right
direction, and I'll do the research?
Also in passing, I should mention that one of the reasons I switched to
container-managed authentication is that I anticipate my app having to
run inside a client's portal, and I anticipate that I'll have to avoid a
2nd login; in other words, their users will login to the portal, and I
won't have the option of requiring them to login again to my app.
-----Original Message-----
From: Eddie Bush [mailto:ekbush@swbell.net]
Sent: Tuesday, September 24, 2002 10:30 AM
To: Struts Users Mailing List
Subject: Re: Logout in a container-managed security environment
(see below)
Charles McClain wrote:
>All:
>
>When I first converted my app to use the Struts framework, I cribbed
>the login mechanism from the Struts example application. This worked
>nicely; besides the initial login function, the combination of the
>global "loginpage" forward and the app:checklogin tag (as well as the
>login check in the Actions) forced the user to the application login
>page if he tried to come into the application "in the middle" via a
>bookmark or something. Finally, there was a "logout" action with a
>session.invalidate() method call that also threw the user back to the
>application login page.
>
>After some reading which recommended container-managed security -- and
>also after I decided I would like to use the Jakarta Taglibs
>req:isUserInRole tag to vary menus, etc., by user role -- I switched
>over to using a Tomcat security constraint.
>
>Everything still works fine -- when the user links to the app "welcome"
>page, Tomcat throws up a login dialog, and if he tries to come into the
>app "in the middle" via a bookmark, he also is required to login via
>Tomcat. However, since the application no longer has its own login
>page, I seem to have lost the ability to log him out and require a
>re-login. The logout action still performs the session.invalidate()
>method and takes him to the "you have logged out" page, but I don't
>know how to force the Tomcat login dialog; in other words, if I put a
>link back to the "welcome" page on the "you have logged out" page, it
>just goes back to the "welcome" page without requiring him to login
>again.
>
It *sounds* like you're doing it right. One important note is that the
session dies with the request in which it is invalidated - meaning that,
if you expect to see the session disappear right after you invalidate
it, you're going to be disappointed. Once the current request is "dead"
so should be the session. Having a "link to the welcome page" indicates
to me that the user is making another request for that page. That being
the case, I think the session should be dead. Here's how I kill one:
HttpSession session = request.getSession(false);
if (session != null)
session.invalidate();
>If he closes the browser, of course, he has to login again, but I'm
>looking for the same kind of forced re-login behavior that the original
>application-controlled login mechanism gave me.
>
I'm not sure what is going on here. What method of authentication are
you using? I'm not 100% certain, but this could actually be a problem
with BASIC auth (seems I recall hearing something like that, but I could
be mistaken). Why? The browser caches your credentials and gives them
to Tomcat when it asks for them again (with BASIC, I believe).
Personally, I use FORM-based auth.
>Any ideas?
>
>
>Charles McClain
>Phone: 603.659.2046
>email: cmcclain01@attbi.com
>
--
Eddie Bush
--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Logout in a container-managed security environment
Posted by Eddie Bush <ek...@swbell.net>.
(see below)
Charles McClain wrote:
>All:
>
>When I first converted my app to use the Struts framework, I cribbed the
>login mechanism from the Struts example application. This worked
>nicely; besides the initial login function, the combination of the
>global "loginpage" forward and the app:checklogin tag (as well as the
>login check in the Actions) forced the user to the application login
>page if he tried to come into the application "in the middle" via a
>bookmark or something. Finally, there was a "logout" action with a
>session.invalidate() method call that also threw the user back to the
>application login page.
>
>After some reading which recommended container-managed security -- and
>also after I decided I would like to use the Jakarta Taglibs
>req:isUserInRole tag to vary menus, etc., by user role -- I switched
>over to using a Tomcat security constraint.
>
>Everything still works fine -- when the user links to the app "welcome"
>page, Tomcat throws up a login dialog, and if he tries to come into the
>app "in the middle" via a bookmark, he also is required to login via
>Tomcat. However, since the application no longer has its own login page,
>I seem to have lost the ability to log him out and require a re-login.
>The logout action still performs the session.invalidate() method and
>takes him to the "you have logged out" page, but I don't know how to
>force the Tomcat login dialog; in other words, if I put a link back to
>the "welcome" page on the "you have logged out" page, it just goes back
>to the "welcome" page without requiring him to login again.
>
It *sounds* like you're doing it right. One important note is that the
session dies with the request in which it is invalidated - meaning that,
if you expect to see the session disappear right after you invalidate
it, you're going to be disappointed. Once the current request is "dead"
so should be the session. Having a "link to the welcome page" indicates
to me that the user is making another request for that page. That being
the case, I think the session should be dead. Here's how I kill one:
HttpSession session = request.getSession(false);
if (session != null)
session.invalidate();
>If he closes the browser, of course, he has to login again, but I'm
>looking for the same kind of forced re-login behavior that the original
>application-controlled login mechanism gave me.
>
I'm not sure what is going on here. What method of authentication are
you using? I'm not 100% certain, but this could actually be a problem
with BASIC auth (seems I recall hearing something like that, but I could
be mistaken). Why? The browser caches your credentials and gives them
to Tomcat when it asks for them again (with BASIC, I believe).
Personally, I use FORM-based auth.
>Any ideas?
>
>
>Charles McClain
>Phone: 603.659.2046
>email: cmcclain01@attbi.com
>
--
Eddie Bush
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>