You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looks to me like spring-webmvc recently refactored their cors code and broke the cors functionality in spring-data-rest.
In this commit the getHandler method was refactored to call a new method hasCorsConfigurationSource(handler) instead of CorsUtils.isCorsRequest(request).
hasCorsConfigurationSource(handler) only checks whether the handler is a CorsConfigurationSource or whether the handler mapping has a global cors configuration source set.
Since this is a new method there is no overridden implementation in RepositoryRestHandlerMapping.
As a result repository cors configurations are ignored unless there is a global cors configuration set.
I have committed a spring boot app into my github repo that demonstrates the issue.
Had a quick look at the code. If I were to submit a PR then I would probably modify the signature of hasCorsConfigurationSource(handler) to hasCorsConfigurationSource(handler, request). Before the refactor, handler mappings used the request to make cores decisions so maybe it is reasonable to reinstate this capability by having this method (in RepositoryRestHandlerMapping) return getCorsConfiguration(handler, request). But this fix span at least two repos (teams?) and also seems quite surgical. I may not (probably not) seeing the bigger picture somewhere along the line.
However, if that does seem appropriate and you want someone to do the grunt work then let me know and I will be happy to PR that
The changes in AbstractHandlerMethodMapping indeed break Spring Data REST's CORS discovery on repository interfaces. @RepositoryRestController's are not affected. As you noted, we cannot determine a repository-bound CORS config solely based on the handler but we require path/request details
Paul Warren opened DATAREST-1397 and commented
Looks to me like spring-webmvc recently refactored their cors code and broke the cors functionality in spring-data-rest.
In this commit the
getHandler
method was refactored to call a new methodhasCorsConfigurationSource(handler)
instead ofCorsUtils.isCorsRequest(request)
.hasCorsConfigurationSource(handler)
only checks whether the handler is aCorsConfigurationSource
or whether the handler mapping has a global cors configuration source set.Since this is a new method there is no overridden implementation in
RepositoryRestHandlerMapping
.As a result repository cors configurations are ignored unless there is a global cors configuration set.
I have committed a spring boot app into my github repo that demonstrates the issue.
Had a quick look at the code. If I were to submit a PR then I would probably modify the signature of
hasCorsConfigurationSource(handler)
tohasCorsConfigurationSource(handler, request)
. Before the refactor, handler mappings used the request to make cores decisions so maybe it is reasonable to reinstate this capability by having this method (inRepositoryRestHandlerMapping
)return getCorsConfiguration(handler, request)
. But this fix span at least two repos (teams?) and also seems quite surgical. I may not (probably not) seeing the bigger picture somewhere along the line.However, if that does seem appropriate and you want someone to do the grunt work then let me know and I will be happy to PR that
Affects: 3.2 RC2 (Moore)
Reference URL: https://github.com/paulcwarren/DATAREST-1397
Referenced from: pull request #357
Backported to: 3.1.10 (Lovelace SR10)
The text was updated successfully, but these errors were encountered: