Open spring-projects-issues opened 5 years ago
Bartosz Kielczewski commented
The NPE happens in the code introduced by DATAREST-1294.
The NPE happens when preflight request has path = /{repository} and Access-Control-Request-Method: GET
This is because HandlerMethod of preflight request has no RequestMapping. It has none because org.springframework.web.servlet.handler.AbstractHandlerMethodMapping returns PREFLIGHT_AMBIGUOUS_MATCH = new HandlerMethod(new EmptyHandler(), ClassUtils.getMethod(EmptyHandler.class, "handle"));
Now the match is ambiguous, because there are two HandlerMethods matching the request: repositoryEntityController.getCollectionResource and repositoryEntityController.getCollectionResourceCompact and both are for GET /{repository} and differ only by produced mediaType.
Why GET /{repository} and not for OPTIONS /{repository}, repositoryEntityController.optionsForCollectionResource?
Ok, that's because RequestMethodsRequestCondition explicitly matches to would-be method based on Access-Control-Request-Method header, so GET is being matched. Moreover, both GET methods are matched, because for preflight requests only RequestMethodsRequestCondition is not empty so produces gets ignored.
BTW, it looks like RepositoryRestController.optionsForCollectionResource and RepositoryRestController.optionsForItemResource won't be matched, like never-ever, should probably be removed. Looks like you can't have @RequestMapping
for OPTIONS anymore.
So what seems problematic is:
@RequestMapping
, since it got matched. This could actually check if it really has.I would do a PR, but this seems potentially bigger
Bartosz Kielczewski commented
Yeah, seems bigger, can reproduce this on other paths, i.e. {repository}/search/{search}, so CORS preflight requests are broken, because multiple "would-be" methods are being mapped instead of OPTIONS.
At least there was no NPM before DATAREST-1294 was merged, so short-term fix would be to address it, possibly in RepositoryRestHandlerMapping.lookupHandlerMethod. Still the matching doesn't seem to be working as originally intended, so it can have other implications if you've relied on it somewhere.
As for me downgrading to 3.1.1 is acceptable work-around and thankfully I'm not using CORS on production
Bartosz Kielczewski opened DATAREST-1305 and commented
With CORS configuration:
And with some standard repositories, i.e.:
When CORS preflight request is done from the browser (or curl here):
The response is 500:
And in the stack trace there's NPE in RepositoryRestHandlerMapping.exposeEffectiveLookupPathKey:
Affects: 3.1.2 (Lovelace SR2)