Hi,
currently I have a generic mixin called Protected that I can use for all
components to inject the CSRF token.
So the usage looks like:
<t:actionlink t:id="logout" t:mixins="Protected">Logout</t:actionlink>
or
<form t:type="form" t:id="statusForm" t:mixins="Protected">
In the mixin I have a if/elseif structure where I use the instanceof
operator to determine the exact component:
@InjectContainer
private ClientElement container;
...
if(container instanceof Form){
...
else if(container instanceof AbstractLink){
...
Q1: Is there a better way to do that? The usage of instanceof may have
negative impact on performance. I can use a separate Mixin for each
Component but I wouldn't see that as a nice solution.
If it is a Form component I just add an element:
Element formElement = writer.getElement();
formElement.element("input", "type", "hidden", "name", "formtoken", "value",
token);
for an AbstractLink I extract the href attribute and add the formtoken
parameter.
Q2: What name should be used for the CSRF protection parameter and where
should I put that constant? Is there some strategy to avoid naming
conflicts?
Q3: In Tapestry 4 the Form component provided a method addHiddenValue
(http://tapestry.apache.org/tapestry4/tapestry/apidocs/org/apache/tapestry/form/Form.html#addHiddenValue%28java.lang.String,%20java.lang.String%29).
In Tapestry 5 this method has gone. Is there still some programmatic way to
put a hidden field in a form component? My idea was to add this field before
the form is rendered, what would be the best way to avoid modification of
the rendered markup. Espacially for the AbstractLink component it would be
nice to have a addParameter method.
Thanks for your help!
Markus
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Generic-Protected-mixin-for-mulitple-components-tp4422923p4422923.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]
