You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Emi Lu <em...@encs.concordia.ca> on 2007/11/05 21:05:23 UTC
Login checking before processing any action/class
Hello ,
For struts1, we use "doFilter"
public void doFilter(
ServletRequest req,
ServletResponse res,
FilterChain chain)
throws IOException, ServletException
{
HttpServletRequest request = (HttpServletRequest) req;
HttpServletResponse response = (HttpServletResponse) res;
HttpSession session = request.getSession();
If not login successfully:
ActionConfig action = ...
this.sendRedirect(request, response, action.getPath());
else {
chain.doFilter(req,res);
}
}
in web.xml, all classes/actions need be filtered by this actionClass.
For struts2, do you have a good example for login checking? Moreover,
before each action/class is called, a login checking will be done
automatically. If user logins successfully, allow user action to be
processed; otherwise, return error msg to default login page.
Thank you!
-e
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Login checking before processing any action/class
Posted by Gary Affonso <gl...@greywether.com>.
Tom Schneider wrote:
> With Acegi, are you using an interceptor or is there a different way to
> enforce security?
Acegi sets up it's own Servlet Filter to monitor incoming url requests.
This filter is typically the first in the filter chain, Acegi gets a
shot at processing the url before anything else.
More specifically, Acegi typically sets up and entire chain of filters
that do various things for you (like automatically logging in
unauthenticated guests as "anonymous", etc.).
You typically configure the behavior of each component in that chain in
Springs application context.
So, no, you're Acegi is not using an interceptor. It's using a filter.
That let's Acegi do security checks/blocks *before* anything like
struts even has a chance to process something like a foo.action call.
> I wouldn't mind seeing an example of this if there's one
> that you can point to.
Just google for acegi and head to their site. Checkout the "getting
started" stuff.
> IMO, this would fit into Struts 2 authentication
> best practices and a little page describing the general setup wouldn't be a
> bad idea.
Agreed. My personal opinion is that *the* best practice for
authentication in java webapps at the moment is Acegi.
There are things Acegi doesn't cover with the default packages (NTLM
single-sign-on support comes to mind) but, man, if you've got anything
like "typical" java webapp auth needs, Acegi is great.
- Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Login checking before processing any action/class
Posted by Tom Schneider <sc...@gmail.com>.
With Acegi, are you using an interceptor or is there a different way to
enforce security? I wouldn't mind seeing an example of this if there's one
that you can point to. IMO, this would fit into Struts 2 authentication
best practices and a little page describing the general setup wouldn't be a
bad idea.
Thanks,
Tom
Gary Affonso wrote:
>
> Dave Newton wrote:
>> Interceptor or Acegi.
>
> +1 on Acegi.
>
> We've been doing auth "by hand" for years, I think we've used just about
> every technique over time (writing servlet filters, writing WebWork
> interceptors, doing checks in the Action's exec method, using
> container-security, etc).
>
> But having just climbed the Acegi learning curve (it wasn't as bad as I
> feared, particularly if you already know Spring) I can say that, for us,
> it's absolutely the best thing we could be doing. Should have done it
> years ago.
>
> - Gary
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Login-checking-before-processing-any-action-class-tf4754010.html#a13596932
Sent from the Struts - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Login checking before processing any action/class
Posted by Gary Affonso <gl...@greywether.com>.
Dave Newton wrote:
> Interceptor or Acegi.
+1 on Acegi.
We've been doing auth "by hand" for years, I think we've used just about
every technique over time (writing servlet filters, writing WebWork
interceptors, doing checks in the Action's exec method, using
container-security, etc).
But having just climbed the Acegi learning curve (it wasn't as bad as I
feared, particularly if you already know Spring) I can say that, for us,
it's absolutely the best thing we could be doing. Should have done it
years ago.
- Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Login checking before processing any action/class
Posted by Dave Newton <ne...@yahoo.com>.
Interceptor or Acegi.
d.
--- Emi Lu <em...@encs.concordia.ca> wrote:
> Hello ,
>
> For struts1, we use "doFilter"
>
> public void doFilter(
> ServletRequest req,
> ServletResponse res,
> FilterChain chain)
> throws IOException, ServletException
> {
>
> HttpServletRequest request =
> (HttpServletRequest) req;
> HttpServletResponse response =
> (HttpServletResponse) res;
> HttpSession session = request.getSession();
>
>
> If not login successfully:
>
> ActionConfig action = ...
> this.sendRedirect(request, response,
> action.getPath());
>
>
> else {
> chain.doFilter(req,res);
> }
>
> }
>
> in web.xml, all classes/actions need be filtered by
> this actionClass.
>
> For struts2, do you have a good example for login
> checking? Moreover,
> before each action/class is called, a login checking
> will be done
> automatically. If user logins successfully, allow
> user action to be
> processed; otherwise, return error msg to default
> login page.
>
> Thank you!
>
> -e
>
>
>
---------------------------------------------------------------------
> 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