API: Add OPTIONS request handler to serve CORS preflight requests

[techmatt101]

Add support for CORS requests to the PhotoPrism API. Would like the option to pass new flags: --http-cors-allow-origins, --http-cors-allow-methods, and --http-cors-allow-headers. to enable web apps on different domains to call the PhotoPrism API directly, without needing a proxy.

Use case: I self-host PhotoPrism and run a separate photo frame app that fetches images via the PhotoPrism API. Without CORS headers, requests are blocked by the browser.

Note: This is not the same as PHOTOPRISM_CORS_ORIGIN, which controls image access from the PhotoPrism web app to external sources like CDNs.

[lastzero]

From what I see, your PR adds duplicate config options for the same headers we already set and which are described in our documentation at https://docs.photoprism.app/getting-started/config-options/#site-information?

		// See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin
		if origin := conf.CORSOrigin(); origin != "" {
			c.Header(header.AccessControlAllowOrigin, origin)

			// Add additional information to preflight OPTION requests.
			if c.Request.Method == http.MethodOptions {
				c.Header(header.AccessControlAllowHeaders, conf.CORSHeaders())
				c.Header(header.AccessControlAllowMethods, conf.CORSMethods())
				c.Header(header.AccessControlMaxAge, header.DefaultAccessControlMaxAge)
			}
		}

If that is not the case, please let us know which headers should be set differently or added, including the exact header name and a link to the specification. Note that setting PHOTOPRISM_CORS_ORIGIN to * allows all origins and is generally safe enough for most use cases, especially at home.

[techmatt101]

You are correct, that when setting PHOTOPRISM_CORS_ORIGIN it is returned on the response headers. However I'm struggling to see how this ever worked in practice, as browsers will make a pre flight OPTIONS request, which currently photoprism will always return 404, failing the CORS in the browser.

curl --request OPTIONS \
  --url http://localhost:2342/api/v1/config \
  --header 'Accept: */*' \
  --header 'Accept-Encoding: gzip, deflate, br, zstd' \
  --header 'Accept-Language: en-GB' \
  --header 'Access-Control-Request-Method: GET' \
  --header 'Origin: http://localhost' \
  --header 'Referer: http://localhost' \
  --header 'Sec-Fetch-Mode: cors' \
  --header 'Sec-Fetch-Site: cross-site' \
  --header 'User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:141.0) Gecko/20100101 Firefox/141.0'

Tested request always returns a 404 when setting PHOTOPRISM_CORS_ORIGIN. I would expect this request to return 204, as it does when testing with my PR changes. Is there something I'm missing, from what I can see it's a bug that OPTION requests are not handled correctly. This is why I added router.Use(cors.New(conf.HttpCors())) middleware in the PR.

I can update the PR to use the existing flags instead.

[lastzero]

Thanks! That makes it clearer. If the only issue is missing support for the OPTIONS request method, there might be an easier way to add that — i.e. without adding new dependencies and configuration options to the project.

Would you need it for all server endpoints, all the API endpoints under /api/v1/, or only specific API endpoints?

[techmatt101]

I would say all API endpoints under /api/v1/ preferably. My web app will be calling /config first but others might not follow that.

I think your right, there is probably a better way than adding another dependency to the project. I'n not familiar with the project or using go, so welcome any guidance/help on this, thanks.

[lastzero]

I'm currently need to work on other issues, but will be happy to take a look when I have time. You're welcome to remind me should I forget!

[lastzero]

@techmatt101 my changes above, combined with PHOTOPRISM_CORS_ORIGIN, should do the trick:

• https://docs.photoprism.app/getting-started/config-options/#site-information

The commit adds a wildcard request handler to ensure that OPTIONS requests don't return error 404 (Not Found). I guess this shouldn't be a problem since there are no other REST API endpoints that use or require it. Things might be different for the WebDAV API endpoints, but they should not be affected by the changes.

Updated preview builds will soon be available for testing. Any help with this would be much appreciated!