CORS issues when running web on different host

[kulmann]

Describe the bug

Serving the web assets from a different host / port than the backend causes CORS issues.
The first failing request after login is an OPTIONS request to /ocs/v1.php/cloud/user, there are probably more issues. 😉
In the case of the mentioned OPTIONS request the backend requires authentication and returns a 401, whereas OPTIONS requests should never require authentication.

Steps to reproduce

Steps to reproduce the behavior:

1. checkout web master (after Fix idp config dev setup web#8016 is merged)
2. run docker-compose up -d
3. create a symlink to the dev setup config.json: ln -s ../dev/docker/ocis.web.config.json config/config.json
4. run pnpm i && pnpm serve
5. try to log in on https://host.docker.internal:9100 (you might need to add host.docker.internal as localhost alias to your /etc/hosts file if not already present)

Expected behavior

You should be able to login and see your personal space ;-)

Actual behavior

CORS errors

Setup

The dev setup from the web repo, see steps to reproduce, with an up to date ocis docker image.

[kulmann]

cc @wkloucek this is what we saw today in our zoom call

[dschmidt]

I found a (fairly reasonable) workaround that works in our new development setup, so there's no real urgency to get this fixed from our side.
(Still think this should be fixed rather sooner than later but it's not blocking us anymore )

[dschmidt]

Despite the recently closed tickets/PRs linking this issue, it's still not fixed in oCIS latest

[micbar]

@dschmidt what config did you use and what is exactly the problem?

You need to set the OCIS_CORS_* variables. https://doc.owncloud.com/ocis/next/deployment/services/env-vars-special-scope.html

[dschmidt]

Okay, thanks for the hint - I'm pretty sure I've looked into it with someone from the oCIS team at some point and we concluded that in fact it was broken.

I've now added the following env vars to oCIS in the Web development setup:

      OCIS_CORS_ALLOW_HEADERS: "*"
      OCIS_CORS_ALLOW_METHODS: "*"
      OCIS_CORS_ALLOW_ORIGINS: "https://host.docker.internal:9201" # also tried "*"

Here are the failed requests I can see for now (possibly more after these have been fixed):

Access to fetch at 'https://host.docker.internal:9200/themes/owncloud/theme.json' from origin 'https://host.docker.internal:9201' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Access to XMLHttpRequest at 'https://host.docker.internal:9200/api/v0/settings/values-list' from origin 'https://host.docker.internal:9201' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Access to XMLHttpRequest at 'https://host.docker.internal:9200/ocs/v1.php/cloud/user' from origin 'https://host.docker.internal:9201' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Access to XMLHttpRequest at 'https://host.docker.internal:9200/ocs/v1.php/cloud/capabilities?format=json' from origin 'https://host.docker.internal:9201' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Note: oCIS is running on port 9200, our frontend development server is running on port 9201

[wkloucek]

      OCIS_CORS_ALLOW_HEADERS: "*"
      OCIS_CORS_ALLOW_METHODS: "*"
      OCIS_CORS_ALLOW_ORIGINS: "https://host.docker.internal:9201" # also tried "*"

Actually you only should set OCIS_CORS_ALLOW_ORIGINS.

Access-Control-Allow-Methods: * should actually do harm in your case:

The value "*" only counts as a special wildcard value for requests without credentials (requests without [HTTP cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies) or HTTP authentication information). In requests with credentials, it is treated as the literal method name "*" without special semantics.

(https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Methods)

[dschmidt]

Thanks a lot, @wkloucek - really good catch!

With just OCIS_CORS_ALLOW_ORIGINS set, I can make oC Web boot up and render a personal space listing. But other issues become apparent now:

Access to XMLHttpRequest at 'https://host.docker.internal:9200/ocs/v1.php/cloud/user/signing-key' from origin 'https://host.docker.internal:9201' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Access to XMLHttpRequest at 'https://host.docker.internal:9200/remote.php/dav/spaces/1284d238-aa92-42ce-bdc4-0b0000009157%24some-admin-user-id-0000-000000000000/sadfasdf.txt' from origin 'https://host.docker.internal:9201' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

[2403905]

@dschmidt Can not reproduce on my local. Please describe your environment.

[dschmidt]

If you are testing with the current oC Web dev stack, you need to remove the traefik cors middleware from the ocis service to make the issue visible again.

[2403905]

Looks like some requests don't contain the Origin header.

@janackermann or @JammingBen Could you validate please if the request on the screenshot contains the Origin header?

Steps:
Latest https://github.com/owncloud/web
Cometed out the # traefik.http.routers.ocis.middlewares: cors in docker-compose.yml
Run backenddocker-compose up ocis -d
Run frontend pnpm vite
Login as an admin
Got to the Spaces, create a New space, go inside a New space.

[AlexAndBear]

@2403905
Currently, there are two issues related to CORS AFAIR

Access-Control-Allow-Origin
If the server and web are served from a different location, Access-Control-Allow-Origin must be set (for example to value:'*')
Otherwise, it will be blocked by CORS
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin

Access-Control-Expose-Headers
if Access-Control-Expose-Headers (for example value: '*') is not set on the server side, the frontend can't retrieve/access multiple headers, that we rely on.

See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Expose-Headers

Otherwise, only those headers will be provided:

[Cache-Control](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control)
[Content-Language](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Language)
[Content-Length](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Length)
[Content-Type](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Type)
[Expires](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires)
[Last-Modified](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Last-Modified)
[Pragma](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma)

https://developer.mozilla.org/en-US/docs/Glossary/CORS-safelisted_response_header

You can check if those CORS entries are set by yourself in the browser's debug tools. I can't give you a general answer on that question, because it depends how OCIS and Web are deployed

[2403905]

@janackermann https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request
When the client sends the preflight request it could contain the Origin header. The question is why some request doesn't contain the Origin?

[AlexAndBear]

@2403905
CORS will be set by the server, this is nothing that the frontend is in control of, I think your question could be better answered by a server team member.

So to clarify: Frontend can't change anything that's CORS related it's 100% server side, PREFLIGHT Requests are done by the browser (not in our hand) and we can't manipulate this.

[2403905]

@janackermann Is the frontend managing the access-control-request-headers ?

[AlexAndBear]

@2403905 as I said before, cors is exclusive handled by server. Cors would be senseless if managed by Frontend

[2403905]

I found the cause but @janackermann we still need to work together to figure out the root cause of this issue.
We have the OPTION requests that contain the not allowed value cache-control in the Access-Control-Request-Headers which leads to CORS error.
Workaround: Add the cache-control to the allowed headers
OCIS_CORS_ALLOW_HEADERS: 'Origin,Accept,Content-Type,Depth,Authorization,Ocs-Apirequest,If-None-Match,If-Match,Destination,Overwrite,X-Request-Id,X-Requested-With,Tus-Resumable,Tus-Checksum-Algorithm,Upload-Concat,Upload-Length,Upload-Metadata,Upload-Defer-Length,Upload-Expires,Upload-Checksum,Upload-Offset,X-HTTP-Method-Override,cache-control'