Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Add form support for Spring's RequestDataValueProcessor #7

pfeigl opened this Issue · 21 comments

This is a copy paste from the following forum discussion.
The link also contains some reference code on how the result can be achieved.

Since Spring 3.1 there is a new interface called RequestDataValueProcessor.
You can find the docs here:

The interface supports one method called getExtraHiddenFields, which adds functionality to dynamically add hidden fields into the form without changing the actual form code.

For JSP this is happening automatically, as soon as a form is annotated as form:form. One classic usecase for all of this is automatic CSRF protection of forms. You can find a very nice example with an implementation of this here:

Unfortunately, it seems that thymeleaf forms which are bound using th:object do not support this functionality.

It would be a very great addition, if this could be added to one of the future versions of thymeleaf.


+1 on this issue




supporting RequestDataValueProcessor would be realy great news. We are using HDIV framework ( in our projects to add some advanced security features and it really seamlessly integrates with spring mvc + jsp + spring forms lib. I believe this easy integration is the purpose of RequestDataValueProcessor (as you can see here I spend some time trying to do this be myself, but I was not able to find an easy way to make HDIV work together with thymeleaf... It would be really great if thymeleaf would use this existing interface and allow integration with HDIV too.


+1, want it to be done.


This will be a part of 2.1, as it requires to compile thymeleaf-spring3 against Spring 3.1 instead of 3.0. The solution will consist of the implementation of a semi-mirror interface called IDataValueProcessor in thymeleaf, which once the framework is initialized will decide whether to use an "enabled" implementation (which will use Spring's RequestDataValueProcessor mechanism underneath) or a "disabled" implementation (which will do nothing and avoid Spring 3.1 classes to be loaded in a 3.0-based application).

This IDataValueProcessor interface will look like this:

public interface IDataValueProcessor  {

    public Map<String, String> getExtraHiddenFields(final RequestContext requestContext, final HttpServletRequest request);

    public String processAction(final RequestContext requestContext, final HttpServletRequest request, final String action);

    public String processFormFieldValue(final RequestContext requestContext, final HttpServletRequest request, final String name, final String value, final String type);

    public String processUrl(final RequestContext requestContext, final HttpServletRequest request, final String url);


And will be applied at a series of processors and other artifacts:

  • th:object on <form> tags: processAction(...) for the action attribute and getExtraHiddenFields(...) for adding <input type="hidden" /> fields just after the <form> tag.
  • A future th:form if it exists (value = form's id attribute), same as th:object above.
  • th:value and th:field on <input>, <select> and <textarea> tags: processFormFieldValue(...) on the value of the value attribute being written.
  • URLs: th:href or LinkExpression? at first thought, LinkExpression looks like a better option, because that way every URL created by the application will be covered, even if created inside a javascript fragment with inlining.

+1, to integrate Thymeleaf with HDIV

@gillarramendi gillarramendi referenced this issue in hdiv/hdiv

HDIV is supported in HTML #34


Moved to thymeleaf 3.0, due to the requirement of compiling against Spring 3.1.







It would be nice if we could resolve this by having an optional dependency on Spring 3.1+ since Spring Security 3.2 will utilize this mechanism for its CSRF support as well. Without this support it means any Thymeleaf Spring Security user will be required to manually add the CSRF token. For this reason, I am quite willing to send a PR for this feature.

A few possibilities to get this in sooner and still build against 3.1...

We could create a separate jar for Spring 3.2 support.

We can create another module for Spring 3.2 support. We would then use the Maven shade plugin to merge the dependencies into the thyemeaf-spring3 jar. I haven't investigated how to do this with Maven very thoroughly yet, but we do something like this with Gradle within the Spring Framework itself to deal with working with multiple versions of the same library.

Please let me know your thoughts.

PS: One other thing to note is that Spring 3.2 should be rather backward compatible to Spring 3.0 since it is a minor revision change. Perhaps building against Spring 3.2 would be preferred (especially with Spring 4 nearly out)


I'd probably suggest the pull request route for now as I know Daniel's a bit swamped with the 2.1 release of all the Thymeleaf modules for this weekend.


@ultraq Thanks for the response. However, before taking the time to put a PR together I want to ensure that @danielfernandez (or some other authoritative person) will consider merging a PR into 2.1 (or at least prior to 3.0) since he stated

Moved to thymeleaf 3.0, due to the requirement of compiling against Spring 3.1.

I can have something ready quite promptly as soon as I get a response, but I don't want to spend the time on it now if it won't even be considered till 3.0.


@rwinch Thanks a lot for your offer, Rob, I really appreciate it.

However, after giving it some more thought, I found there might be a way to apply this in a quite transparent manner already for 2.1. So let me first have a go at it and see if I can come up with a solution fast. As Emanuel said, I'm quite busy with the latest 2.1 changes, so "fast" is important today :-)

I'll keep you posted.


@danielfernandez Thanks for the response. If there is anything I can do to help this go smoothly please let me know. One thing that you will probably find relevant is that in Spring 4, Spring MVC changed the interface in a non-passive manner. See this commit for details.

Also note that with the 4.x API the method processAction method must be called prior to getExtraHiddenFields with no other form's processAction method invoked between. This is important so that the getExtraHiddenFields knows if it is a POST or not. This ensures that the CSRF token is only included on HTTP POST and not GET (so it doesn't get leaked).

This means if we want it to support both 3.x code and 4.x code you may need do a little bit of work.


PS: Please let me know if I can be of any help.

@danielfernandez danielfernandez referenced this issue from a commit
@danielfernandez danielfernandez Implemented first phase of #7. Linked all necessary attribute process…
…ors to RequestDataValueProcessorUtils class

This has been implemented for Thymeleaf 2.1.

The IDataValueProcessor idea above was finally discarded. The real implementation direcly relies on the Spring-enabled attribute processors for URLs and forms:

  • th:href and th:src simply call RequestDataValueProcessor.processUrl(...) before rendering the URL. Note this is not applied at the LinkExpression level, i.e., not for every @{...} but just at these specific attributes. Besides, this means that Spring's interface is applied after HttpServletResponse.encodeURL(...) (which is what Spring does in its JSP taglibs).

  • th:action calls RequestDataValueProcessor.processAction(...) before rendering the form's action attribute, but additionally it detects when this attribute is being applied on a <form> tag --which should be the only place, anyway--, and in such case calls RequestDataValueProcessor.getExtraHiddenFields(...) and adds the returned hidden fields just before the closing </form> tag. Note the values in these hidden fields are not applied RequestDataValueProcessor.processFormFieldValue(...), mirroring Spring's JSP taglib behaviour.

  • th:value calls RequestDataValueProcessor.processFormFieldValue(...) for rendering the value it refers to, unless there is a th:field present in the same tag (in which case th:field will take care).

  • th:method calls RequestDataValueProcessor.processFormFieldValue(...) whenever it has to render an additional <input type="hidden" ... /> for setting a non-browser compatible form method (i.e. other than get or post).

  • th:field calls RequestDataValueProcessor.processFormFieldValue(...) for rendering the value of the field it applies to (or the tag body if it is a <textarea>). Additional <input type="hidden" value="on" /> fields created for checkboxes in order to differentiate disabled and unchecked checkboxes are also applied this processing method, mirroring Spring JSP taglib behaviour.

Important: All these calls are applied conditionally, only if Spring version is 3.1 or newer. Compatibility of the thymeleaf-spring3 module is kept at Spring version 3.0.

Finally, in order to prepare for future Spring 4.0 support, the Thymeleaf infrastructure for calling the RequestDataValueProcessor.processAction(...) method already supports sending an httpMethod argument, which will be required in 4.0. See spring-projects/spring-framework@4b22558


Updated 2.1.0-SNAPSHOT


HDIV security framework has been integrated with Thymeleaf thanks to RequestDataValueProcessor interface support: hdiv/hdiv@eea00c4
More info: hdiv/hdiv#34


Mila esker! That's really great news :-)

Please don't hesitate contacting me ( ) when you release your new version, so that we can give it proper publicity.


Ok, Moitas grazas :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.