[v2] CORS Preflight Did Not Succeed

[Whitestrake (Matthew Fay)]

@Dustin_Rowland

So is KeeWeb not sending the credentials?

Caddy’s basicauth module expects an Authorization header with matching base64-encoded credentials.

In basic HTTP authentication, a request contains a header field in the form of Authorization: Basic <credentials> , where credentials is the Base64 encoding of ID and password joined by a single colon : .

—Basic access authentication - Wikipedia

If KeeWeb is correctly forming this Authorization header for its requests, the basicauth directive will not respond with a 401 for it. So we can infer that KeeWeb is either not sending the basic auth credentials or not forming it correctly.

We can confirm that it is missing by looking at your own supplied log output above:

@Dustin_Rowland

    "request":{
        "headers":{
            "Referer":[
                "https://kee.rowland.pw/"
            ],
            "Connection":[
                "keep-alive"
            ],
            "Pragma":[
                "no-cache"
            ],
            "User-Agent":[
                "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0"
            ],
            "Accept":[
                "*/*"
            ],
            "Accept-Language":[
                "en-US,en;q=0.5"
            ],
            "Accept-Encoding":[
                "gzip, deflate, br"
            ],
            "Access-Control-Request-Method":[
                "HEAD"
            ],
            "Access-Control-Request-Headers":[
                "authorization,cache-control"
            ],
            "Origin":[
                "https://kee.rowland.pw"
            ],
            "Dnt":[
                "1"
            ],
            "Cache-Control":[
                "no-cache"
            ]
        },

Noting the complete lack of Authorization request header.

---

@Dustin_Rowland

You mentioned adding headers into this imitation and I’m not sure I understand how or where.

You should already be sending some headers, the usual CORS headers, so just one to add. From my other post, emphasis mine:

@Whitestrake

So we need:

• An empty 204 No Content response
• The usual CORS headers you’d put on
• Plus Access-Control-Allow-Methods to respond to the OPTIONS request

As for adding the single header you’d need, and responding, this is the relevant part of the post:

@Whitestrake

Now, just to keep things neat, I’d recommend you use a handle directive to bundle the respond and header directives together in a neat package and tell Caddy to exclusively use that for any OPTIONS request.

https://caddyserver.com/docs/caddyfile/directives/header
respond (Caddyfile directive) — Caddy Documentation
handle (Caddyfile directive) — Caddy Documentation

handle isn’t necessary, it’s just more readable in my opinion.

Note also that if you’re doing this across the entire board for all OPTIONS requests, you might want to narrow it down a bit more. Note also my further response in the linked thread:

@Whitestrake

As a quick addendum, since the CORS preflight is a different kind of OPTIONS request to a regular one, and we probably don’t wanna respond to a regular OPTIONS request with a CORS preflight response, you can also differentiate the two easily by the presence of the Access-Control-Request-Method request header.