i just realized this could be used as a
i just realized this could be used as a centralized auth server no? have an array of allowed service names (for the stub) and voila
anyways i should probably add docs on better-auth for this. no more d1 just for auth
17 Replies
not sure i have context on what the service names/sub are
but yeah it does seem a bit heavy to have an auth db in every DO
when there's likely just gonna be one row in it
*stub sorry
you mean an array of authorized stub ids?
basically yes
yeah
i was thinking about this the other day, i think the DOs themselves should have no knowledge of any auth
just call them in an authenticated context
i'm about to implement this actually, shipping an agent to my app that users can spin up, i'll just keep a record of
users_agents
with user_ids and the DO stub ids and do my authorization that waywas actually considering this too lol
how exactly do you mean this?
like i think the DO itself should just run without any context of auth
auth just happens before
oh as in the client does worker -> DO and the worker decides if you are allowed or not
yeah
yea thats how my current Ai app works too
Weird I was about to tackle this exact same scenario with worker and DO and better auth and i was thinking pretty much the same : the worker should manage auth then allow or block DO calls. I however may need to pass a permissions object to the DO to manage granular level actions on the DO end though. Thanks for sharing your discoveries and experiments !
Yea most likely smarter. this was my simple solution to it
This deserves a live pic of my red cat blocking me from coding.

relatable

No fuckin way, they are all the same loll. And I am a svelte fan too. You clone haha !!

no orange but also cat-blocked