-
Notifications
You must be signed in to change notification settings - Fork 382
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix the cors issues #1396
Fix the cors issues #1396
Conversation
d39a269
to
4d3917e
Compare
it was previously not possible to read in list of strings from the config file. This can now be done in a generic way.
4d3917e
to
c054aac
Compare
@TheGreatRefrigerator Should we put some default values for the CORS settings? |
Yes, the default values should mirror those we set in the sample config i guess. |
there have been CORS issues when using our map clients with local ors instances during development due to Problems with what headers are accepted and exposed by the backend. With the spring-boot update and the new run configurations using spring, setting these options properly is now possible for local instances using `spring-boot:run` or mvn version of it. However, the docker approach is still using catalina + tomcat where the settings would be passed differently, so they are not respected in a local backend running with docker. - add addCorsMappings function to ApiConfig class - extent ors-config-sample.json with default cors settings working with all origins and accepting `Authorization` headers. - if the api settings are missing from the ors config file, default values are used that correspond with the entries in the ors-config-sample.json
test all available api_settings as well as predefined defaults for HTTP methods - adjust ors-config.json for CORS tests - switch up the api_settings values to avoid testing defaults
…ht responses and cors
The web.xml is overwriting the native spring-boot CORS settings when applied. Removing them is enough to fall back to the spring-boot applied configurations. This way CORS can be centrally controlled with the normal ors config files. - change OpenRouteService to openrouteservice
These tests check the tomcat + war file deployment used in Docker, which cannot be checked via the integration or unit tests. The tests check with the wildcard from the default config first and then replace the wildcard with https://example.org. With that set, it checks for correct CORS issues by requesting with origin https://example.com.
c054aac
to
b509221
Compare
Did some squashing and dropped the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Checked locally, seems to work both in docker and run directly.
it was previously not possible to read in list of strings from the
config file.
This can now be done in a generic way.### Pull Request Checklist
have been resolved.
[Unreleased] heading.
along with a short description of what it is for, and documented this in the Pull Request (below).
(at least Germany), and the graphs build without problems (i.e. no out-of-memory errors).
importer etc.), I have generated longer distance routes for the affected profiles with different options
(avoid features, max weight etc.) and compared these with the routes of the same parameters and start/end
points generated from the current live ORS.
If there are differences then the reasoning for these MUST be documented in the pull request.
and why the change was needed.
Fixes #1394
Information about the changes
Examples and reasons for differences between live ORS routes, and those generated from this pull request
Required changes to ors config (if applicable)