Rcd: disposable shared file link of rclone server

Feature
1

I know rclone can create directly public link, but not all remotes has this feature.
Rclone can use rcd --rc-serve to create a 'fake' (download files from rclone server) shared link for remote files.

But other user must know about --rc-user and --rc-pass.
Considering below situation:

  1. I don't shared the 'administrator' token ( it mean Basic Auth)
  2. Other users can downloads specific remote files only
  3. The 'fake' shared link can be cancel( expired time, or manually disabled by 'administrator')
  4. Other users don't know real path of shared files in rclone server.

rclone server should has some api

  • share/create: create a shared file link of rclone server.

params:

{
  srcFs: string, // a remote name string eg "drive:" for the source
  srcPath: string, // a path within that remote eg "a/b/file.txt" for the source
  token?: string, // (option) average user token, similar with dstFs. if not provided , rclone will auto-generate it. eg "yf62HDvd78"
  sharedName?: string, // (option) similar with dstPath. if not provided, extract it from srcPath. eg "file.txt"
  expired?: moment | duration // (option) expired date. not provided mean unlimited.
}

return

{
  sharedLink: `share/links/${token}/${sharedName}`
}

Nb: average user can directly downloads file ,(no authorization header) by GET method

  • share/list: list current shared link

    no params.
    return

      {
    sharedLinks: {
      srcFs: string,
      srcPath: string,
      token: string,
      sharedName: string,
      expired?: time
    }[]
  }

  • share/delete: deprecate shared links
    params

      {
    // a list of links need to be deprecated
    // providing `srcFs` and `srcPath`
    // or providing `token` and `sharedName`
    sharedLinks: ({
      srcFs: string,
      srcPath: string
    } | {
      token: string,
      sharedName: string,
    })[]
  }

    return none

2

I see what you mean.

This would mean exposing the rc port to the internet wouldn't it.

How would the shared files be stored?

Is this a feature you could work on?

3

Shared files don't need to be stored, they still in their remotes.

For rclone,

  1. get the real path from the shared link table
  2. calls s.serverRemote(w,r, realPath, realRemote) (same as Serve)
    Done

curl http://127.0.0.1:5572/share/links/${token}/${sharedName} -o object

is same as

curl http://user:pass@127.0.0.1:5572/[remote:path]/path/to/object -o object

Only the URL and request header is different!

4

Some remotes hasn't PublicLink feature.
sharedLink can be treated as a temporary replacement of public link for these remotes.

5

No but the tokens do unless they are generated with two way encryption...

So the tokens could be an encrypted version of [remote:path]/path/to/object which rclone decrypts with a secret key that it stores in the config file.

Alternatively the tokens could be an HMAC of [remote:path]/path/to/object and you supply that in the path

curl http://127.0.0.1:5572/share/links/${token}/[remote:path]/path/to/object -o object

Of the tokens could each be a JSON file on the disk with a random UUID name

6

It seems that shared links have "long-term" support, mean that shared links still exist even if rclone server was "restarted".

Before you mentioned the above feature, I just consider that lifecycle of shared links is limited in run-time. If rclone server is shutdown, all shared links are gone.
And my naive solution is that rclone server holds a map table in memory.

(token, sharedName) (srcFs, srcPath, expired)
(foo, a.mp4) (remot1, path/to/object/c, null )
(bar, b.md) (remote2, path/to/object/d, 2020/2/3 )

I don't know if it will raise the security problem. :joy:

By the way, the feature of long-term support is not bad.

7

That is easy anyway!

They could be persistent to disk in files or something like that.

:slight_smile:

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.