#Jottacloud forum code

I don't really do Go language or C#, or Python, but the linked code from rclone looks like Jottacloud 'legacy' plan is going away, whereas their 'standard' plan is their new way. Someone who's tried it can say if user's web flow goes like An Illustrated Guide to OAuth and OpenID Connect. At a code level, the fact that they pass jottacli as the client ID, and don't bother passing the client secret (because secrets are hard to keep with an installed program) is OAuth-flavored too. How we get along with OAuth and oauth-handler code shows Duplicati takes a different approach, using a cloud-resident OAuth confidential client, but (just like rclone), it might be able to do the needed OAuth. I suspect client type is a small factor in its flow. shows how the current Duplicati OAuth services were set up. There's a fairly standard way in the C# code (I think) to interface with the Duplicati OAuth handler to serve as a Jottacloud model. If this can be pulled off, Jottacloud backend would have AuthID which it gives to the OAuth handler which handles token refresh. expired_access_token error from Dropbox short-lived access tokens #4667 describes how Dropbox recently took the refresh token path (breaking Duplicati) instead of a long-lived access token. So there's hope, but the Jottacloud new-way needs to be checked further, and several people may be needed, one for Duplicati and one for the Duplicati OAuth handler.Дuplicati can handle either, so Updated values to match current Dropbox API changed the OAuth handler end, and 2.0.6.101_canary_ did a required client-side change. The latter person has been rarely available, but did help Dropbox, so might help here. Somebody would have to change some GUI screens. I'm not sure who did the original Jottacloud ones. In terms of release, it is not clear if new Beta can be pushed out just for this, but in any case we would want it in a Canary at first.

Jottacloud forum