-
Notifications
You must be signed in to change notification settings - Fork 4
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
Make sure my signout is a real signout #253
Comments
Relates to #248. |
This definitely belongs in v4. |
I should set an expiration time on the cookies, in case people don't actively logout. |
I should make sure there's an expiration date on my non-JWT cookies as well. |
TODO
|
On deleting cookies server-side (set Expires in the past). |
I'm re-prioritizing this ahead of WebSockets. I think I only temporarily put WebSockets ahead of it because I was curious whether the WebSocket connect handler receives cookies. It does. |
I'm still continuing work for this on the 250-ws1 branch for now, though. |
What about users who still have old cookies in their browsers for Passover 2022? |
gh-253 My last build failed when it tried to curl a host of https
Do I even need access and refresh tokens? I'm not delegating authorization like with OAuth2.0. Should I be issuing my own cookie? If I do, what happens when it expires? How about...it's expired, and the person has to log in again. I bet my frontend doesn't handle that course of events (expired cookies of any kind) at all. |
I think a big part of the whole problem around signout, gh-331, etc, is that my frontend is confused about who is signed in. It should, as part of this or any of this batch of Issues:
|
Ugh, what if someone logs in, joins a seder, logs out in another tab, and submits their libs in the tab where they're logged in? |
I should stop sending the id token to the client, and instead associate the identity server-side with the…sub? Id token on the client creates multiple sources of truth. |
The whole login/logout behavior is getting really hard to manage. I think I need to list all the different features I want, how I want it to work. |
I think I do want to move to a passover.lol-generated opaque cookie. Advantages:
I should still, during the cookie-checking process, check back with Cognito to see if the person has deleted their user. |
Side note: maybe the backend auth'd user recordkeeping should be limited to "this email address was this user in these rooms." |
gh-253 Since I'm planning to mess with cookies, I want signin exercised on this dev branch. I may leave these changes to the itest App in place on master, and add a Smoke Action that runs the smoke test every day.
The login cookie should be non-session. |
gh-253 I don't know how to do what the commented-out test here is doing. I don't know how to test that my runXXX Dynamo functions actually set the locals they're supposed to set.
gh-253 This actually tests that, when I have a function like runGet that runs a DynamoDB get(), the locals like dbError and dbData are set.
gh-253 I'm getting a real error on authenticated requests, a db error when trying to get the email.
I'm quite worried about how the front-end will handle expired logins. |
gh-253 We authenticate with the email now, not the sub.
TODO 2022-03-15
|
gh-253 The evaluate happens in the browser, so it doesn't know user2's name unless I pass it in.
gh-253 I started sending more 400s rather than 401s, because the 401 docs say something about you must send instructions on how to authenticate.
gh-253 We’ll get the user info from the URL.
gh-253 I run itest with npx now.
gh-253 The front-end now never interacts with JWTs.
gh-253 The frontend now figures out who is logged in by looking at params sent back after login in the redirected-to URL, not by hitting /id.
I might need to bring back some kind of /id endpoint. If you load a new page after signing in, and you have a valid cookie in your browser, you could be kind of signed in without your UI telling you that you are. This could probably be addressed after web sockets, because you aren't really signed in when this happens. The front end has to affirmatively include the email address in requests, even if there is a valid cookie, for anything to happen on behalf of the user. This appears to be addressed in recent commits, in which I update the state hydration to look for just email and nickname. |
gh-400 is created to handle invalidating the opaque cookie server-side. |
I think I currently have a halfhearted signout, that leaves the cookies in place.
The text was updated successfully, but these errors were encountered: