Change CorsConfig.enabled to optional and add logic to infer it #8038
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
Resolves #7990
Resolves #8024
The PR changes
CorsConfig#enabled
to optional so we can tell if the value is ever explicitly set--either from code or config--on theCorsSupport
builder.If so, we use the explicit setting.
If not, we set it as follows:
cors
config was used, setenabled
tofalse
.cors
config was used, setenabled
totrue
.This prevents the auto-discovered CORS logic from enabling permissive CORS settings by default.
Note that this changes the
CorsConfig#enabled()
method API. In 4.0.0 it returnsboolean
. With these changes it will returnOptional<Boolean>
.Documentation
Bug fix - no doc change
Release note information
In 4.0.0, the
CorsConfig.Builder
had the methodboolean enabled()
to return the builder's setting for whether CORS is enabled or not in the builder.In 4.0.1, the method on the builder has changed to
Optional<Boolean> enabled()
so the caller can tell whether or not CORS was explicitly enabled or disabled or whether defaults should apply.