What is the problem you are having with rclone?
when doing config of a seafile remote with 2FA, the token is always the same one.
i don't blame rclone because according to the seafile official API docs, i get the exactly same token with a POST to the /api2/auth-token.
so rclone is doing the "right" thing according to the doc, but still, something is wrong.
what rclone does (also the same with a POST request according to seafile API docs):
- get a unique token, same one everytime (2FA enabled).
- can always access with this token.
- this token doesn't show up on the seafile web page (/linked-devices/), which is reasonable, since a special unique never-changed token is not possible to represent a specific device.
while the official clients, both "seafile client" and "seadrive", they behave differently:
- everytime re-login, the token is different (same user, same password).
- this token is on the list of
/linked-devices/, representing the device that has gotten this token.
- if user manually delete / disconnect this device / token, then this token is expired.
- (these two client apps store auth tokens into a sqlite3 db file in plaintext after user logi)
a unique, always same, never expired auth token is a critical security hole. users even cannot delete it manually. although seafile has done this and documented it officially, we should not use it.
What is your rclone version (output from
- os/version: ubuntu 18.04 (64 bit)
- os/kernel: 5.4.0-42-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.16.5
- go/linking: static
- go/tags: none
Which cloud storage system are you using? (eg Google Drive)
Seafile CE v8.0.7
The command you were trying to run (eg
rclone copy /tmp remote:tmp)
Paste command here
The rclone config contents with secrets removed.
Paste config here
A log from the command with the
Paste log here
I would appreciate a little feedback on my answer to your previous post, was it helpful?
(Select as solution, send a heart, a brief comment - anything but silence)
It looks like you also have other rclone community members awaiting feedback too.
I can confirm, from all my tests when I was working on the Seafile backend, that the authorisation token returned is always the same per user. That certainly bothered me as well, but there was no other option.
After the backend was finalised, Seafile version 7.1 introduced the API token concept, which would indeed solve the problem.
I had a quick look at the new APIs, and we need to call new endpoints which are different from the standard endpoints (which are also different from the undocumented API used by the official client. Yes there's a strong lack of consistency in the API).
So actually, there's some non-trivial work involved to make the backend compatible with the two authentication systems. I'll probably work on it at some point, but in the meantime you're welcome to propose a PR
thank you for your hard work.
this "new" lib-token is definitely something demanded, but it's not urge and you can just take it easy.
rclone can just use the token extract from official client app's SQLite db file to access seafile access, which is my practice. it's not hard, the software called "sqlitebrowser" can be used to view those ".db" files.
as for now, the only necessary thing is to put a warning in the doc of rclone's seafile part to let users know the security issue.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.