You can do that easily with the `remote_ip`[0] matcher (pair it with the `not` matcher to invert the match). For example to require `basicauth`[1] for all non-private IPv4 ranges:

    @needs-auth not remote_ip 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8
    basicauth @needs-auth {
        Bob JDJhJDEwJEVCNmdaNEg2Ti5iejRMYkF3MFZhZ3VtV3E1SzBWZEZ5Q3VWc0tzOEJwZE9TaFlZdEVkZDhX
    }

And for rewrites, there's the `rewrite`[2] handler. Not sure what you're missing?

[0] https://caddyserver.com/docs/caddyfile/matchers#remote-ip

[1] https://caddyserver.com/docs/caddyfile/directives/basicauth

[2] https://caddyserver.com/docs/caddyfile/directives/rewrite

One problem, as a lazy bastard, I've always had with the Caddy docs is it can sometimes be hard to glance at a page in the documentation and see "ah, that's how I'd do <common thing>".

Take the basicauth portion for example. If you had been reading the docs like a book, started in the references/tutorial sections, understood all there is to know about how request matcher syntax works as a result, and then read the basicauth page you would have a rock solid understanding of how to make basicauth do what you want here. If you land at the basicauth page from a Google search trying to stand up a quick file-server weekend project in a way your friends can access you either are really on top of it and notice "[<matcher>]" (not even mentioned in the Syntax breakdowns of the page) is what's used in the single example below and happens to be a path but might be a lot more or you leave without a hint of how to do basicauth the way you wanted. It'd be great if the syntax section breakouts just mentioned something that triggered more or less a "and hey dumbass, if you haven't learned how matchers work yet you need to go do that to fully utilized this directive".

I realize this is awfully needy, the docs have everything you need if you read them carefully, and I absolutely LOVE using Caddy so it's not an attempt to say it's bad overall by any means. I wanted to point it out though since this exact example is something I ran into a few weekends ago. I think the problem is exacerbated by v2 syntax being new, as well as the competing JSON syntax, making it harder for people to find use case examples outside of what's in the official docs.

Protip: you can click almost everything in code blocks in the docs. For example, if you click `[<matcher>]`, it brings you right to the request matcher syntax section, which explains what you can fill in there.

It would be redundant to write on every page what you can use as a matcher. The Caddyfile reference docs assume you've read https://caddyserver.com/docs/caddyfile/concepts which walks you through how the Caddyfile is structured, and it'll give you the fundamentals you need to understand the rest of the docs (I think, anyway).

If you think we need more examples for a specific usecase, we can definitely include those. Feel free to propose some changes on https://github.com/caddyserver/website, we could always use the help!

I had a huge facepalm the day I realized all of the syntax was clickable :). It's not even a uncommon feature I just hadn't tried clicking it at for some reason!

Yeah I wouldn't say necessarily every page needs examples of different matchers and certainly not about what all of the matcher options are. More a "if the token is shown in the syntax it should have a bullet in the syntax section" kind of approach which in the case of [<matcher>] could be as plain and short as "[<matcher>] is a token which allows you to control the scope a directive applies to. For details on how see Request Matchers." to raise the "you probably want to know more about this first" flag to anyone that just jumped in from Google or what have you to go read about matchers before trying to understand the directive.

If that makes any sense I'd be glad to raise it more formally over on the GitHub!

Really appreciate this feedback and the positive attitude. This is helpful, thank you!

Right, I know it's possible (and thanks for the example) - I still whish it was easier to specify "only authorized given conditions x, y, z".

In the above, access is implied, then revoked without a valid username/password, then login is excepted for certain conditions (IPs in this case) - and access is implied (again).

IMNHO one of the strengths of apache is how authentication providers and authorization is separated and allow for easy(ish) combinations.

That said, there's something to be said for doubling down on a single type of handling for access and rewrites (matchers).

I still prefer matchers (which resource) combined with action/policy (allow/deny/rewrite).

You could also do that, by structuring it like this:

    @first <whatever matcher>
    handle @first {
        do_something
    }

    @second <whatever matcher>
    handle @second {
        do_something_else
    }
    
    handle {
        error "Unauthorized" 403
    }

Which is basically an if/else-if/else structure.

I'm not totally sure I follow how you'd like for it to be structured. Could you give a config example? I think one of the issues is `basicauth` needs to write a response header to work correctly (i.e. WWW-Authenticate to tell the browser to prompt) so it can't only act as a matcher.