I would appreciate the way like Lenny described it. The advantage is that it opens the possibility of a generic solution.
Let's say that I have the mixin Protected and in the afterRender Phase it calls the insertCSRFToken() method of the container. I can use class transformation to modify all class components that are placed in the components package (or sub-packages) of the tapestry project and check if the insertCSRFToken() is provided. If it is not provided I can inject a component specific insertCSRFToken() method for the core components or a generic method for user created components that uses XPath to get all <form> and elements of the container and inserts the token (if it is not already there). Advantage: -) Protected mixin works out of the box for every tapestry and user created component -) CSRF protection logic is injected If the generic insertCSRFToken() does not work for a user specific component the following options exist: -) provide the insertCSRFToken() method for the user component -) disable CSRF protection by configuration -) disable auto insertCSRFToken injection by configuration Issues with that approach: -) I have to transform all component classes to implement an interface named for example TokenContainer that defines the insertCSRFToken() method. In the mixin I check the container element to be a TokenContainer and then call the insertCSRFToken(). Otherwise I would need to use reflection to manually call isnertCSRFToken() since the method is not available at compile time. Thanks for the input, this is a great help. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Generic-Protected-mixin-for-mulitple-components-tp4422923p4425831.html Sent from the Tapestry - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
