feat: disable the hidden HTTP method filter by default

[codeconsole]

Summary

Grails currently rewrites hidden HTTP methods in a servlet filter that runs before the dispatcher and Spring Security. Reading _method there can force a multipart request body to be parsed—and temporary upload files written—before routing or authentication.

This PR disables the Grails hidden-method filter by default and resolves form method overrides inside the dispatcher instead. Existing browser forms continue to work without template changes.

What changes

• GrailsDispatcherServlet resolves _method after multipart handling and the filter chain.
• Overrides are limited to PUT, PATCH, and DELETE; X-HTTP-Method-Override is no longer used in the new default mode.
• UrlMappingsHandlerMapping applies the same resolution when matching routes.
• resources mappings add POST /$controller/$id -> update, matching the POST method already accepted by RestfulController.update.
• <g:form method="PUT"> and PATCH submit to that POST update route without _method.
• <g:form method="DELETE"> still emits _method, because update and delete share the same URL.
• Grails backs off when Spring Boot's hidden-method filter is enabled, avoiding the hiddenHttpMethodFilter bean-name collision introduced in Grails 8.

Compatibility and authorization

Servlet filters—including Spring Security—now see the real request method. For example, a browser delete form is seen by the filter chain as POST /books/1; it becomes DELETE only inside Grails dispatching.

Applications with method-specific security rules such as DELETE /books/** must review those rules before upgrading. Otherwise, the DELETE-specific rule will not match the form's POST request. This behavior and migration concern are documented in the Grails 8 upgrade guide.

The legacy filter behavior can be restored with:

grails:
    web:
        hiddenmethod:
            filter:
                enabled: true

When enabled, the dispatcher-level override and additional POST update mapping are disabled.

Why change the default?

The existing filter reads request parameters before authentication. For multipart/form-data, that can trigger early parsing of the entire upload. Spring Boot disabled its equivalent filter by default for the same early-consumption concern.

Grails 8 is the appropriate compatibility boundary for changing this default, while the configuration property provides an opt-out for applications that need time to migrate security rules.

[codecov]

Codecov Report

❌ Patch coverage is 84.48276% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 54.7310%. Comparing base (351652b) to head (90e0842).
⚠️ Report is 76 commits behind head on 8.0.x.

Files with missing lines	Patch %	Lines
...ils/web/servlet/mvc/GrailsDispatcherServlet.groovy	63.6364%	2 Missing and 2 partials ⚠️
...vy/org/grails/plugins/web/taglib/FormTagLib.groovy	33.3333%	0 Missing and 2 partials ⚠️
.../web/controllers/ControllersAutoConfiguration.java	66.6667%	0 Missing and 1 partial ⚠️
...plugins/web/mapping/UrlMappingsGrailsPlugin.groovy	50.0000%	0 Missing and 1 partial ⚠️
...s/web/mapping/mvc/UrlMappingsHandlerMapping.groovy	75.0000%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@                Coverage Diff                 @@
##                8.0.x     #16183        +/-   ##
==================================================
+ Coverage     54.1488%   54.7310%   +0.5822%     
- Complexity      20258      20452       +194     
==================================================
  Files            2098       2103         +5     
  Lines          100920     101025       +105     
  Branches        17898      17920        +22     
==================================================
+ Hits            54647      55292       +645     
+ Misses          38484      37864       -620     
- Partials         7789       7869        +80     

Files with missing lines	Coverage Δ
...GrailsHiddenHttpMethodFilterAutoConfiguration.java	100.0000% <100.0000%> (ø)
...core/src/main/groovy/grails/config/Settings.groovy	100.0000% <ø> (ø)
...ing/UrlMappingsBeanDefinitionsPostProcessor.groovy	88.0952% <100.0000%> (+1.6088%)	⬆️
...n/groovy/org/grails/web/util/HiddenHttpMethod.java	100.0000% <100.0000%> (ø)
...grails/web/mapping/DefaultUrlMappingEvaluator.java	78.6078% <100.0000%> (+0.2573%)	⬆️
.../web/controllers/ControllersAutoConfiguration.java	93.1034% <66.6667%> (-1.9785%)	⬇️
...plugins/web/mapping/UrlMappingsGrailsPlugin.groovy	42.8571% <50.0000%> (-1.2605%)	⬇️
...s/web/mapping/mvc/UrlMappingsHandlerMapping.groovy	58.9474% <75.0000%> (+1.3387%)	⬆️
...vy/org/grails/plugins/web/taglib/FormTagLib.groovy	76.3848% <33.3333%> (-0.0772%)	⬇️
...ils/web/servlet/mvc/GrailsDispatcherServlet.groovy	33.8710% <63.6364%> (+6.9479%)	⬆️

... and 54 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jdaugherty]

We removed the dispatch actions in Grails 8 already (deprecated in Grails 7). Is _method just left over from that? I had no idea you could even change the method for a form - why wouldn't you either set the form to the intended method or just set the formmethod? It seems like _method is from an earlier implementation when there weren't built in constructs to change the method in html5.

[codeconsole]

We removed the dispatch actions in Grails 8 already (deprecated in Grails 7). Is _method just left over from that? I had no idea you could even change the method for a form - why wouldn't you either set the form to the intended method or just set the formmethod? It seems like _method is from an earlier implementation when there weren't built in constructs to change the method in html5.

No, it is for RestfulServiceController and g:form and has always been there. It is used in the scaffolding plugin.

<g:form method="PUT" action="/books">

creates

<form method="POST" action="/books">
<input type="hidden" name="_method" value="PUT">

then HiddenMethodFilter wraps the entire request so the entire filter stack (including Spring Security thinks the request is PUT /books instead of POST /books (what it really is)

This PR keeps the actual request and uses _method just for DELETE and utilizes the existing mapping urls for the rest of the requests. Alternatively, you could add 1 more rule for every mapping, BUT that creates O(n) mappings so if you have a lot of rules, it just overcomplicates.

I a follow up PR would also be to not use _method and use actual javascript to send a DELETE but that also requires javascript working in the browser.

If you only use POST and GET in your forms, this PR will only help you not forcing multipart resolution at the beginning of the filter stack

[matrei]

The way I understand it, this is the current PR behavior:

// Pseudo-code
if (grailsFilterEnabled) {
    if (springFilterEnabled) {
        use Spring HiddenHttpMethodFilter
    }
    else {
        use Grails HiddenHttpMethodFilter
    }

    disable Grails dispatcher-level override
}
else {
    if (springFilterEnabled) {
        use Spring HiddenHttpMethodFilter
        ALSO enable Grails dispatcher-level override
    }
    else {
        no servlet HiddenHttpMethodFilter
        enable Grails dispatcher-level override
    }
}

Wouldn't this be more appropriate?

// Pseudo-code
if (springFilterEnabled) {
    use Spring HiddenHttpMethodFilter
    Grails compatibility/filter mode = true
}
else if (grailsFilterEnabled) {
    use Grails HiddenHttpMethodFilter
    Grails compatibility/filter mode = true
}
else {
    no servlet HiddenHttpMethodFilter
    use Grails dispatcher-level override
}

[codeconsole]

Accurate description of the behaviour, and fixed in 482fa1c — your structure, with one addition.

The mode now comes from HiddenHttpMethod.isServletFilterMode (either property), used by the dispatcher, handler mapping, URL mapping evaluator and g:form alike so they cannot drift.

That is only sound if a filter really exists whenever either property is set, and it did not: Boot's filter comes from WebMvcAutoConfiguration, which backs off entirely under @EnableWebMvc. Asking for Boot's filter there produced no filter, while the Grails one had already backed off on the property. So the registration moved to its own auto-config ordered after Boot's, gating on @ConditionalOnMissingBean — detecting Boot's filter instead of assuming it — and contributing the Grails filter when Boot has not. Same pattern GrailsFormContentFilterAutoConfiguration already uses.

Worth noting the case you found was worse than redundant: with spring=true, g:form stopped emitting _method for PUT and the POST member route appeared, so form updates hit the security chain as a POST — the exact silent authorization change the upgrade note warns about, landing on whoever opted in to avoid it.

Covered by GrailsHiddenHttpMethodFilterAutoConfigurationSpec, including the @EnableWebMvc case.

[codeconsole]

Consolidated into #16149, which now covers the request path as one reviewable change — per-request work, hidden HTTP method handling and multipart together.

This branch was merged in with its history intact; no commits were squashed or dropped, and git merge-base --is-ancestor confirms every commit here is contained in #16149.

Closing in favour of that. The reason is review flow rather than anything wrong here: these branches collided in GrailsDispatcherServlet.checkMultipart and UrlMappingsHandlerMapping, so reviewing them separately meant tracking a merge order, which is not a reasonable thing to ask of a reviewer.