I've read that Box.com tokens should be good for quite some time (~1month) of non-use.
still, I can see that an account that I opened last week has asked me to refresh my token several times, already. rclone complains as following:
user@host ~$ rclone -vP sync ~/folder BOXREMOTE:folder
Failed to create file system for "BOXREMOTE:folder": failed to make remote
couldn't fetch token - maybe it has expired? - refresh with "rclone config reconnect BOXREMOTE:": oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Refresh token has expired"}
is this normal? I have seen several other threads on similar topics, but I haven't found an answer there.
thanks!
All tokens within Box (access tokens, developer tokens, downscoped tokens) have a 1 hour expiration time, which is done for security to prevent long-lived tokens from floating around.
Access tokens, which they expire after an hour, can be perpetually refreshed using the refresh token, meaning that if the access token expires you can fetch a new valid one without having to go through the entire auth flow again.
I can't speak to how rclone implemented the Box auth, but the above is basically how our systems work. If the token simply expires after an hour then more than likely they're not refreshing the token.
I'm having some trouble understanding the difference between the automatic token refreshing, carried out by rclone under the hood, and the entire oauth re-authorizing, which requires user intervention.
Each refresh token can only be used once to make a new access token.
So if you made a token on your desktop PC then copied the config file to your server, the first one to use the refresh token would win and the other would not be able to generate a new access token.
I'm really sorry, but I'm still having trouble following along.
I have a single rclone configuration with several Box accounts, let's say 3.
each has a different email, password, and each has been authenticated separately via oauth during the automatic config phase.
I can see from the config file that each has a different access_token and a different refresh_token.
I'm using a union remote which is the union of the 3 Box remotes.
still, as I was saying, I am getting constant errors like I reported in my original post, "Refresh token has expired" after commands like rclone about UNION: or rclone sync ~/stuff UNION:.
am I doing something wrong?
I am definitely not "reusing" the Box remote access nor refresh tokens!
I wonder if what is happening is that on startup all 3 tokens need refreshing at once and rclone makes a mess of the config file when saving the 3 responses at once...
A bit of locking in the config file code might fix the issue.
If you try rclone about on the individual remotes before trying the union does it work ok?
great! \o/ ... at least I'm not asking a dumb question.
what do you mean?
not really.
I usually start my "let's work on the backup" work session with a simple script that loops over my remotes and prints out their about information, so I'm effectively running:
rclone about MYBOX1:
rclone about MYBOX2:
rclone about MYBOX3:
usually rclone stops with an error at the first line.
after I reauthorize MYBOX1, then the first about completes successfully but the second about raises the same "token expired" error.
after I reauthorize MYBOX2, then the first two about commands complete, and it's the third command's turn to yield the error.
it's quite frustrating and I'm pretty sure it should not happen!
I'll pay more attention, making sure to run the separate rclone about commands always first, so as to trigger individual token refreshes, but I'm pretty sure there might be a bug in the union remote, somewhere...
if I notice that by doing that (that is, always running the various rclone about first) the subsequent rclone commands on the union succeed, then I'll report here.
still, I'm all ears for any suggestion.
would the debug logs help out in debugging this token mess?
@ncw so far, so good. I've been leading any rclone activity of my union remote with individual rclone about commands on each Box remote -- the token refreshing has been flawless.
I cannot promise that I'll be able to thoroughly reverse engineer the Box/union problems and attach a definitive debug file, but I'll try and keep that in mind.
(I won't close this issue so as to have more time to attach any logs, if needed, before the issue closes.)
still, for more powerful union users, the takeaway seems that:
Can you please make a new issue on github about this with a link to this forum page and I'll think about how to fix the problem. It is going to need some sort of file locking I think which is all horribly OS dependent.