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-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
