Added support for Jottacloud cli token

[albertony]

Jottacloud used to support basic username/password authentication, but this was recently discontinued, while re-enabled for a limited time until June 1st 2022 after request from Duplicati users.

The new authentication in Jottacloud is based on OAuth and OpenID Connect. It does not use regular OAuth workflow, with redirect to login with callback etc. Instead, users have to manually log in to the official web gui and generate what they call a "Personal Login token" ("Generate a personal login token to log in to the Jottacloud Command-Line Tool"). This single-use token contains a username and password that can then be used as basic authentication to request a real OAuth token.

This PR adds Jottacloud as a provider. The login button leads to a new page showing a simple input box for the user to manually enter a "Personal Login Token". This is then used to request a OAuth token. Finally this is hooked into the same logic as the existing providers: Saving the token, generate authid, show the logged-in page.

Some question marks:

• I have called it "CLI Token" in the code, currently. Not sure if that is the best name for it... OpenID has something called "ID Token", but I can't really get it to match what the Jottacloud token contains. Other services have something called "Personal Access Token". I ended up naming it "CLI Token" to avoid the confusion of using some name from a standard that is not really followed.

• I was a bit unsure about the fetch token logic; is it correct to do the following in the CliTokenLoginHandler:

  fetchtoken = dbmodel.create_fetch_token(resp)
  
  # If this was part of a polling request, signal completion
  dbmodel.update_fetch_token(fetchtoken, authid)
  

• What is the significance of the user_id? It is not part of the token returned from Jottacloud, so it will be stored as N/A in oauth service. What is the effect of this? We do have the real username included in the login token, so we could use that if it is beneficial in any way..

• Developer tested, but more real user/beta-testing would be nice (was asked for in forum, but not sure if anyone actually did the effort). First of all I have done manual testing of the web gui / rest api of the service itself. Then @jthall put a lot of effort into testing it with Duplicati, as discussed in the issue, successfully (after a couple of patches, mentioned in additional comments to this pr) running Duplicati against the oauth service running in a local python environment. Later, also described in comment on the issue, it was deployed to Google App Engine (at a custom/unofficial url) and then tested with Duplicati connecting to it, which also seem to work fine.

See:

• Jottacloud removed basic authentication, Duplicati can no longer connect duplicati#4697
• https://forum.duplicati.com/t/jottacloud-error-401-unauthorized/3929

[albertony]

Pushed some small tweaks after performing some more manual testing:

• Styling of input field for cli token, and also authid in existing revoke page to make it consistent:
  • Bootstrap style, like the other page elements.
  • Wider (100% of parent by default when using bootstrap style), so that more of the token/authid is visible.
  • Marked as required in the form, i.e. must have non-zero input for the button to trigger.
• Error handling when processing the cli token:
  • Since this new cli token handling for Jottacloud is a process with several manual steps (users must themselves log in to a separate website, generate the token, copy it, and paste it into the appropriate field in the oauth handler site) there is a chance of user error that would only be reported as "Server error, close window and try again".
  • Now indicating if token was invalid, i.e. not valid base64 or not valid json after decoding base64. E.g. user copy-pasted some text other than the token.
  • Now indicating if HTTP Error 401 (Unauthorized) occured when requesting a oauth token using the cli token. This can easily happen if the user tries to use a cli token that has already been used before.

[albertony]

Pushed a bugfix reported by @jthall in the related issue: Jottacloud returns the personal login token with base64 encoding in "dialect": raw (as in no padding) and urlsafe (as in "-" used instead of "+", and "_" used instead of "/").

[albertony]

Pushed another fix after feedback by @jthall: Using space delimited scope value "openid offline_access" according to standard, instead of plus delimited (which will be encoded into %2B) like rclone did ("offline_access+openid").

[kenkendk]

Great work @albertony

[kenkendk]

I have now deployed a version that supports Jottacloud using the CLI token

[albertony]

@kenkendk, I don't know if you considered these two things I was uncertain about, and if you can tell me a bit about them: What is the "fetchtoken", and is it relevant for the Jottacloud/CLIToken logic? And what is the significance of the user_id?

I was a bit unsure about the fetch token logic; is it correct to do the following in the CliTokenLoginHandler:

fetchtoken = dbmodel.create_fetch_token(resp)

# If this was part of a polling request, signal completion
dbmodel.update_fetch_token(fetchtoken, authid)

What is the significance of the user_id? It is not part of the token returned from Jottacloud, so it will be stored as N/A in > oauth service. What is the effect of this? We do have the real username included in the login token, so we could use that if it is beneficial in any way..

[albertony]

Regarding the fetch_token, I think I found the answer myself. Included a fix for this PR #10.

Still wondering about the user_id..