Implementation of alternate auth mechanism for serving files through rclone

Dev Discussions
1

Hey everyone,

The rclone web-gui struggles from many problems due to the current HTTP authentication system being used for authenticating served from the rclone.
The web-gui depends on this mechanism to authenticate with the rclone server. But according to the Mozilla documentation, this is deprecated. https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication#Access_using_credentials_in_the_URL . And hence, causing a lot of problems like multiple login windows.

The alternative can be something a token-based system like the one used in the jupyter notebook (python) authentication here. What we could do, is provide this mechanism for serving GUI files, which should ensure that:

  1. A user could use a token to log in automatically on the localhost.
  2. For a remote user, he should be able to use a username and a password to log in.

I have very little experience with the server-side of things and would appreciate it if someone could help me with that. I would take up the task in the GUI side of things.

2

When you do an http request with username/password it gets converted into an Authorization header in basic auth

So the simplest thing would be to allow rclone to pass the username/password as GET parameters when we open the browser which we do already as the login_token.

We could replace username/password with an opaque token but it will be the same scheme fundamentally.

Is that your proposal?

3

That makes sense. We could open up a login link which will take username/password as GET parameters and then redirect to the main page.

4

Aren't we doing something a bit like this here: https://github.com/rclone/rclone/blob/0d10640aaaf93291a1e0f942a7b71ba7077cd72e/fs/rc/rcserver/rcserver.go#L97

5

Ahh yes. But the token is not yet available to read till the page loads and the page requires the token to load, thus a chicken and egg problem.

6

If the username password gets parsed through the url, we get through, otherwise, we see an error. And after refresh it somehow manages to get the token.

7

Ah.... I see!

Solving this issue would fix that wouldn't it?

8

Yes. That would help.

9

So if we serve the static files without auth then the initial fetch should be OK without auth. The app can then grab the token from the URL parameter and it is away.

I'm just trying to think if serving just the static files without auth

  • is enough
  • introduces any security problems

Thoughts?

10

We could serve the files without any problem if nothing else is exposed in the process. This should be enough to solve the problem.

1 Like
11

Great! I didn't understand the problem until you broke it down for me above - thanks :slight_smile:

12

I am happy that I could help :slight_smile: .

13

I am trying to fix it. Will submit a PR.

14

I have submitted a PR. Please verify if I have done it right. :slight_smile:

1 Like