-
Notifications
You must be signed in to change notification settings - Fork 14
Implement flow for reauthenticating the user to request additional scopes #266
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The latest updates on your projects. Learn more about Vercel for GitHub.
3 Skipped Deployments
|
appUrl: string; | ||
}; | ||
|
||
export const AUTH_SCOPES = "atproto transition:generic"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If everything works correctly in this PR it should just be a matter of deploying the app with new scopes here. This can be done as a followup PR when implementing user email storage.
if (!session) { | ||
redirect("/login?error=You've been logged out. Please log in again."); | ||
} | ||
const result = await signIn({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is successful we should probably delete the old session here. Could just leave it orphaned and let it expire naturally tho.
c0f7df3
to
93770f6
Compare
d095354
to
5465f67
Compare
Split into stacked PRs #272 |
Draft for now because it doesn't work lol. Also will need to split out the database change and merge/migrate that before. Do not be scared by the number of lines changed, this is mostly (+1159 lines) the db migration snapshot 😆
This is the first step in implementing user email storage. Will also lay the groundwork for requesting new scopes when oauth scopes are shipped in atproto.
This involves sending the user back through the Auth flow with the additional scopes attached (including the old ones too)
The way this PR implements this is to store the scopes that the user logs in with in my session database, then when they use the app with different scopes to what we currently require (check in middleware), reauthenticate them as above.
We don't reauthenticate the user without telling them what's happening, they'll be presented with a page (/reauthenticate) beforehand (design still WIP):