codeconsole opened a new pull request, #16760: URL: https://github.com/apache/grails-core/pull/16760
Fixes #15921 on 9.0.x. #16759 fixes it on 7.0.x by moving Grails' encoding filter to `Ordered.HIGHEST_PRECEDENCE`. For 9.0 this PR removes Grails' filter and lets Spring Boot's do the job. Once any filter reads a request parameter, the servlet container decodes the request body, and it uses ISO-8859-1 unless a character encoding has been set by then. Grails registers its encoding filter at order -180, so a filter ordered ahead of it that reads a parameter, such as the CAS plugin's single sign-out filter (it reads `logoutRequest` from every POST), garbles every non-ASCII form field: a controller receives `Café – ðŸ‚` for `Café – 🍂`. Spring Boot already avoids this. It registers its encoding filter at `Ordered.HIGHEST_PRECEDENCE`, but in a Grails app its filter backs off, because Grails' `characterEncodingFilter` bean is a `CharacterEncodingFilter` too. That also means `spring.servlet.encoding` has no effect in a Grails app. Grails' filter does nothing Boot's doesn't: same class, and an encoding and a force flag that `spring.servlet.encoding.charset` and `.force` already cover. So: - `ControllersAutoConfiguration` no longer declares an encoding filter. Spring Boot's `HttpEncodingAutoConfiguration` registers one, configured by `spring.servlet.encoding`. - `grails.filter.encoding` and `grails.filter.forceEncoding` are deprecated. A new `GrailsCharacterEncodingEnvironmentPostProcessor` turns them into `spring.servlet.encoding.charset` / `.force` as default properties, so a `spring.servlet.encoding` setting the app makes itself wins. It also logs a deprecation warning through Boot's deferred log. The configuration metadata marks both keys deprecated, with their replacements. - `Settings.FILTER_ENCODING`, `Settings.FILTER_FORCE_ENCODING` and `GrailsFilters.CHARACTER_ENCODING_FILTER` are deprecated for removal. - The CAS plugin registers its single sign-out filter at `Ordered.HIGHEST_PRECEDENCE + 1`. A `FilterRegistrationBean` at the same order as Boot's filter would still run first; #16759 checks this on 7.0.x. **Behavior change:** Spring Boot forces the request encoding by default (`force-request` is true when nothing is set). Grails' `forceEncoding` defaulted to false, so a request that declares its own charset is now decoded as UTF-8 too. `spring.servlet.encoding.force-request: false` restores the Grails 8 behavior. The upgrade guide says so. #### Tests - `ControllersAutoConfigurationSpec`: with `ControllersAutoConfiguration` and `HttpEncodingAutoConfiguration`, there is exactly one `CharacterEncodingFilter`. It takes `spring.servlet.encoding.charset` and comes first in the filter chain. - `GrailsCharacterEncodingEnvironmentPostProcessorSpec`: translates both keys, the app's own `spring.servlet.encoding` wins, and nothing is added when neither key is set. - app1: `CharacterEncodingSpec` posts a form, with no charset, through a filter at `HIGHEST_PRECEDENCE + 1` that reads one of its parameters, and checks that the filter and the controller both get the text as typed. This is the same reproducer as in #16759. - CAS example: `CasSingleSignOutEncodingSpec` posts `Café – 🍂` to an echo action with single sign-out enabled, against the CAS container. Without the change, the app1 spec fails (`Café – ðŸ‚`); with it, it passes. These also pass: the `grails-controllers` tests (231), and `clean aggregateViolations` (Checkstyle, CodeNarc, PMD and repository conventions, all clean). I haven't run the CAS spec locally yet, because my Docker runtime is down. CI's CAS lane runs it, and on 7.0.x the same spec fails without the fix and passes with it. #### Docs - The filter-ordering note in the plugin guide now says Spring Boot's encoding filter runs first. Its example moved to `HIGHEST_PRECEDENCE + 1`. - The upgrade guide has a new section, "20. Spring Boot Registers the Character Encoding Filter". -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
