struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Maurizio Cucchiara <>
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.



Twitter     :
G+          :
Linkedin    :

Maurizio Cucchiara

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message