Caddy does not respect cookies?

Hi folks,

This is my first post here, so welcome.
I’m thinking about migrating from nginx (weird if conditions, etc) to caddy.
I’m using latest caddy (from couple days ago) compiled by myself (go get…)

But I stuck at cookies. I’m trying to secure wordpress instalation with non standard way - only user with specific cookie can go to /wp-admin/* or wp-login.php, the rest should be redirected/rewrited to not_found.html.

My Caddyfile

        rewrite /wp-admin/ {
                regexp .+
                if {~cookiename} not "LONG_ID"
                to not_found.html
        }

        rewrite /wp-login {
                regexp ^\.php+
                if {~cookiename} not "LONG_ID"
                to not_found.html
        }

        rewrite {
                if {path} not_match ^\/wp-admin/.+
                to {path} {path}/ /index.php?{query}
        }

Problem is that my browsers have this cookie, even I’m trying to use httpie:
http --follow GET http://example.org:2015/wp-admin/ ‘Cookie:cookiename=LONG_ID’

But Caddy says:

HTTP/1.1 404 Not Found
Content-Encoding: gzip
Content-Length: 38
Content-Type: text/plain; charset=utf-8
Date: Wed, 19 Jun 2019 17:40:41 GMT
Server: Caddy
Vary: Accept-Encoding
X-Content-Type-Options: nosniff

404 Not Found

For user with no cookie this is somewhat ok, but not for users with cookie. I was trying many options, order and I don’t know what’s going on. Any clues would be highly appreciated. :slight_smile:

Are you sure using cookiename is a reliable and safe solution?

The cookiename could be forged.

How many users need access to the admin area?

You could possibly add:
https://caddyserver.com/docs/status
https://caddyserver.com/docs/errors

Yes as my main goal is to prevent bots from trying to guess login and password and this solution seems to be perfect. Users will have to enter to “secret” and “hidden” website which sets this cookie for them.

Anyway, I was fighting with this problem, and still it does not work. Does caddy have any debug options to check which rules were/were not applied during processing request or something? Such information would be helpful in debugging this problem. :frowning:

I find custom logging useful in this situation.

I append useful placeholders to the common log format to tell how Caddy received / manipulated a request.

You might get some use out of this:

log / /path/to/access.log "{common} /// {rewrite_uri} {~cookiename}"

Provoke the issue, then check the log to see if Caddy received the cookie as expected and also whether Caddy rewrote the URI (and what it rewrote it to).

https://caddyserver.com/docs/log


P.S. you can save a bit of unnecessary regex processing:

rewrite /wp-admin/ {
  # regexp is completely unnecessary here as
  # it will always evaluate a match because
  # this rewrite always has a base path
  if {~cookiename} not "LONG_ID"
  to not_found.html
}

rewrite /wp-login {
  # this regex check can be done with substrings much faster
  if {file} ends_with .php
  if {~cookiename} not "LONG_ID"
  to not_found.html
}

rewrite {
  # the not-match is unnecessary (a case of citogenesis?) -
  # it provides neither security nor functionality
  # specifying the index file is also not canonical or necessary
  to {path} {path}/ /?{query}
}

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.