| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
| |
it doesn't hurt anything even though it's not super necessary for plain
logins, and it's more convenient to access without needing to
deconstruct the enum value
|
| |
|
|
|
|
|
| |
i can't exchange refresh tokens for access tokens without knowing the
webface oauth configuration either, so this strategy also won't work.
the server actually needs to only receive access tokens, and request the
web server to refresh them as needed.
|
| |
|
|
|
|
| |
the server needs the access token to use for the current login process,
but it'll also need to store the refresh token so that it doesn't need
to re-login afterwards
|
| |
|
|
|
|
|
|
|
|
| |
the local client needs to receive the code and send it directly to the
server, which handles the rest of the oauth flow (because the client
doesn't have the server's oauth configuration, so it can't do the
exchange itself), but the web client needs to receive the code and
exchange it for a token and send that token to the server (because the
server doesn't have the web server's oauth configuration, so it can't do
the exchange itself)
|
| |
|
|
|
|
| |
we need to know both who we are (so that the webface can display it) and
also how to log back in as that user (since oauth methods log back in
without specifying the username at all)
|
| | |
|
| |
|
|
|
| |
this should allow us to configure a separate oauth application for tt
web than normal (since the redirect_url needs to be different)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
