You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Currently, the "internal" directive does not accept globs, wildcards, or regex. It accepts only a literal string base path, which is then compared to the path requested by the client. This makes it difficult to "set it and forget it" when it comes to similar paths.
For example, the following attempts to protect the "methods" directory (which contains files that are meant to be included or required by the php rpc server, but not by the webserver directly):
Failure to remember to update the caddy config results in granting inadvertent access to said files. Instead, if the "internal" directive had simple globbing or wildcards, you could do this (in a truly "set it and forget it" manner):
internal /www/website/rpc.domain.com/*/*/methods
As an alternative, it would be great if "internal" could protect a particular file extension:
internal *.inc
Thank you.
The text was updated successfully, but these errors were encountered:
Since no new features are being developed for v1, and this is now possible in Caddy 2, (albeit not with the Caddyfile quite yet, I think you have to use JSON for the X-Accel-Redirect-esque behavior, but that can come in 2.1 or 2.2 maybe), I will be closing this issue. Thanks!
Currently, the "internal" directive does not accept globs, wildcards, or regex. It accepts only a literal string base path, which is then compared to the path requested by the client. This makes it difficult to "set it and forget it" when it comes to similar paths.
For example, the following attempts to protect the "methods" directory (which contains files that are meant to be included or required by the php rpc server, but not by the webserver directly):
When you later start adding customer endpoints (in lieu of "demo"), you need to remember to protect the new path, and you end up with this:
Failure to remember to update the caddy config results in granting inadvertent access to said files. Instead, if the "internal" directive had simple globbing or wildcards, you could do this (in a truly "set it and forget it" manner):
As an alternative, it would be great if "internal" could protect a particular file extension:
Thank you.
The text was updated successfully, but these errors were encountered: