I’m currently leaning towards having tokens that are used by apps to gain access to an account. That way a user can selectively remove the access to apps if they stop using them… it’s also just a single item of data for apps to store and conceals the actual account credentials from apps.
Each account will still have a user-id and secret, but once created, the user will be able to generate (through a web UI or API) tokens for each application they want to give access. The app will just use this token to log in to FD.
I’ll work on streamlined ways to do this for the scenario where a user already has an account and also for new users.
Not sure what’s possible in AP/Android, but if from the app you open a web page, is it possible for the page to send data back to the app by redirecting to a special URL scheme? If so, a token can be handed back from FD to the app without the user having to copy/paste.
I understand the logic, but as a user I would probably create an account on my laptop. If I then would have to log in there and create a token, it’d be annoying to get it to my phone (either store & sync in a txt file or password manager comment, or type by hand).
Instead, if I have a username and password (what you call secret, I think), I could just log in on AntennaPod quickly using the password manager on my phone (which contains the credentials that I created on my laptop). AntennaPod could then submit those credentials to the API and if correct receive and store the token (not storing username/password) - without the user having to think about complicated strings.
Then (as in the new gpodder.net flow linked above) in the next step the user could give the device a name that is then sent to FD (to help recognise the device when managing the account on web).
And one note to set expectations right: I’m happily discussing here with you and would love to see this implemented, but I’m not a developer so it’d be up to others to actually implement it. And whether they want to depends on interest, time, etc.
I think I’ve not explained what I was thinking very well.
Apps will have 2 options to authenticate:
For most APIs they are equal. But there will be some small restrictions around what can be done with an app token (e.g. they cannot create new tokens, or list or delete other app tokens… but they can delete themselves).
Apps will be able to create their own app tokens if they authenticate using the account-uuid/secret combination or they can be provided with a token by the user. I suspect we’ll see multiple different ways that app builders actually implement this.
The docs will read:
Applications are encouraged to use an access token rather than the account-uuid and account-secret combination. App access tokens should be placed in the X-FeedDirectory-Client-Auth header, or can be passed as a parameter client-app-token . The use of app tokens will mean that apps are isolated from resets of the main accout credentials - the tokens will continue to be valid. As a general rule, apps should not be storing the account-uuid or account-secret
I’ve done the implementation and hope to release in a couple of days once I’ve done some testing.
After a bit longer than I hoped, I’ve deployed a version of feeddirectory.org that implements the app-tokens so that apps do not have to store the account-uuid/secret. The APIs for managing the tokens are:
@tonytamsf@Matth78 Would either of you be interested in turning this into a GitHub issue? @ByteHamster Do you think implementation could benefit from mock-ups, or would/should it look like the new nice gpodder login?
I am about to create an issue for it.
I will keep it simple, so don’t hesitate to tell if what I do need adjustments.
I will edit this post afterward to link to GitHub issue.
Edit : issue 4986 has been created
After thought, @ByteHamster, I am not technical but with the ongoing effort to restructure / modularize code is it ok to add a syncing service ? Or should some indications / informations be added ?
Thanks a lot @Matth78! Maybe it would be good to just add a link to the API specifications of feeddirectory and a note about what it should look like (same as gpodder.net login, as ByteHamster confirmed just above).