As for now I will rollback my changes regarding this, maybe I will
come back to the idea in 2.3.17
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
2013/10/18 Lukasz Lenart :
> 2013/10/17 Paul Benedict :
>> Throw an exception instead. If Struts has a default exception handler,
>> tr
2013/10/17 Paul Benedict :
> Throw an exception instead. If Struts has a default exception handler,
> translate the exception into a 403; but the goal is to give the user a
> chance to customize the response.
That's the problem exceptions handling is provided by an
interceptor, deep in execut
Throw an exception instead. If Struts has a default exception handler,
translate the exception into a 403; but the goal is to give the user a
chance to customize the response.
On Thu, Oct 17, 2013 at 6:46 AM, Lukasz Lenart wrote:
> 2013/10/10 Lukasz Lenart :
> > 2013/10/10 Steven Benitez :
> >>
2013/10/10 Lukasz Lenart :
> 2013/10/10 Steven Benitez :
>> Yeah, I'm not a fan of the Judge name either. Guard is better, but I'm not
>> sure if it's best. What would the API look like?
>
> Not sure yet, something like this:
>
> public class SecurityGate {
>
> private List guards;
>
> publ
Sounds like what Spring Security has:
http://docs.spring.io/spring-security/site/docs/2.0.x/apidocs/org/springframework/security/vote/AuthenticatedVoter.html
Each request goes through a list of voters.
Paul
On Thu, Oct 10, 2013 at 2:50 AM, Lukasz Lenart wrote:
> 2013/10/10 Steven Benitez :
> >
2013/10/10 Steven Benitez :
> Yeah, I'm not a fan of the Judge name either. Guard is better, but I'm not
> sure if it's best. What would the API look like?
Not sure yet, something like this:
public class SecurityGate {
private List guards;
public void check(HttpServletRequest) {
Yeah, I'm not a fan of the Judge name either. Guard is better, but I'm not
sure if it's best. What would the API look like?
On Thursday, October 10, 2013, Lukasz Lenart wrote:
> 2013/10/10 Lukasz Lenart >:
> > 2013/10/10 Paul Benedict >:
> >> I like the idea except the Judge name. I think Authent
2013/10/10 Lukasz Lenart :
> 2013/10/10 Paul Benedict :
>> I like the idea except the Judge name. I think Authenticator is fine.
>
> Hm... basically what the interfaces do is to judge if e.g. action name
> is proper, parameter name matches given pattern, etc. It's some kind
> of authentication of r
2013/10/10 Paul Benedict :
> I like the idea except the Judge name. I think Authenticator is fine.
Hm... basically what the interfaces do is to judge if e.g. action name
is proper, parameter name matches given pattern, etc. It's some kind
of authentication of request but rather in validation terms
2013/10/9 Steven Benitez :
> Can you clarify how this would affect custom action mappers?
The whole stack will be executed before action mappers, I think in
prepare operations. Thus still needs some clarification, but I want to
make a security guard of the framework :-)
Regards
--
Łukasz
+ 48 6
I like the idea except the Judge name. I think Authenticator is fine.
On Wed, Oct 9, 2013 at 3:21 PM, Steven Benitez wrote:
> Can you clarify how this would affect custom action mappers?
>
>
> On Wed, Oct 9, 2013 at 4:05 PM, Lukasz Lenart >wrote:
>
> > Hi,
> >
> > Another idea is to add some lo
Can you clarify how this would affect custom action mappers?
On Wed, Oct 9, 2013 at 4:05 PM, Lukasz Lenart wrote:
> Hi,
>
> Another idea is to add some logic to handle security aspects of the
> framework in one place - it would be some kind of stack of interfaces
> which will try to cleanup inco
Hi,
Another idea is to add some logic to handle security aspects of the
framework in one place - it would be some kind of stack of interfaces
which will try to cleanup incoming request.
For example:
- ActionNameJudge#accept() will handle if action name match expected
pattern, the same what is al
13 matches
Mail list logo
