Add CORS support

[abatkin]

Add CORS support to linkding. This is useful if you are running an alternate web-based frontend. By default, all CORS support is disabled, but once one of the documented environment variables are set, an additional Django middleware (django-cors-headers) is added and configured appropriately.

This change:

• adds a new dependency django-cors-headers (which adds no additional net-new transitive dependencies)
• adds a number of new configuration parameters/environment variables
• documents the settings on the Options page

[garyp]

I'm working on an alternative web-based frontend and also had a need for the Linkding API to return CORS headers. I just tested this PR and it works great (at least for my use case).

[abatkin]

Rebased against master

[abatkin]

@sissbruecker is CORS support something that you think could be accepted, assuming the implementation was able to meet the appropriate standards? Are there concerns about adding a new dependency (django-cors-headers), the (too?) many configuration options, or something else? Thanks!

[sissbruecker]

Those would indeed be the main concerns. It adds a lot of rather technical options and requires a new dependency for something that is not really needed by the majority of users. Apart from that I haven't really had the time or motivation to engage with this, partly also because I see little value in it compared to other things I could do (or that interest me more I guess). But I tend to change my mind so maybe I'll proceed with this at some point.

[ad732]

@abatkin
I'm not familiar with CORS headers, but would it be possible to simplify all those configuration values into a single environment variable where you can specify the allowed URL origins for requests?

How about only having LD_CORS_ALLOWED_ORIGINS as a configuration option?

---

For example, could we remove LD_CORS_URLS_REGEX, since there don't appear to be any endpoints other than /api/* where setting CORS headers would be necessary anyway?

On a related note, does it really make sense to have LD_CORS_ALLOWED_REGEX? Why use a regex at all instead of explicitly specifying allowed origins? I'm not sure what the intended use case is here-would someone ever realistically expose Linkding across multiple domains where pattern matching would be required?

Isn't LD_CORS_ALLOWED_METHODS also redundant, since we should generally allow all HTTP methods supported by the API?

I also wonder whether LD_CORS_ALLOWED_HEADERS and LD_CORS_EXPOSE_HEADERS should really be exposed as configuration options. My understanding is that these are internal implementation details that end users typically shouldn't need to manage. If more custom behavior is required, wouldn't it be better for the users themself to handle it at the reverse proxy level?

Similarly, could we just choose a sensible default for LD_CORS_PREFLIGHT_MAX_AGE and remove the configuration option altogether? I doubt many people would need to adjust it.

[abatkin]

I think that's reasonable - only allowing CORS_ALLOWED_ORIGINS as a configuration option.

The next question is whether it makes sense to use the https://pypi.org/project/django-cors-headers/ third-party library, or to build the functionality directly into the app. I'm fine implementing from scratch, the CORS standard isn't not a moving target at this point.