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){
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
