Help with CORS in OIDC setup (with caddy v2) - preflight redirect instead of 204

[C8opmBM]

I've been struggling to find a solution to this, to no end.

So I have outline setup with OIDC.
The main subdomain wiki.domain needs to make requests to wikidata.domain in order to upload images.

I've setup cors policy in caddy v2, but all the time I have this error in browser.

Access to XMLHttpRequest at 'https://wikidata.domain.net/outline' from origin 'https://wiki.domain.net' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: Redirect is not allowed for a preflight request.

I've configured it correctly with cors snippet, it should respond with 204 but somehow it still redirects

My caddy snippet:

(cors) {
        @cors_preflight{args.0} method OPTIONS
        @cors{args.0} header Origin {args.0}

        handle @cors_preflight{args.0} {
                header {
                        Access-Control-Allow-Origin "{args.0}"
                        Access-Control-Allow-Methods "GET, POST, PUT, PATCH, DELETE, OPTIONS"
                        Access-Control-Allow-Headers *
                        Access-Control-Max-Age "3600"
                        defer
                }
                respond "" 204
        }

        handle @cors{args.0} {
                header {
                        Access-Control-Allow-Origin "{args.0}"
                        Access-Control-Expose-Headers *
                        defer
                }
        }
}

auth.{$DOMAIN} {
        import cors https://wiki.{$DOMAIN}
        import cors https://wikidata.{$DOMAIN}
        reverse_proxy authelia:9091
}

If I bypass for internal ip for wiki.domain and wikidata.domain in authelia, the uploads work, so this makes me think the issue is with authelia rather than my cors reverse proxy setup

  - name: internal
    networks:
    - '172.20.0.0/16'
    - '192.168.0.0/18'
  rules:
    - domain: ['wiki.domain.net', 'wikidata.domain.net']
      networks:
        - 'internal'
      policy: bypass

Could you point me in the right direction?

My identity providers cors setting (I've tried with "*" as well), doesnt work.

identity_providers:
  oidc:
    cors:
      endpoints:
        - authorization
        - token
        - revocation
        - introspection
        - userinfo
      allowed_origins:
      allowed_origins_from_client_redirect_uris: false

Authelia log during request:

time="2023-03-01T20:55:12+02:00" level=info msg="Access to https://wikidata.domain.net/outline (method OPTIONS) is not authorized to user <anonymous>, responding with status code 302 with location redirect to https://auth.domain.net/?rd=https%3A%2F%2Fwikidata.domain.net%2Foutline&rm=OPTIONS" method=GET path=/api/verify remote_ip=192.168.1.153

I also found this at https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#preflighted_requests

Credentialed requests and wildcards
When responding to a credentialed request:

The server must not specify the "*" wildcard for the Access-Control-Allow-Origin response-header value, but must instead specify an explicit origin; for example: Access-Control-Allow-Origin: https://example.com
The server must not specify the "*" wildcard for the Access-Control-Allow-Headers response-header value, but must instead specify an explicit list of header names; for example, Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
The server must not specify the "*" wildcard for the Access-Control-Allow-Methods response-header value, but must instead specify an explicit list of method names; for example, Access-Control-Allow-Methods: POST, GET
The server must not specify the "*" wildcard for the Access-Control-Expose-Headers response-header value, but must instead specify an explicit list of header names; for example, Access-Control-Expose-Headers: Content-Encoding, Kuma-Revision

However I do not know how should I adapt this.
Any insights?

[james-d-elliott]

The issue is most likely that the preflight doesn't include credentials (cookie header). This either needs to be fixed by the app developer or you need to setup a bypass rule the preflight requests.

[C8opmBM]

Thanks James, I've tried also to include the suggested doc setup, but it does not work.

access_control:
  rules:
    - domain: ['wiki.domain.net', 'wikidata.domain.net']
      methods:
        - OPTIONS
      policy: bypass

It only works if I bypass them completely (as mentioned above, tested with bypass on local networks).
Any other suggestion?

[james-d-elliott]

I'm guessing it's not including the credentials at all then, even with non-preflight requests?

[C8opmBM]

Is that even possible? The other domain (wikidata.domain) is part of the oidc app, it's the upload bucket, but I try to cover it under authelia umbrella as well via normal access_control subdomain policy.

So the workflow is like this: the main app Outline is protected by oidc, having its main domain at wiki.domain.
The second domain wikidata.domain is the upload bucket, to which the main domain makes requests whenever it needs to upload, but only to a certain uri wikidata.domain/outline. This domain has no protection it seems, and if accessed directly, it redirects to the third domain wikidatata-admin.domain which is not exposed (points to an internal IP).

Maybe the second domain doesn't need protection?

Anyway, this is a weird situation.

LE: it seems the cookies are not included in the POST request. If I bypass POST, it works.

msg="Check authorization of subject username= groups= ip=192.168.1.153 and object https://wikidata.domain.net/outline (method POST)."

GET requests are passed correctly:
msg="Check authorization of subject username=myuser groups=admins,dev ip=192.168.1.153 and object https://wikidata.domain.net/outline/uploads/51864f23-9981-4318-8d06-4c3b07c7c403/6f18c4db-eacd-4c2c-82fb-0bc320072d29/222.png?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=minio%2F20230301%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20230301T204112Z&X-Amz-Expires=60&X-Amz-Signature=d06974d85124fbcb90392aaf3d90f33e9184b9c3df24e3bae0f60b23cdd5bbbb&X-Amz-SignedHeaders=host&response-content-disposition=attachment (method GET)."

[james-d-elliott]

When performing requests with js it's indeed possible to make them with credential information or without depending on how the request is made and how the application is secured. If you use the app which is redirecting normally then you may see the situation changes. I suspect what will occur is that you'll see a cookie header on both apps with the authelia_session key which match and are assigned to the cookie domain you configured (i.e. both domains have access to this cookie).