Fwd: session.invaludate(); not working in LogoffAction
oops meant to send this to the list as well. -- Forwarded message -- From: David Johnson <[EMAIL PROTECTED]> Date: Tue, 8 Mar 2005 09:15:52 -0500 Subject: Re: session.invaludate(); not working in LogoffAction To: Max Cooper <[EMAIL PROTECTED]> Well, it's interesting actually. What I have is a simple login screen that validates login and password against a database. the FINAL version of this application will have to validate against my client's SSO (which I at this point know nothing about) So, I'm thinking that for now, I'll just use the DB validation, then put the UserID in the session scope, then check for it in in every action class. The logoutAction will null out the userID... am I over simplifying? On Mon, 07 Mar 2005 17:12:38 -0800, Max Cooper <[EMAIL PROTECTED]> wrote: > Are you using HTTP BASIC authentication? If you get a login dialog box, > as opposed to a login web page, you are probably using HTTP BASIC > authentication. If so, the browser remembers the login and automatically > sends it to the app with each request, which will log the user in again > if they revisit a page after logging out. > > FORM-based authentication does not have this issue. So one resolution > would be to switch to form-based authentication. > > To stay with BASIC, I think you could delete/expire the auth cookie as > part of the logout action. I haven't tried this before, but it seems > like it might work. > > Tell us more about your authentication system and we can help you find a > solution to the problem. > > -Max > > On Mon, 2005-03-07 at 16:44 -0500, David Johnson wrote: > > hi all > > > > have a logoff action, and inside it I do the following. > > > > // Clean up the session if there is one > > HttpSession session = request.getSession(); > > session.invalidate(); > > > > When I watch what's happening in the manager application (I'm using > > Tomcat) the number of sessions does not decrease, and I can back up in > > the browser and call actions, all of which have code to check for a > > valid session.. > > > > This raises a question.. what's the best way in my web-app to make > > sure the user is valid? should I check in **every** action? > > > > -- -Dave [EMAIL PROTECTED] -- -Dave [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: session.invaludate(); not working in LogoffAction
Are you using HTTP BASIC authentication? If you get a login dialog box, as opposed to a login web page, you are probably using HTTP BASIC authentication. If so, the browser remembers the login and automatically sends it to the app with each request, which will log the user in again if they revisit a page after logging out. FORM-based authentication does not have this issue. So one resolution would be to switch to form-based authentication. To stay with BASIC, I think you could delete/expire the auth cookie as part of the logout action. I haven't tried this before, but it seems like it might work. Tell us more about your authentication system and we can help you find a solution to the problem. -Max On Mon, 2005-03-07 at 16:44 -0500, David Johnson wrote: > hi all > > have a logoff action, and inside it I do the following. > > // Clean up the session if there is one > HttpSession session = request.getSession(); > session.invalidate(); > > When I watch what's happening in the manager application (I'm using > Tomcat) the number of sessions does not decrease, and I can back up in > the browser and call actions, all of which have code to check for a > valid session.. > > This raises a question.. what's the best way in my web-app to make > sure the user is valid? should I check in **every** action? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: session.invaludate(); not working in LogoffAction
This approach is also useful for other logged in redirection type things on
login, such as checking to see a logged in user has agreed to the latest
Terms of Service.
> -Original Message-
> From: Günther Wieser [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 07, 2005 7:04 PM
> To: 'Struts Users Mailing List'
> Subject: RE: session.invaludate(); not working in LogoffAction
>
> i prefer to write my own RequestProcessor which does all the checking and
> handling in case of "user not logged in".
> and even more preferable is to implement J2EE security which was
> suprisingly
> simple (at least for Resin).
>
> i wrote an example for the request processor stuff a few days ago here in
> the list, here it is again:
> --
> public class MyRequestProcessor extends TilesRequestProcessor {
>
> public void process(HttpServletRequest req, HttpServletResponse res)
> throws IOException, ServletException {
> HttpSession session = req.getSession();
> String path = super.processPath(req, res);
> String url = req.getRequestURL().toString();
> String queryString = req.getQueryString();
> // the next lines are there to allow deep linking
> // we store the url that has been requested for future use
> if ((queryString!=null) && (!"".equals(queryString))) {
> url = url + "?" + queryString;
> }
> if (session.getAttribute(Constants.SESSION_LOGIN_REFER_KEY)
> == null) {
> if (url != null) {
>
> session.setAttribute(Constants.SESSION_LOGIN_REFER_KEY, url);
> }
> else {
> //TODO: get main URL from property
>
> session.setAttribute(Constants.SESSION_LOGIN_REFER_KEY,
> "http://localhost:8080/WebCreator/index.do";);
> }
> }
> // no comes the important stuff
> if (!checkForRealm(session)) {
> if (!"/login".equals(path)) {
> super.doForward("/login.do", req, res);
> }
> }
> super.process(req, res);
> }
>
> protected boolean checkForRealm(HttpSession session)
> throws ServletException, IOException {
> if (session.getAttribute(Constants.SESSION_USER_KEY) != null
> ) {
> return true;
> }
> else {
> return false;
> }
> }
> }
>
> so what it does is:
> - get the current requested url for further reference and stores it in the
> session if an atrribute with the same key does not exist (see "deep
> linking"
> below")
> - then it checks the session for the realm (that is the attribute that you
> use to say "the user is logged in")
> - if it does not exist and if the request didn't go to /login.do, it
> forwards the request to the action /login.do (which is a simple html with
> username/password field)
> - if it exists it redirects to the super class to process the request as
> usual
> - you need to implement the checkRealm() method with whatever you need to
> check, my example is really simple but very common
>
> with extending TileRequestProcessor (don't care that i extend
> TilesRequestProcessor, you can extend the standard request processor the
> same way) and adding the lines in struts-config.xml, each request that
> hits
> the struts action servlet will go through MyRequestProcessor BEFORE the
> typical struts tasks (action, form beans filling, etc) start. so this is
> the
> right place to check security, authorization and authentication.
>
> regarding "deep linking": i want my customers to be able to store a
> bookmark
> that points deep into the system. when they request this bookmark, they of
> course need to login first. so i store the requested url in the session,
> and
> if the login is successfull, i send a redirect to the browser to disply
> the
> page the user requested with his bookmark.
> this is done by sending a meta refresh command in the head of the
> resulting
> "login ok" page, with the url containing the session attribute that has
> been
> store with "session.setAttribute(Constants.SESSION_LOGIN_REFER_KEY, url)"
>
> hope that helps, feel free to ask more if something is unclear.
> ---
>
> kr,
> guenther
>
> -Original Message-
&g
RE: session.invaludate(); not working in LogoffAction
This approach is also useful for other logged in redirection type things on
login, such as checking to see a logged in user has agreed to the latest
Terms of Service.
> -Original Message-
> From: Günther Wieser [mailto:[EMAIL PROTECTED]
> Sent: Monday, March 07, 2005 7:04 PM
> To: 'Struts Users Mailing List'
> Subject: RE: session.invaludate(); not working in LogoffAction
>
> i prefer to write my own RequestProcessor which does all the checking and
> handling in case of "user not logged in".
> and even more preferable is to implement J2EE security which was
> suprisingly
> simple (at least for Resin).
>
> i wrote an example for the request processor stuff a few days ago here in
> the list, here it is again:
> --
> public class MyRequestProcessor extends TilesRequestProcessor {
>
> public void process(HttpServletRequest req, HttpServletResponse res)
> throws IOException, ServletException {
> HttpSession session = req.getSession();
> String path = super.processPath(req, res);
> String url = req.getRequestURL().toString();
> String queryString = req.getQueryString();
> // the next lines are there to allow deep linking
> // we store the url that has been requested for future use
> if ((queryString!=null) && (!"".equals(queryString))) {
> url = url + "?" + queryString;
> }
> if (session.getAttribute(Constants.SESSION_LOGIN_REFER_KEY)
> == null) {
> if (url != null) {
>
> session.setAttribute(Constants.SESSION_LOGIN_REFER_KEY, url);
> }
> else {
> //TODO: get main URL from property
>
> session.setAttribute(Constants.SESSION_LOGIN_REFER_KEY,
> "http://localhost:8080/WebCreator/index.do";);
> }
> }
> // no comes the important stuff
> if (!checkForRealm(session)) {
> if (!"/login".equals(path)) {
> super.doForward("/login.do", req, res);
> }
> }
> super.process(req, res);
> }
>
> protected boolean checkForRealm(HttpSession session)
> throws ServletException, IOException {
> if (session.getAttribute(Constants.SESSION_USER_KEY) != null
> ) {
> return true;
> }
> else {
> return false;
> }
> }
> }
>
> so what it does is:
> - get the current requested url for further reference and stores it in the
> session if an atrribute with the same key does not exist (see "deep
> linking"
> below")
> - then it checks the session for the realm (that is the attribute that you
> use to say "the user is logged in")
> - if it does not exist and if the request didn't go to /login.do, it
> forwards the request to the action /login.do (which is a simple html with
> username/password field)
> - if it exists it redirects to the super class to process the request as
> usual
> - you need to implement the checkRealm() method with whatever you need to
> check, my example is really simple but very common
>
> with extending TileRequestProcessor (don't care that i extend
> TilesRequestProcessor, you can extend the standard request processor the
> same way) and adding the lines in struts-config.xml, each request that
> hits
> the struts action servlet will go through MyRequestProcessor BEFORE the
> typical struts tasks (action, form beans filling, etc) start. so this is
> the
> right place to check security, authorization and authentication.
>
> regarding "deep linking": i want my customers to be able to store a
> bookmark
> that points deep into the system. when they request this bookmark, they of
> course need to login first. so i store the requested url in the session,
> and
> if the login is successfull, i send a redirect to the browser to disply
> the
> page the user requested with his bookmark.
> this is done by sending a meta refresh command in the head of the
> resulting
> "login ok" page, with the url containing the session attribute that has
> been
> store with "session.setAttribute(Constants.SESSION_LOGIN_REFER_KEY, url)"
>
> hope that helps, feel free to ask more if something is unclear.
> ---
>
> kr,
> guenther
>
> -Original Message-
&g
RE: session.invaludate(); not working in LogoffAction
i prefer to write my own RequestProcessor which does all the checking and
handling in case of "user not logged in".
and even more preferable is to implement J2EE security which was suprisingly
simple (at least for Resin).
i wrote an example for the request processor stuff a few days ago here in
the list, here it is again:
--
public class MyRequestProcessor extends TilesRequestProcessor {
public void process(HttpServletRequest req, HttpServletResponse res)
throws IOException, ServletException {
HttpSession session = req.getSession();
String path = super.processPath(req, res);
String url = req.getRequestURL().toString();
String queryString = req.getQueryString();
// the next lines are there to allow deep linking
// we store the url that has been requested for future use
if ((queryString!=null) && (!"".equals(queryString))) {
url = url + "?" + queryString;
}
if (session.getAttribute(Constants.SESSION_LOGIN_REFER_KEY)
== null) {
if (url != null) {
session.setAttribute(Constants.SESSION_LOGIN_REFER_KEY, url);
}
else {
//TODO: get main URL from property
session.setAttribute(Constants.SESSION_LOGIN_REFER_KEY,
"http://localhost:8080/WebCreator/index.do";);
}
}
// no comes the important stuff
if (!checkForRealm(session)) {
if (!"/login".equals(path)) {
super.doForward("/login.do", req, res);
}
}
super.process(req, res);
}
protected boolean checkForRealm(HttpSession session)
throws ServletException, IOException {
if (session.getAttribute(Constants.SESSION_USER_KEY) != null
) {
return true;
}
else {
return false;
}
}
}
so what it does is:
- get the current requested url for further reference and stores it in the
session if an atrribute with the same key does not exist (see "deep linking"
below")
- then it checks the session for the realm (that is the attribute that you
use to say "the user is logged in")
- if it does not exist and if the request didn't go to /login.do, it
forwards the request to the action /login.do (which is a simple html with
username/password field)
- if it exists it redirects to the super class to process the request as
usual
- you need to implement the checkRealm() method with whatever you need to
check, my example is really simple but very common
with extending TileRequestProcessor (don't care that i extend
TilesRequestProcessor, you can extend the standard request processor the
same way) and adding the lines in struts-config.xml, each request that hits
the struts action servlet will go through MyRequestProcessor BEFORE the
typical struts tasks (action, form beans filling, etc) start. so this is the
right place to check security, authorization and authentication.
regarding "deep linking": i want my customers to be able to store a bookmark
that points deep into the system. when they request this bookmark, they of
course need to login first. so i store the requested url in the session, and
if the login is successfull, i send a redirect to the browser to disply the
page the user requested with his bookmark.
this is done by sending a meta refresh command in the head of the resulting
"login ok" page, with the url containing the session attribute that has been
store with "session.setAttribute(Constants.SESSION_LOGIN_REFER_KEY, url)"
hope that helps, feel free to ask more if something is unclear.
---
kr,
guenther
-Original Message-
From: Leon Rosenberg [mailto:[EMAIL PROTECTED]
Sent: Monday, March 07, 2005 10:52 PM
To: 'Struts Users Mailing List'
Subject: Re: session.invaludate(); not working in LogoffAction
Graig will blame for not using Filters (they would do the job too), but I'd
say "yes":
Create a "BaseAction", all your actions are extending from, with:
public ActionForward execute(
ActionMapping mapping,
ActionForm bean,
HttpServletRequest req,
HttpServletResponse res)
throws Exception {
if (isAuthorizationRequired()){
boolean authorized = checkAuthorization(req);
if (!authorized){
Re: session.invaludate(); not working in LogoffAction
Graig will blame for not using Filters (they would do the job too), but I'd
say "yes":
Create a "BaseAction", all your actions are extending from, with:
public ActionForward execute(
ActionMapping mapping,
ActionForm bean,
HttpServletRequest req,
HttpServletResponse res)
throws Exception {
if (isAuthorizationRequired()){
boolean authorized = checkAuthorization(req);
if (!authorized){
String redUrl =
req.getContextPath()+"your_login_action_path";
res.sendRedirect(redUrl);
return null;
}
}
ActionForward forward = doExecute(mapping, bean, req, res);
return forward;
}
protected abstract boolean isAuthorizationRequired();
public abstract ActionForward doExecute(
ActionMapping mapping,
ActionForm af,
HttpServletRequest req,
HttpServletResponse res)
throws Exception;
Now in actions you want to protect overwrite authorizationRequired returning
true.
And implement the checkAuthorization method, a good strategy is to put
something in the session on login, and
check if it's there (userId for example fits perfectly), on logout simply
remove this attribute again.
I would also recommend to provide overwritteable init/deInit actions and
common error handling.
Implement your code in doExecute.
You may make execute final, but sometimes you will want to overwrite this as
well.
Regards
Leon
> -Ursprüngliche Nachricht-
> Von: David Johnson [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 7. März 2005 22:44
> An: Struts Users Mailing List
> Betreff: session.invaludate(); not working in LogoffAction
>
> hi all
>
> have a logoff action, and inside it I do the following.
>
> // Clean up the session if there is one
> HttpSession session = request.getSession(); session.invalidate();
>
> When I watch what's happening in the manager application (I'm using
> Tomcat) the number of sessions does not decrease, and I can
> back up in the browser and call actions, all of which have
> code to check for a valid session..
>
> This raises a question.. what's the best way in my web-app to
> make sure the user is valid? should I check in **every** action?
>
> --
> -Dave
> [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: session.invaludate(); not working in LogoffAction
Graig will blame for not using Filters (they would do the job too), but I'd
say "yes":
Create a "BaseAction", all your actions are extending from, with:
public ActionForward execute(
ActionMapping mapping,
ActionForm bean,
HttpServletRequest req,
HttpServletResponse res)
throws Exception {
if (isAuthorizationRequired()){
boolean authorized = checkAuthorization(req);
if (!authorized){
String redUrl =
req.getContextPath()+"your_login_action_path";
res.sendRedirect(redUrl);
return null;
}
}
ActionForward forward = doExecute(mapping, bean, req, res);
return forward;
}
protected abstract boolean isAuthorizationRequired();
public abstract ActionForward doExecute(
ActionMapping mapping,
ActionForm af,
HttpServletRequest req,
HttpServletResponse res)
throws Exception;
Now in actions you want to protect overwrite authorizationRequired returning
true.
And implement the checkAuthorization method, a good strategy is to put
something in the session on login, and
check if it's there (userId for example fits perfectly), on logout simply
remove this attribute again.
I would also recommend to provide overwritteable init/deInit actions and
common error handling.
Implement your code in doExecute.
You may make execute final, but sometimes you will want to overwrite this as
well.
Regards
Leon
> -Ursprüngliche Nachricht-
> Von: David Johnson [mailto:[EMAIL PROTECTED]
> Gesendet: Montag, 7. März 2005 22:44
> An: Struts Users Mailing List
> Betreff: session.invaludate(); not working in LogoffAction
>
> hi all
>
> have a logoff action, and inside it I do the following.
>
> // Clean up the session if there is one
> HttpSession session = request.getSession(); session.invalidate();
>
> When I watch what's happening in the manager application (I'm using
> Tomcat) the number of sessions does not decrease, and I can
> back up in the browser and call actions, all of which have
> code to check for a valid session..
>
> This raises a question.. what's the best way in my web-app to
> make sure the user is valid? should I check in **every** action?
>
> --
> -Dave
> [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: session.invaludate(); not working in LogoffAction
I think that you shouldn't just check for the existence of a Session, you should check for a "user" Session attribute that you have set in your own code. If you are invalidating the Session and this attribute still exists afterward, I'd suggest something has gone awry . . . And yes, I do it in every protected Action, but of course, via one line of code that invokes a base class. Erik David Johnson wrote: hi all have a logoff action, and inside it I do the following. // Clean up the session if there is one HttpSession session = request.getSession(); session.invalidate(); When I watch what's happening in the manager application (I'm using Tomcat) the number of sessions does not decrease, and I can back up in the browser and call actions, all of which have code to check for a valid session.. This raises a question.. what's the best way in my web-app to make sure the user is valid? should I check in **every** action? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
session.invaludate(); not working in LogoffAction
hi all have a logoff action, and inside it I do the following. // Clean up the session if there is one HttpSession session = request.getSession(); session.invalidate(); When I watch what's happening in the manager application (I'm using Tomcat) the number of sessions does not decrease, and I can back up in the browser and call actions, all of which have code to check for a valid session.. This raises a question.. what's the best way in my web-app to make sure the user is valid? should I check in **every** action? -- -Dave [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
