| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Co-authored-by: Francis Lavoie <lavofr@gmail.com>
|
|
|
|
|
|
Some files had the old copyright or were missing the license comment entirely.
Also change Light Code Labs to Dyanim in security contact and releases.
|
|
Some new users mistakenly try to define two sites without braces around each. Doing this can yield a confusing error message saying that their site address is an "unknown directive".
We can do better by keeping track of whether the current site block was parsed with or without a brace, then changing the error message later based on that.
For example, now this invalid config:
```
foo.example.com
respond "foo"
bar.example.com
respond "bar"
```
Will yield this error message:
```
$ caddy adapt
2021/08/22 19:21:31.028 INFO using adjacent Caddyfile
adapt: Caddyfile:4: unrecognized directive: bar.example.com
Did you mean to define a second site? If so, you must use curly braces around each site to separate their configurations.
```
|
|
Some users forget to use a comma between their site addresses. This is invalid (commas aren't a valid character in domains) and later parts of the code like certificate automation will try to use this otherwise, which doesn't make sense. Best to error as early as possible.
Example thread on the forums where this happened: https://caddy.community/t/simplify-caddyfile/13281/9
|
|
* caddyfile: Errf enable error chain unwrapping
* refactor: remove parseError
|
|
* caddyfile: Add parse error on site address in `{`
This is an incredibly common mistake made by users, so we should catch it earlier in the parser and give a more friendly message. Often it ends up adapting but with mistakes, or erroring out later due to other site addresses being read as directives.
There's not really ever a situation where a lone '{' is valid at the end of a site address (but I suppose there are edgecases where the user wants to use a path matcher where it ends specifically in `{`, but... why?), so this should be fine.
* Update caddyconfig/caddyfile/parse.go
|
|
* caddyfile(formatter): fix nesting not decrementing
This is an extremely weird edge-case where if you had a environment variable {}
on one line, a comment on the next line, and the closing of the block on the
following line; the rest of the Caddyfile would be indented further than it
should've been.
ref; https://github.com/matthewpi/vscode-caddyfile-support/issues/13
* run gofmt
* fmt: better way of handling edge case
|
|
* caddyfile: Fix `import` replacing unrelated placeholders
See https://caddy.community/t/snippet-issue-works-outside-snippet/12231
So it turns out that `NewReplacer()` gives a replacer with some global defaults (like `{env.*}` and some system and time placeholders), which is not ideal when running `import` because we just want to replace `{args.*}` only, and nothing else.
* caddyfile: Add test
|
|
|
|
* caddyfile: reject recursive self-imports
* caddyfile: detect and reject cyclic imports of snippets and files
* caddyfile: do not be stickler about connected nodes not being connected already
* caddyfile: include missing test artifacts of cyclic imports
* address review comments
|
|
|
|
|
|
Previous commit improved the Caddyfile adapter so it doesn't unnecessarily add names to "skip" in "auto_https" when the server is already HTTP-only.
This commit updates the tests to reflect that change, while also fixing the Caddyfile formatting in many of the tests.
We also print the line number of the divergence between input and formatted version in Caddyfile adapt warnings - very useful for finding initial formatting problems.
|
|
Eliminates a fair amount of repeated code
|
|
* caddyfile: Introduce basic linting and fmt check
This will help encourage people to keep their Caddyfiles tidy.
* Remove unrelated tests
I am not sure that testing the output of warnings here is quite the
right idea; these tests are just for syntax and parsing success.
|
|
|
|
* caddyfile: Add support for env var defaults, tests
* caddyfile: Use ?? instead, fix redundant cast, remove env chaining
* caddyfile: Use : instead
|
|
|
|
* caddyfile: Add support for args on imports
* caddyfile: Add more import args tests
|
|
|
|
|
|
* caddyconfig: Only parse # as start of comment if preceded by space
* caddyconfig: Simplify # logic using len(val), add a test
|
|
|
|
|
|
|
|
Thus far the fuzzers have found a few crashers in the Caddyfile parser. However, the fuzzer have been stuck at import glob expansion after import glob expansion, which aren't reproducible.
|
|
Certificate selection used to be a module, but this seems unnecessary,
especially since the built-in CustomSelectionPolicy allows quite complex
selection logic on a number of fields in certs. If we need to extend
that logic, we can, but I don't think there are SO many possibilities
that we need modules.
This update also allows certificate selection to choose between multiple
matching certs based on client compatibility and makes a number of other
improvements in the default cert selection logic, both here and in the
latest CertMagic.
The hardest part of this was the conn policy consolidation logic
(Caddyfile only, of course). We have to merge connection policies that
we can easily combine, because if two certs are manually loaded in a
Caddyfile site block, that produces two connection policies, and each
cert is tagged with a different tag, meaning only the first would ever
be selected. So given the same matchers, we can merge the two, but this
required improving the Tag selection logic to support multiple tags to
choose from, hence "tags" changed to "any_tag" or "all_tags" (but we
use any_tag in our Caddyfile logic).
Combining conn policies with conflicting settings is impossible, so
that should return an error if two policies with the exact same matchers
have non-empty settings that are not the same (the one exception being
any_tag which we can merge because the logic for them is to OR them).
It was a bit complicated. It seems to work in numerous tests I've
conducted, but we'll see how it pans out in the release candidates.
|
|
This allows modules to test their UnmarshalCaddyfile methods.
|
|
|
|
|
|
|
|
|
|
This fixes indentation for blocks starting with
a brace as:
```Caddyfile
{
...
}
```
Fixes #3144
Signed-off-by: Vaibhav <vrongmeal@gmail.com>
|
|
Previously the formatter did not include support for
blocks inside other blocks. Hence the formatter could
not indent some files properly. This fixes it.
Fixes #3104
Signed-off-by: Vaibhav <vrongmeal@gmail.com>
|
|
This takes the config file as input and formats it.
Prints the result to stdout. Can write changes to
file if `--write` flag is passed.
Fixes #3020
Signed-off-by: Vaibhav <vrongmeal@gmail.com>
|
|
* Fix typo
* Fix typo, thanks for Spell Checker under VS Code
|
|
Small expansion to the work done in https://github.com/caddyserver/caddy/pull/2963 which simply calls `os.ExpandEnv` so env vars like `{$URL}` where `$URL=$SCHEME://$HOST:$PORT` (contrived) get the expanded $SCHEME, $HOST, and $PORT variables included
|
|
Now multiple instances of the same matcher can be used within a named
matcher without overwriting previous ones.
|
|
The fix that was initially put forth in #2971 was good, but only for
up to one layer of nesting. The real problem was that we forgot to
increment nesting when already inside a block if we saw another open
curly brace that opens another block (dispenser.go L157-158).
The new 'handle' directive allows HTTP Caddyfiles to be designed more
like nginx location blocks if the user prefers. Inside a handle block,
directives are still ordered just like they are outside of them, but
handler blocks at a given level of nesting are mutually exclusive.
This work benefitted from some refactoring and cleanup.
|
|
When we append a token to the new dispenser, we need to consume it in the parent, too; otherwise it gets scanned twice, which in this case messed up the nesting count which got decremented once too many times.
|
|
* fix replacing variables on imported files
* refactored replaceEnvVars to ensure it is always called
* Use byte slices for easier use
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
|
|
* transform a caddyfile with environment variables
* support adapt time and runtime variables in the caddyfile
* caddyfile: Pre-process environment variables before parsing
Co-authored-by: Matt Holt <mholt@users.noreply.github.com>
|
|
It now will delete the current token even if it is the last one
|
|
* fuzz: add missing fuzzer by fixing .gitignore adding a negation for caddyfile/ directory
* ci: print fuzzing type for debuggability and traceability
* README: update the Fuzzit badge to point to the correct Caddy server Github organization
|
|
* file_server: Make tests work on Windows
* caddyfile: Fix escaping when character is not escapable
We only escape certain characters depending on inside or outside of
quotes (mainly newlines and quotes). We don't want everyone to have to
escape Windows file paths like C:\\Windows\\... but we can't drop the
\ either if it's just C:\Windows\...
|
|
* v2: split golangci-lint configuration into its own file to allow code editors to take advantage of it
* v2: simplify code
* v2: set the correct lint output formatting
* v2: invert the logic of linter's configuration of output formatting to allow the editor convenience over CI-specific customization. Customize the output format in CI by passing the flag.
* v2: remove irrelevant golangci-lint config
|
|
Newlines (\n) can be escaped outside of quoted areas and the newline
will be treated as whitespace but not as an actual line break. Escaping
newlines inside a quoted area is not necessary, and because quotes
trigger literal interpretation of the contents, the escaping backslash
will be parsed as a literal backslash, and the newline will not be
escaped.
Caveat: When a newline is escaped, tokens after it until an unescaped
newline will appear to the parser be on the same line as the initial
token after the last unescaped newline. This may technically lead to
some false line numbers if errors are given, but escaped newlines are
counted so that the next token after an unescaped newline is correct.
See #2766
|
