Whitelisting possibility with basic auth

[stp (Michael)]

My current caddyfile for piwik looks like this:

    :8080 {
      root /var/www
      gzip
      log stdout
      errors stdout
      basicauth admin {$BASICAUTH_PASSWORD} {
        /index.php
        /config/
        /js/
        /core/
        /tmp/
        /vendor/
        /plugins/
        /libs/
        /misc/
        /lang/
      }
      fastcgi / 127.0.0.1:9000 php
      rewrite {
        if_op or
        if {path} has config.ini.php
        if {path} has install.php
        if {path} has .md
        if {path} has .text
        if {path} has .json
        if {path} has .lock
        to /403
      }
      status 403 /403
    }

With the proposed change/addition in Basic auth path exception? - #9 by thechriswalker

It could simply look like:

    :8080 {
      root /var/www
      gzip
      log stdout
      errors stdout
      basicauth admin {$BASICAUTH_PASSWORD} {
        not /piwik.php
        not /piwik.js
      }
      fastcgi / 127.0.0.1:9000 php
      rewrite {
        if_op or
        if {path} has config.ini.php
        if {path} has install.php
        to /403
      }
      status 403 /403
    }

Is there any other sane way to do this? Not playing around with proxy workarounds etc. As fastcgi doesn’t support a without a rewrite solution isn’t that simply.

Any ideas are greatly appreciated.

[Whitestrake (Matthew Fay)]

@stp

Not playing around with proxy workarounds etc.

Don’t know about proxy workarounds, but other than this, the only method I know is to use redirects to bounce clients between a “secure” subdomain vhost with a blanket basicauth and an “insecure” default domain, using if statements to check the requested URI.

I really like the suggestion you linked for exception logic in the basic auth directive though! I’d like to see something like this:

basicauth / user pass {
    except /piwik.php
    except /piwik.js
}

Creates a very clear intent to declare a basepath to secure and then specify exceptions. To let you secure by default but flag out known resources that are OK to share would be quite useful, especially when the contents of the web root might change.

[matt (Matt Holt)]

The wider problem here is present for all directives: right now, most Caddy directives operate on a base path that the request has to match, but Caddy really needs a better, standardized way to do request matching so that it can match on more than just a base path.

I proposed a couple related things in an issue once but I only implemented #2. I still feel like something similar to #1 is needed to make Caddy really powerful/useful for power users (note that Caddy’s initial target audience is for more simple use cases, but I want to bring Caddy to more advanced sites).

[Whitestrake (Matthew Fay)]

Apart from the concept of opening a block in the middle of a one-liner directive seeming odd to me, which might just be due to being used to how Caddyfiles are already… That sounds like it would be absolutely wonderful and I can think of two or three common-enough use cases off the top of my head that it would solve without the need for weird workarounds.

edit: After reading through the issue, which seems to have been well discussed, it seems to me like getting this kind of power in the Caddyfile syntax without complexity is chasing an optimistic ideal.