@bun - okay, things are working, though
@bun - okay, things are working, though I haven't properly tested all the expires stuff and whatnot... and again, I do plan to move all this into a full proof-of-concept repo with working demo etc. Anyway, some stuff in 🧵 ....
13 Replies
ok so first off, the part you're interested in, the durable object itself.
the high level ideas are:
1. the id is always unique
2. there is always a random key value set (not strictly necessary in all flows, but, doesn't hurt)
3. the DO always cleans itself up - only question is after how long and if it allows extending the expirey
This is used for auth sessions and out-of-band "magic link" sortof things (reset password, verify email address, etc.)
Some of this will be a repeat when I copy/paste all the notes...
the frontend side pretty much just does what it says in the notes... it must attach the signin session key in the header, the signin session id comes along via cookies, etc.
oh, of course there's a missing piece here which is the database (D1) - which stores the
user-token that's expected in the durable object.
The idea with that is really just to implement "sign out everywhere" / "invalidate all sessions for this user"
Not a must imho, but, it almost comes for free with this architecture since I'm hitting the DB to check if the email is validated anywaywait so why are you not using user id as id for the DO @dakom ?
@dakom
Because there's a one-to-many mapping of users to auth tokens, i.e. a single user may be logged in on their browser, phone, etc. simultaneously
in an earlier design I was doing it that way - and then looking up each of the different tokens via an internal storage key, but I think this redesign is much cleaner
so you can have those multiple tokens in a single DO, whats the issue?
it makes the expirey stuff messy - imagine that they are active on their browser session, but their phone session has inactive/expired
much simpler to just have each DO instance organically expire, than to have to check sub-keys and storages in the alarm handler
ahhh right
tbh it sucks you cant make alarms with like specific params
would make session invalidation much easier
I think you can effectively do that by having the alarm check for some keys... but tbh I did start going down that road and it felt just a bit icky
not saying it can't be done cleaner, but for my personal attempts, this approach ended up more to my taste
(but that could just be because I gave up on the other approach and didn't spend enough time trying to make it nice... you may have better luck!)
also are you sure rust wasm is much more perfomant than JS in cloudflare workers context?
oh I'm quite sure that rust wasm is less performant than JS in many flows, especially if it's mostly just shuffling data back and forth between D1/DO/etc.
but - it's a negligible difference either way. It's the advantages of the language and being able to reason about my data structures and code that's worth it for me