Don't ignore `--private-repos` when `--no-auth` is used

[zroug]

Output of rest-server --version

rest-server 0.10.0 compiled with go1.15.2 on linux/amd64

What should rest-server do differently?

It should still check whether username and path match, when flags --no-auth and --private-repos are used simultaneously. I think that essentially means omitting !s.NoAuth here:

rest-server/handlers.go

Line 70 in 421da62

if !s.NoAuth && s.PrivateRepos {

What are you trying to do? What is your use case?

This change would allow me to use a reverse proxy for authentication and still use --private-repos. I could use this to work around issues like #70, #73 or #111 more easily.

Did rest-server help you today? Did it make you happy in any way?

Yes, I especially like the append only mode and the stateless simplicity.

[wojas]

It would require a bit more work to support this. We currently have no username to compare to when auth is disabled, username will always be an empty string (see checkAuth). I guess we could just read the username part of the Basic auth, but not check the password.

Would the Basic auth header be set by the check on your reverse proxy?

[zroug]

You are right, my reverse proxy sets an additional header with the user name. I didn't realize that this header is not part of the basic auth header.
I probably could get the proxy to send a fake Authorization header but I think it would be much cleaner to specify a header to trust the username from. That makes it a bit more complicated, but maybe --no-auth could have an optional argument to specify a trusted header that contains the user name?

[rawtaz]

What reverse proxy are you using, how is the authentication between your restic client and the proxy performed, and what is the normal way for the proxy to signal to the backend that the user is authenticated?

[zroug]

I'm using Traefik​ as a reverse proxy. Right now Traefik is not authenticating the the clients, this is done by restic rest server at the moment. I would like to instead use Traefik to authenticate the users using ForwardAuth (https://doc.traefik.io/traefik/v2.0/middlewares/forwardauth/), so that we can have a single user database. The backend would not receive any not authenticated requests. A header that contains the user name would be added to authenticated requests.

[wojas]

I have seen similar things before. I agree that adding something like --trusted-username-header would be the best solution.

[MichaelEischer]

Wouldn't it be easier to just let the reverse proxy check that the username and path prefix match? Since #112 all --private-repos does is verify that the first part of the pathname matches the username. The option is no longer necessary to provide subrepositories.

[wojas]

Wouldn't it be easier to just let the reverse proxy check that the username and path prefix match? Since #112 all --private-repos does is verify that the first part of the pathname matches the username. The option is no longer necessary to provide subrepositories.

Maybe, but #117 shows the risks of having two different components try to interpret the request path.

#140 also allows giving specific users additional permissions, which would not work in combination with a check on the proxy level.

[GeorgFoc]

I stumbeled over this problem as well (I use nginx).
What I would expect would be something like this:

Internet --https-->proxy/lb --http-->rest-server

So normal TLS Termination. I found, that the current SSL Ciphers are week, and I cannot change them.

For TLS Termination working correctly, the Rest-Server should Respect the X-Forwarded-Proto Header, to know, that the client talks https, but the requests comes through http.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-Proto

This would be enough for me. Basic Auth would still work, because the Authorization Header could also be proxied, as far as I understand.

Also nice would be a health endpoint like /healthz with only response with http 200 if the Rest-Server is healthy.

[MichaelEischer]

@GeorgFoc Basic-Auth at rest-server also works without enabling TLS. So, I don't understand what you need the X-Forwarded-Proto header for.

[GeorgFoc]

@MichaelEischer
Yes you are right. I'm sorry. I touched to many systems yesterday and was unconcentrated. TLS Terminations works just finde.