struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurizio Cucchiara <mcucchi...@apache.org>
Subject Re: Cookie Interceptor
Date Thu, 04 Apr 2013 16:03:32 GMT
Hi Christian,
unfortunately, as you already noticed, Cookie dealing is the weak link
of Struts.


> the CookieInterceptor currently looks for all available cookies. Lets say there
> are cookies x, y, z. Now it would call setX, setY, setZ on the action.


I'm not able to understand what's the problem here: if you have
included x, y and z in your interceptor definition as cookieNames
parameter, struts will try to inject the value to your action.

>
> In addition it creates a cookie-map which is then injected to the action.


This is an optional and additional behavior, you have to implement
CookieAware interface.

>
> The cookie interceptor does not make sense at a general level so far.
> You need to have x, y, z in your actions, and so all your actions would
> need to provide these setters.

IMHO, this is the struts way, and it's similar to what usually happens
for http request parameters.

> Also "*" is risky: if you set a cookie for use in
> Action A it might fail if you have not an appropriate cookie-based Action B.

I agree with you for "*": it is a security hole (even if we can find
some small improvements): a malicious user could manipulate the stack
and your action trying to break your code.
I'm not sure IUC, but as illustrated here [1],  and according to the
best practices, you should define a cookie interceptor per action and
not per package.

> Actually I have tried to implement CookieAware and expected it would
> populate a map only from which I can take care of the cookies myself.
> This doesn't work, because an error is thrown when the get/set methods
> are missing.

I'm assuming you are running Struts on DevMode, did you try to switch
DevMode off?

> To overcome this I created a CookieMapInterceptor which does not populate
> the action but only a Map. For that I have overridden the
> CookieInterceptor. It was a bit of pain because a few necessary
> members are private and not protected.
>
> That said, I would like to implement one of the following solutions:
>
> Option 1) override CookieInterceptor with CookieMapInterceptor and
> make ACCEPTED_PATTERN, acceptedPattern, cookiesNameSet protected

We could try to reuse what defined for ParametersInterceptor [2]

> Option 2) add another option to the CookieInterceptor, which is called
> "skipActionPopulation" (defaults to false). If true, only the map
> would be created without putting the Cookies on the Action

Again, did you verified how it works w/o devMode enabled?

> In any way I would love to make ACCEPTED_PATTERN, acceptedPattern,
> cookiesNameSet protected.
>
> Any preferences/objections?
No objections from my side, but I would also like we reuse as much
code as possible.

WDYT?


[1] https://cwiki.apache.org/confluence/display/WW/Cookie+Interceptor
[2] https://svn.apache.org/repos/asf/struts/struts2/trunk/xwork-core/src/main/java/com/opensymphony/xwork2/interceptor/ParametersInterceptor.java

Twitter     :http://www.twitter.com/m_cucchiara
G+          :https://plus.google.com/107903711540963855921
Linkedin    :http://www.linkedin.com/in/mauriziocucchiara
VisualizeMe: http://vizualize.me/maurizio.cucchiara?r=maurizio.cucchiara

Maurizio Cucchiara

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message