CORS preflight redirects instead of serving 204

[Tattered1900]

Running Caddy v2.6.4 via docker compose

  caddy:
    container_name: caddy
    hostname: caddy
    build: ./data/caddy/dockerfile-dns
    profiles:
      - backend
    depends_on:
      - crowdsec
    networks:
      - system
    ports:
      - ${PORT_CADDY_HTTP}:80
      - ${PORT_CADDY_HTTPS}:443
    environment:
      LOG_FILE: ${CADDY_LOG}
      DOMAIN: ${DOMAIN}
      SERVER_IP: ${SERVER_IP}
      EMAIL: ${EMAIL_ADMIN}
      CLOUDFLARE_API_TOKEN: ${CLOUDFLARE_API_TOKEN}
      BOUNCER_CADDY_TOKEN: ${BOUNCER_CADDY_TOKEN}
      TZ: ${TZ}
    volumes:
      - ${ROOTDIR}/Caddyfile:/etc/caddy/Caddyfile:ro
      - ${CONFIGDIR}/caddy/data:/data
      - ${CONFIGDIR}/caddy/config:/config
      - ${LOGDIR}/caddy:/var/log/caddy/
    healthcheck:
      test: ["CMD", "caddy", "version"]
    restart: unless-stopped  

1. The problem I’m having:

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

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

I’ve setup cors policy, 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 (I think I did) with cors snippet, it should respond with 204 but somehow it still redirects

My caddy snippet and domain configuration:

(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
}

I also found this at Cross-Origin Resource Sharing (CORS) - HTTP | MDN

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?

[francislavoie]

What do you see when you make the same request with curl -v? Enable the debug global option and add the log directive to your site. What do you see in Caddy’s logs?

[Tattered1900]

Problem is and remains with the app (Outline) integration with authelia OIDC, it does not pass the cookie header.

Caddy behaves as it should.
Thanks.