You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Mufaddal Khumri <mk...@allegrocentral.com> on 2008/01/04 05:47:38 UTC
Interceptor best practices ...
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
[S2] datetimepicker - type = time - time selection
Posted by Srikanth Muthyala <sr...@iitc.com.au>.
Hello,
I am able to use datetimepicker for time field. But the selection is the problem. If I want to select 10:45 PM - I have to click the picker icon three times to select 10 then 45 then PM. Does anybody know how to make this user friendly - I mean the selection popup screen does not disappear after first selection and force to select hours and minutes.
The code, if needed.
< s:datetimepicker type = "time" name = "time" label = "Time" toggleType = "fade" toggleDuration = "300" > </ s:datetimepicker > s:datetimepicker type = "time" name = "time" label = "Time" toggleType = "fade" toggleDuration = "300" > </ s:datetimepicker > Any help will be appreciated. I guess this could be a common problem. Any work arounds???????
Regards,
Srikanth
Re: Interceptor best practices ...
Posted by Dave Newton <ne...@yahoo.com>.
--- Mufaddal Khumri <mk...@allegrocentral.com> wrote:
> 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.
The point is, more or less, what Ted and Al said: having the interceptor
check that the user *was* logged in correctly is fine, and is a valid
use--checking for a logged-in user is a cross-cutting concern. Logging in
itself *isn't*, so belongs in an action.
d.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Interceptor best practices ...
Posted by Mufaddal Khumri <mk...@allegrocentral.com>.
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
> <mk...@allegrocentral.com> 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: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Interceptor best practices ...
Posted by Ted Husted <hu...@apache.org>.
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 <mk...@allegrocentral.com> 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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
RE: Interceptor best practices ...
Posted by Al Sutton <al...@alsutton.com>.
imho, you shouldn't be validating the users username and password in an
interceptor. You should validate them in an action, then set a token in the
session indicating the user had been validated, then check for your chosen
token in the interceptor.
That way you don't need to keep hitting your username and password store
every time a request comes in.
-----Original Message-----
From: Mufaddal Khumri [mailto:mkhumri@allegrocentral.com]
Sent: 04 January 2008 04:48
To: Struts Users Mailing List
Subject: Interceptor best practices ...
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org