protondrive: re-read stored credentials before refreshing so a second Fs can't break login - #9881

Thank you for this and for the analysis in #9880.

However I think the fix could be improved. We hit exactly this problem years ago with the OAuth backends and the fix we settled on is in lib/oauthutil - see reReadToken(). The idea is simple, when a token needs refreshing, first re-read the config in case something else (another Fs in this process, or another rclone process entirely) has already rotated it. If the config holds a newer token, adopt it and carry on. Only if it doesn't do we do our own refresh.

That approach has two advantages over sharing one session per remote name:

1. It covers multiple processes as well as multiple Fs objects. A shared session only fixes --backup-dir and friends within one process. An rclone rcd plus a cron job, or two overlapping syncs, still race on the same refresh token and the loser still gets de-authed and wipes the credentials. Re-reading the config (which rclone reloads when the file changes on disk) handles both cases.
2. It doesn't need a process-wide session cache, which brings its own lifecycle problems - Disconnect on one Fs logging out the client every other Fs holds, or two Fs with different options such as replace_existing_draft silently sharing whichever client happened to be built first.

The reason this needs to go a little deeper than the backend is that go-proton-api's Client.authRefresh keeps the refresh token private and has no hook before it refreshes, so the losing client can't recover once its token has been spent. But github.com/rclone/go-proton-api is our fork, so we can add one. Concretely:

In go-proton-api (client.go), add an optional hook, e.g. AddAuthRefreshHook(func() (uid, acc, ref string, ok bool)), and in authRefresh:

• Before calling m.authRefresh, call the hook. If it returns a refresh token different from c.ref, adopt the new uid/access/refresh tokens, call the auth handlers, and return nil so the caller retries the request with the fresh access token.
• If our own refresh fails with 400/422, call the hook again before de-authing. If the token has changed adopt it as above; only if nothing newer exists do we run the deauth handlers.

That's roughly 25 lines.

In the backend, register a hook that calls getConfigMap(m), and turn authHandler/deAuthHandler into closures over the Fs's own mapper and salted key pass instead of the _mapper/_saltedKeyPass package globals. That also fixes the "last Fs constructed owns the write-back for every remote" bug you spotted, without needing the authSession struct. The de-auth guard becomes unnecessary because by the time we reach de-auth we have already re-read the config and found nothing newer.

Are you happy to do the go-proton-api and the rclone sides of this?

Thanks for the review. Agreed on all three points, and the "only fixes it in-process" one is the real gap: my nightly runs restic and rclone from the same config, so another process rotating the token is a case I actually hit. I have reworked it your way.

The client is created inside Proton-API-Bridge's common.Login and never exposed, so it took three changes:

• Add an auth refresh hook so clients sharing a session can adopt rotated tokens go-proton-api#10 adds Client.AddAuthRefreshHook. authRefresh calls the hook before refreshing and again if the refresh comes back 400/422; if the hook has a newer refresh token the client adopts it and fires the auth handlers, and it only de-auths when nothing newer exists. Behaviour is unchanged for clients that register no hook.
• Add Config.AuthRefreshHook so clients can adopt rotated session tokens Proton-API-Bridge#9 adds Config.AuthRefreshHook and registers it right after the client is created on both login paths.
• This PR (force-pushed) drops the shared-session code. The hook is a closure that re-reads the config, and the handlers close over each Fs's config instead of the package globals. Disconnect is back to unchanged.

Tested with local replace directives that are not committed: go build ./... and make quicktest here, the full -race suites in both libraries, and new tests against the go-proton-api fake server for adopt-before-refresh, recover-after-rejected-refresh, still-de-auth-when-revoked, and a two-client control. Details are in the updated description.

Once the two library PRs are tagged I will bump go.mod here. Happy to reorder or squash however you prefer.

I’ve now tested this against a real Proton Drive account, using a separate folder for all test files.

The login fix worked in the live check: one client refreshed the login, and a second client picked up the new credentials without getting logged out. I triggered the refresh deliberately rather than waiting for the login to expire. This did not test two separate processes running at the same time.

The backup-folder sync tests passed too. The broader file tests needed a few follow-ups:

• Some took longer than the time allowed, so I ran the unfinished tests separately.
• A test deliberately interrupted an upload and left a draft behind. Allowing that draft to be replaced let the backend tests pass. I enabled that setting only for the test run.
• One upload lost its connection and then retried with an empty body. The test passed on a later run, but that first failure is still worth tracking.

All selected file tests now have a passing result or a normal skip, across those runs. I removed the test folder afterward.

I tested the three proposed changes together locally. GitHub still needs the supporting library changes to be released before I can update this PR to use them. Could you review go-proton-api#10 and Proton-API-Bridge#9 when convenient? Once they’re released, I can update the dependencies here and check GitHub’s results.