In Struts1 I did have a Base Action that I extended from along with a
session scoped variable that kept track of whether the user is logged
in or not. This functionality is needed by multiple actions who ended
up extending the base class. Since Struts 2 has interceptors, I felt
that it would be a better design to create an interceptor that does
this and that way the Action does not have to extend a base class.
This way this interceptor can be stacked with other custom
interceptors as required as well. Thanks for pointing out the
addActionErrors and addFieldErrors methods.
Thanks.
On Jan 4, 2008, at 3:55 AM, Ted Husted wrote:
The best use of interceptors is for behavior that will be shared by
several Actions. If there are several different places where a client
might be authenticated, then, in that case, a login interceptor (and a
custom interceptor stack) can be a good idea.
When coding an Interceptor, you can just return the result code, same
as an action. Any string value can be returned, so long as the code
matches one of the local or global Results.
In this case, good choices might be "input" or "login". In the case of
"input", there should be a local Result by that name that returned the
client to the initial form. Just be sure to set the appropriate Action
or field errors first, so that the messages can be displayed by the
form.
To acquire the Action instance in an Interceptor, we can use this
idiom:
MyAction action = (MyAction)invocation.getAction();
Then we can access the Action properties and helper methods.
action.addActionError(actionErrorMessage);
action.AddFieldError(fieldName, errorMessage);
Another approach, as Al mentioned, would be to create an base Action
with an authenticate method. In either case, the code is essentially
the same, it's just a matter of where it is called.
I believe the most common approach would be to use an Action method to
login, store a session-scope profile object, and then secure (other)
Actions with an authentication interceptor. The authentication
interceptor would check the profile object in session scope, and
decide whether to let the request through.
For more finely grained security, many people like SecurityFilter (on
SourceForge) or Acegi (now Spring Security). There's a FAQ on Acegi in
the documentation, but I don't know if it's up to date.
* http://struts.apache.org/2.x/docs/can-we-use-acegi-security-with-
the-framework.html
HTH, Ted.
<http://www.StrutsMentor.com/>
On Jan 3, 2008 11:47 PM, Mufaddal Khumri
<[EMAIL PROTECTED]> wrote:
Am trying to understand the best practice if any for a
ValidateLoginInterceptor of sorts. In the code below, if the login is
valid then we make a call to:
return actionInvocation.invoke();
In case the login information was incorrect, what should one do?
return ActionSupport.ERROR // In this case would the <result
name="error">/myerrorpage.ftl</result> associated with my action be
executed?
public class ValidateLoginInterceptor implements Interceptor
{
private static final long serialVersionUID = 1L;
private static String EMAIL_FIELD = "email";
private static String PASSWORD_FIELD = "password";
public void destroy()
{
}
public void init()
{
}
public String intercept(ActionInvocation actionInvocation)
throws
Exception
{
String email = actionInvocation.getStack
().findString(EMAIL_FIELD);
String password = actionInvocation.getStack
().findString
(PASSWORD_FIELD);
if (isValidLogin(email, password))
{
// login credentials were valid
return actionInvocation.invoke();
}
else
{
// login credentials are not valid
// actionInvocation.setResultCode
(ActionSupport.ERROR);
Should I be doing this?
return ActionSupport.ERROR;
}
}
}
---------------------------------------------------------------------
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]
