cloudworker-proxy
cloudworker-proxy copied to clipboard
markusahlstrand
Pluggable KvStorage service
Sorry if this has already been addressed, but we're looking into using this proxy to handle oauth on our workers, and our only concern is that the REST API is used for KV storage. We'd prefer to use the binding API since that seems to be the recommended way to access workers, and requires fewer secrets to be added to our deployment (no need for kvAuthEmail and kvAuthKey).
An easy way to address this would be to add a kvStorage option to each of the handlers that requires KV, and allow users to provide their own implementation. This way, we could write a simple KV storage layer ourselves using whichever API we choose. Would be happy to PR this if that sounds like a good design, also open to alternative ways to address this!
Hi @pzuraq and sorry for the late reply!
It would be great if you would like to do a PR for this. I haven't used this functionality in a while, so it might need some love.
I'm thinking about doing a revamp of this project with a few changes. As someone suggested I think it would make sense to break out the handlers to a separate project and maybe just keep the very basic in the base project.
Another interesting option would be to use the new durable objects. Think that would avoid the risk of getting stale data if you hit multiple edge nodes..
We actually ended up deciding to go with a solution based on node-openid-client given how complex OAuth is, we really wanted to be sure we were using a rock solid solution there. We did have to fork to make it compatible with Cloudflare Workers, but the diff was relatively minor so we were comfortable with that.
We also ended up deciding to integrate the authentication directly into SvelteKit, which is our client framework and renders inside workers. Doing it this way means we can expose session information directly to our SSR app, which is really helpful for making sure that the app is rendered in the correct state.
If was gonna bank on a serverside oauth implementation these days its would be https://lucia-auth.com/
Also to use the binging API the module needs to be ESM I believe, so this issue is a blocker https://github.com/markusahlstrand/cloudworker-proxy/issues/133
We ended up updating to oauth4webapi: https://github.com/panva/oauth4webapi
It's been suiting our needs well.