The GitHub Actions job "Groovy Snapshot Canary Build" on grails-core.git/perf/request-path-8.0.x has failed. Run started by GitHub user codeconsole (triggered by codeconsole).
Head commit for run: a39a350296b9337f14f06b53c6301ca613cc9069 / Scott Murphy Heiberg <[email protected]> fix: authorize the method the request will be routed as The security chain resolves a URL to a controller and action of its own accord, to find the rules that apply, and it matched on the method the request arrived as. The dispatcher resolves the override afterwards. So a form POST to a member URL carrying _method=DELETE was resolved by AnnotationFilterInvocationDefinition to the update mapping - reachable at all only because this branch generates a POST route for that URL - authorized against update's rules, and then executed by the dispatcher as delete. An application whose delete is more restricted than its update had that difference bypassed. Matching now resolves the override first, so the action security authorizes is the action that runs. Adding _method can only select the stricter rule, never a weaker one, because both sides read the same resolution. Under the servlet filter the request already reports the overridden method and this resolves to it. Three more from the same review: The handler mapping's fallback derived an override to route on but never published it, so an action reached that way was refused by allowedMethods with a 405 for the method it arrived as. It publishes what it resolves. Every action writes the ALLOWED_METHODS_HANDLED attribute again. Skipping it for a controller that restricts nothing looked safe from inside that controller: the action which reads it is in whichever controller is entered second, so a forward from an unrestricted controller into a restricted action began checking the original request method against allowedMethods and could answer 405 mid-request. setMultipartRequest is back as a deprecated shim. It was removed outright while getCurrentRequest beside it was deprecated, which is a breaking change with no release deprecating it first. It publishes its argument as the multipart request attribute and discards the cached params, so an existing caller keeps working. A tolerated parameter read still returns the fallback for anything a multipart request throws, since the container failures this exists for are not all MultipartException. But only a MultipartException is expected, so anything else is logged at warn instead of debug rather than passing silently. The upgrade notes gain the two silent cases review asked be made prominent: a client that sends X-HTTP-Method-Override now has its POST answered by update with a 200, and an application registering its own filter bean without setting the property gets dispatcher mode as well as its filter. Report URL: https://github.com/apache/grails-core/actions/runs/33682889824 With regards, GitHub Actions via GitBox
