Conversation
When accessing /api/... endpoints the CorsFilter was not always hit and so these endpoints could not be used from webapps even if CORS was properly configured. The problem seemed to be with ApiRouter's forwarding mechanism from /api/... to /api/v1/... Adding FORWARD dispatcher types to @webfilter solves this. Fix is based on this zulip thread: https://dataverse.zulipchat.com/#narrow/channel/379673-dev/topic/CorsFilter.20Servlet.20Filter.20not.20discovered/near/572358009
| } | ||
|
|
||
| @ParameterizedTest(name = "CORS preflight headers on {0}") | ||
| @MethodSource("preflightEndpoints") |
There was a problem hiding this comment.
It seems a bit extra to use a MethodSource here. A ValueSource with the strings should be fine.
There was a problem hiding this comment.
I took it from another random ...IT.java but I see @MethodSource and @valuesource are used quite randomly, but I updated to @valuesource.
| .header("User-Agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/144.0.0.0 Safari/537.36") | ||
| .options(path); | ||
|
|
||
| int statusCode = response.getStatusCode(); |
There was a problem hiding this comment.
While this is technically OK, I'd rather see adoption of the assertions built into RestAssured. That way we can leverage its logging functionality as well.
| */ | ||
|
|
||
| @WebFilter("/*") | ||
| @WebFilter(value = "/*", dispatcherTypes = { DispatcherType.REQUEST, DispatcherType.FORWARD}) |
There was a problem hiding this comment.
We should add dispatch types "ERROR" and "ASYNC" here, too. Error to make really sure the error pages are handled correctly with CORS, Async for future extensions to the JAX-RS API to return Futures.
"INCLUDE" is probably not necessary here, as it would be used internally anyway. No way an outside request would have an INCLUDE dispatch type.
There was a problem hiding this comment.
I also strongly suggest to add detailed explanation to the Javadoc comment, linking to ApiRouter etc. Otherwise this context may be forgotten again.
There was a problem hiding this comment.
Added those and updated javadoc.
| @@ -9,6 +9,7 @@ | |||
|
|
|||
| import edu.harvard.iq.dataverse.settings.JvmSettings; | |||
There was a problem hiding this comment.
I'm just going to put this comment at the top but can you please add a release not snippet that describes the bug being fixed? Thanks! I think you know the drill, but just in case: https://guides.dataverse.org/en/6.9/developers/version-control.html#writing-a-release-note-snippet
ErykKul
left a comment
There was a problem hiding this comment.
Looks good to me. Thanks! Just a release note and it's ready.
|
@ErykKul Should I just add |
|
@beepsoft Please feel free to create an issue and link this PR to it. Can be brief. Also, I see Jenkins is not happy with one IT: Can you please look into that? Thx! Also, CorsIT must be added to https://github.com/IQSS/dataverse/blob/develop/tests/integration-tests.txt |
|
Do we need an issue at this point? I only raised the issue question because the release note authoring README.md mentioned, but I don't know if and how that applies here. Regarding SwordIT: I could not reproduce it locally. I added CorsIT to integration-tests.txt. |
Co-authored-by: Oliver Bertuch <poikilotherm@users.noreply.github.com>
|
I see in https://jenkins.dataverse.org/blue/organizations/jenkins/IQSS-Dataverse-Develop-PR/detail/PR-12151/7/tests that the tests now run, but CorsIT fails - the headers are all not present. I have a hunch that we might need @donsizemore to enable CORS during testing. Unfortunately, we currently have no way to change JVM options at runtime (there may exist an issue about this already). @pdurbin WDYT should we disable these tests until we figure out the remote JVM option part? Can we just enable CORS in Jenkins without affecting other tests? |
|
FWIW: I've recently started making non-IT tests with direct (mocked) calls to API methods to be able to test non-default JVM options, e.g. in LDNInboxTest.java and LocalContextsTest.java. Is that a useful approach here? |
What this PR does / why we need it:
Fixes
CorsFilterinvocation inconsistency.When accessing /api/... endpoints the
CorsFilterwas not always hit and so these endpoints could not be used from webapps even if CORS was properly configured.The problem seemed to be with
ApiRouter's forwarding mechanism from /api/... to /api/v1/...Adding FORWARD dispatcher types to
@WebFiltersolves this.Fix is based on this zulip thread:
https://dataverse.zulipchat.com/#narrow/channel/379673-dev/topic/CorsFilter.20Servlet.20Filter.20not.20discovered/near/572358009
Suggestions on how to test this:
CorsIT.javais added to test whether CORS headers are present for both /api/... and /api/v1/... invocations. For it to pass CORS must be enabled in Dataverse, eg. by settingDATAVERSE_CORS_ORIGIN: "*"env for
dev_dataverseindocker-compose-dev.yml