I notice that CORS and OAuth2 are independent options. OAuth2 provider is enabled by default. When OAuth2 is disabled, then users cannot register their own applications, so there is a functionality change.
CORS, on other hand, is disabled by default, but there is no user impact except that no 3rd party web application can contact the Gitea instance directly. In default config today, users can register their apps, but cannot actually use them.
Why is CORS disabled by default if OAuth2 is enabled? Would it make sense to have CORS enabled by default too, especially for an app that takes care of these settings correctly like Gitea?
I’m asking if there is some deeper reason here or just oversight.
Thanks!
Adam
I think the distinction between the two defaults makes sense, especially from a security perspective. OAuth2 being enabled doesn’t necessarily mean every Gitea instance should accept cross-origin requests by default.
CORS can be quite easy to overlook once enabled, so keeping it opt-in gives administrators a chance to explicitly decide which origins should have access. That said, I can understand the argument that the current defaults may feel inconsistent when OAuth2 applications can be registered but can’t be used directly from a third-party web application.
I’d also be interested to hear whether this was an intentional security decision or simply something that was never revisited as the OAuth2 functionality evolved.