Current situation: we need to write code to implement the MVC CORS configuration using java configuration or xml file. This is as per described in https://docs.spring.io/spring-framework/reference/web/webmvc-cors.html

Enhancement: I would like to propose to support this via properties and yaml as well, using predefined properties keys, and let the auto-configuration for spring mvc do the job.

Comment From: philwebb

The CorsRegistry interface is quite a complex API to represent as properties so I'm not sure that we should do this. Flagging to see what the rest of the team think.

Comment From: hannah23280

Cos i understood that spring actuator library also has something similar (as shown below). So if actuator can do that, i was thinking maybe mvc library can do something similar

management.endpoints.web.cors.allowed-origins= management.endpoints.web.cors.allowed-methods=OPTIONS, GET, POST management.endpoints.web.cors.allowed-headers=

Comment From: hannah23280

Moreover, if xml for mvc core configuration can do it, i would also thought properties should be able to do so. Of course for meantime, we can use xml if we don't want coding, but xml bit verbose. 

  <mvc:cors>

    <mvc:mapping path="/api/**"
        allowed-origins="https://domain1.com, https://domain2.com"
        allowed-methods="GET, PUT"
        allowed-headers="header1, header2, header3"
        exposed-headers="header1, header2" allow-credentials="true"
        max-age="123" />

    <mvc:mapping path="/resources/**"
        allowed-origins="https://domain1.com" />

</mvc:cors>

Comment From: wilkinsona

The actuator properties and the MVC XML are each configuring a single set of CORS configuration. A properties-based equivalent of CorsRegistry would need to be able to configure multiple sets of CORS configuration. I think that would be cumbersome as the path pattern is the identifier for each set of configuration:

spring.web.cors./api/**.allowed-origins=…
spring.web.cors./api/**.allowed-methods=…
spring.web.cors./api/**.allowed-headers=…
spring.web.cors./api/**.exposed-headers=…

I doubt this would work, particularly with environment variables where certain characters are restricted.

An alternative would be to invent some unique identifier that's repeated to create each set of configuration:

spring.web.cors.api.path-pattern=/api/**
spring.web.cors.api.allowed-origins=…
spring.web.cors.api.allowed-methods=…
spring.web.cors.api.allowed-headers=…
spring.web.cors.api.exposed-headers=…

I don't like this either. IMO, the Java API is a better option.

Comment From: hannah23280

The actuator properties and the MVC XML are each configuring a single set of CORS configuration. A properties-based equivalent of CorsRegistry would need to be able to configure multiple sets of CORS configuration. I think that would be cumbersome as the path pattern is the identifier for each set of configuration:

spring.web.cors./api/**.allowed-origins=… spring.web.cors./api/**.allowed-methods=… spring.web.cors./api/**.allowed-headers=… spring.web.cors./api/**.exposed-headers=…

I doubt this would work, particularly with environment variables where certain characters are restricted.

An alternative would be to invent some unique identifier that's repeated to create each set of configuration:

spring.web.cors.api.path-pattern=/api/** spring.web.cors.api.allowed-origins=… spring.web.cors.api.allowed-methods=… spring.web.cors.api.allowed-headers=… spring.web.cors.api.exposed-headers=…

I don't like this either. IMO, the Java API is a better option.

It might look "horrible" when using properties file. But when using yaml, might be different. Nevertheless,spring cloud api gateway already got support similar configuration, so wonder why mvc CORS configuration can't follow suite?

    gateway:
      globalcors:
        cors-configurations:
          "[/**]":
            allowedOrigins: http://localhost:3000
            allowedHeaders: "*"
            allowedMethods:
              - GET
              - POST
              - OPTIONS

Comment From: bclozel

I think the Java API is a better choice here too. While this model is supported by Spring Cloud Gateway, I think that the tradeoff is a bit different when managing a gateway vs. an application.

Comment From: hannah23280

I think the Java API is a better choice here too. While this model is supported by Spring Cloud Gateway, I think that the tradeoff is a bit different when managing a gateway vs. an application.

understood. But i still see no harm in providing support for file configurations. I am not suggesting to remove Java API , hence those that still prefer conding, can continue to do so.

Properties/Yaml always has the benefit of able to make changes without having to recompile the code.

Comment From: wilkinsona

There's the cost of implementing the feature and then maintaining it. This maintenance cost is likely to be larger than we'd like as the support would only work well with YAML files whereas Spring Boot users expect configuration properties to work with properties files, environment variables, system properties and so on as well.

If you are happy with support that's only intended for use with YAML, your best option is to implement it yourself using a WebMvcConfigurer and your own @ConfigurationProperties-annotated class. Thanks anyway for the suggestion.