Add prefix option

[mholt]

I need to understand better what this does. Does this rewrite the request URI? i.e. does it strip the prefix? Or is it a read-only thing? Does it append the prefix the filepath when accessing disk?

[wader]

It is stripped from the URI path before access files in the root path and it is prepended to paths returned by PROPFIND.

See https://github.com/golang/net/blob/master/webdav/webdav.go for details.

[mholt]

Ahh.

So, URI manipulation is typically the role of the rewrite handler: https://caddyserver.com/docs/modules/http.handlers.rewrite

In other words (Caddyfile docs):

uri strip_prefix /prefix/goes/here
webdav

What do you think? Do you think the webdav plugin should be modifying the request?

[wader]

Yeap would make sense but I have problems getting it to work with webdav clients if I just strip but don't prepend the paths returned in PROPFIND. Trying to understand what the webdav spec says about it.

https://tools.ietf.org/html/rfc4918#section-8.3

WebDAV only uses one form of relative reference in its extensions, the absolute path.

And the examples seems to indicate absolute path are needed.

If that is the case we need to pass the Prefix to webdav.Handler or modify add that functionally to it :( or do you have any ideas?

[mholt]

Okay, I see.

If stripping the path is internal-only and doesn't actually modify the req.URL.Path value, then it's totally fine to configure the handler to do it.

Ideally, the handler that needs the path to be changed will copy the path value and change that, like, path := strings.TrimPrefix(req.URL.Path, "/prefix"), as opposed to: req.URL.Path = strings.TrimPrefix(req.URL.Path, "/prefix") which is destructive.

So, this change is acceptable as long as it doesn't permanently mutate the request path.

[wader]

Good! are the field comments used to generate documentation somehow? got a bit concerned that my example will get mangeled and look weird somehow

[wader]

Do you have any pointer or ideas for how the auth things should work? I might have a look it at some point

[mholt]

Yeah, they are -- in fact we render them as markdown. The website doesn't yet support external plugin docs, but it will eventually, so we might want to keep that in mind.

I'll add you as a collaborator to this repo and then next we can see if @hacdias wants to adopt it back upstream.

[mholt]

@wader The auth plugins use the authentication handler: https://caddyserver.com/docs/modules/http.handlers.authentication -- right now it's just basicauth.

But @greenpau is making some good progress on developing out the auth plugins further.

[greenpau]

Do you have any pointer or ideas for how the auth things should work?

@wader , there will be login-type (was thinking naming it caddy-auth-login of a plugin, where user can submit username/password and authenticate against some user store. Upon successful authentication, a user will be issues a JWT token.

For example, caddy-auth-saml redirect a user to Azure portal for authentication, then validates SAML assertion it gets back, and sets the following token: https://github.com/greenpau/caddy-auth-saml#jwt-token

That's the end of login-type of a plugin.

Subsequent requests get intercepted by another "authentication" plugin, which is more of "authorization". It checks the validity of passed credentials (e.g. tokens, headers (incl. cookies), and grants a user access to a resource.

I am in the middle of the development on it https://github.com/greenpau/caddy-auth-jwt

Hope this clarifies.

[mholt]

Thanks @greenpau

To clarify, more than just JWT will be available, e.g. basicauth will continue to be supported too. The basic idea is that you put the auth handler before whatever it is you're trying to protect.

[greenpau]

To clarify, more than just JWT will be available,

@mholt , absolutely! :+1: I actually never done SSPI/Kerberos Interoperability with GSSAPI development. Excited to get to it!