Does It is possible to provide allowedOrigin patterns?

[tamtakoe]

https://*.domain1.com -- domains ending with domain1.com
https://*.domain1.com:[8080,8081] -- domains ending with domain1.com on port 8080 or port 8081
https://*.domain1.com:[*] -- domains ending with domain1.com on any port, including the default port 

Or smth like this?

[jub0bs]

The README says

An origin may contain a wildcard (*) to replace 0 or more characters (i.e.: http://*.domain.com).

• Pattern https://*.domain1.com matches any origin ending in .domain1.com.
• Pattern https://*.domain1.com:[8080,8081] is useless because [8080,8081] is taken literally and no valid Web origin looks like that. However AllowedOrigins: []string{"https://*.domain1.com:8080", "https://*.domain1.com:8081"} would work.
• Patterns https://*.domain1.com:[*] or https://*.domain1.com:* wouldn't do what you expect because at most one wildcard is possible. But do you really have a use case for allowing arbitrary subdomains and arbitrary ports?

[tamtakoe]

My example is Spring pattern https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/web/cors/CorsConfiguration.html#setAllowedOriginPatterns(java.util.List)

But do you really have a use case for allowing arbitrary subdomains and arbitrary ports?

Yes. See my current development config

allowed_origins:
  - https://*.mysite.com
  - http://localhost:4100
  - http://localhost:4200
  - http://localhost:4300
  - http://localhost:4400
  - http://127.0.0.1:4100
  - http://127.0.0.1:4200
  - http://127.0.0.1:4300
  - http://127.0.0.1:4400

[jub0bs]

The same origin patterns would work with rs/cors. What's the problem? Were you hoping that you could express your desired allowed origins more easily with rs/cors than with Spring? I'm not very familiar with Spring, but I don't think that's possible.

[tamtakoe]

The same origin patterns would work with rs/cors.

https://*.domain1.com:[8080,8081] etc. doesn't work with rs/cors, but it works with Spring. Spring is the most popular framework for Java, and Java is among the top popular languages. This means that this pattern is familiar to many developers.

but I don't think that's possible.

Looks like no problem if rs/cors will unwrap

- https://*.domain1.com:[8080,8081] or - https://*.domain1.com:8080-8081

to

- https://*.domain1.com:8080
- https://*.domain1.com:8081

[jub0bs]

@tamtakoe

https://*.domain1.com:[8080,8081] etc. doesn't work with rs/cors, but it works with Spring. [...]

I'm aware of Spring (of course) but I didn't know that it supported such an origin pattern. Interesting.

Spring is the most popular framework for Java, and Java is among the top popular languages. This means that his pattern is familiar to many developers.

Ok, but different CORS libraries from different ecosystems support different origin patterns. I don't think the goal of rs/cors is to cater for developers coming from all those other ecosystems. Those developers simply need to take the time to read the documentation in order to figure out what's possible or not.

Looks like no problem if rs/cors will unwrap

https://*.domain1.com:[8080,8081] or - https://*.domain1.com:8080-8081

to

- https://*.domain1.com:8080
- https://*.domain1.com:8081

If https://*.domain1.com:8080-8081 is meant as ports ranging from 8080 to 8081, I'm not convinced that supporting port ranges is warranted. As for https://*.domain1.com:[8080,8081], I'm not convinced either; at the cost of duplicating the https://*.domain1.com: part, developers can just specify two origin patterns, each with one of the desired ports. And I remain unconvinced that a pattern like https://*.domain1.com:* corresponds to an actual use case. I'm happy to be proven wrong, of course.

[jub0bs]

@tamtakoe FWIW, I've just released a new version of my CORS middleware library that supports origin patterns like https://*.domain1.com:*.