WIP: Initial support for refresh tokens #448

Draft

FenTiger wants to merge 1 commit from FenTiger/refresh-token into master

FenTiger commented

2025-02-23 17:10:30 +01:00

(Migrated from github.com)

I made a crude start on #447. It roughly "Works For Me (TM)", but it has some problems:

It only knows about IndieAuth. It doesn't support any of the other auth methods. This should be fixed; Mastodon is planning to add refresh tokens (https://github.com/mastodon/mastodon/issues/26838, https://github.com/mastodon/mastodon/pull/27948) though it probably won't happen quickly.
If there's no refresh_token then ideally we should send the user back through the OAuth flow from the beginning. I started looking at this, but this will mean rearranging AuthActivity.java so that the flow can be started by triggering an intent or something, rather than only when the user clicks on the "Sign In" button.
Calling into AccountManager from HTTPRequest.java feels like a bit of a layering violation. Is there a clearer way to structure things without too much refactoring?
We could save a round-trip in many situations by paying attention to the token's expires_in value and refreshing automatically when we know it's expired, rather than relying on the server to tell us when we need to refresh.
Applying the new TokenRetryPolicy to the requests that AuthActivity.java issues feels kind of circular. I don't think this will break anything, but I'm not entirely certain.

I made a crude start on #447. It roughly "Works For Me (TM)", but it has some problems: * It only knows about IndieAuth. It doesn't support any of the other auth methods. This should be fixed; Mastodon is planning to add refresh tokens (https://github.com/mastodon/mastodon/issues/26838, https://github.com/mastodon/mastodon/pull/27948) though it probably won't happen quickly. * If there's no `refresh_token` then ideally we should send the user back through the OAuth flow from the beginning. I started looking at this, but this will mean rearranging AuthActivity.java so that the flow can be started by triggering an intent or something, rather than only when the user clicks on the "Sign In" button. * Calling into AccountManager from HTTPRequest.java feels like a bit of a layering violation. Is there a clearer way to structure things without too much refactoring? * We could save a round-trip in many situations by paying attention to the token's `expires_in` value and refreshing automatically when we know it's expired, rather than relying on the server to tell us when we need to refresh. * Applying the new `TokenRetryPolicy` to the requests that `AuthActivity.java` issues feels kind of circular. I don't _think_ this will break anything, but I'm not entirely certain.

This pull request is marked as a work in progress.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin FenTiger/refresh-token:FenTiger/refresh-token

git switch FenTiger/refresh-token

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch master

git merge --no-ff FenTiger/refresh-token

git switch FenTiger/refresh-token

git rebase master

git switch master

git merge --ff-only FenTiger/refresh-token

git switch FenTiger/refresh-token

git rebase master

git switch master

git merge --no-ff FenTiger/refresh-token

git switch master

git merge --squash FenTiger/refresh-token