-
Notifications
You must be signed in to change notification settings - Fork 1
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
Figure out worker-to-worker auth contexts #29
Comments
How should we maintain a list of zones? https://api-cf.drivly.workers.dev/zones lists all current zones and this can be imported into ctx.do, but we'll likely need to create a sync process to keep it updated. Calling the API directly probably isn't an option due to latency. |
I don’t want to introduce any latency - so we probably need to add an array to ctx-do directly. Also for space, we should maybe do an array of sld inside an array of tld … so first do and ly and then apis, and driv inside those …Sent from my iPhoneOn Apr 13, 2023, at 9:36 PM, sam-lippert ***@***.***> wrote:
How should we maintain a list of zones? https://api-cf.drivly.workers.dev/zones lists all current zones and this can be imported into ctx.do, but we'll likely need to create a sync process to keep it updated. Calling the API directly probably isn't an option due to latency.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
@nathanclevenger Why don't we use queues for worker-to-worker communication? |
@sam-lippert I think we can - but it depends on whether the use case is sync or async ... if the caller needs a response to proceed then it needs to be blocking sync, but if the communication doesn't need the result to return it's own response - then it would definitely make sense |
Now that @AggressivelyMeows confirmed that the
cf-worker
header can't be spoofed for incoming traffic, we should use this for authenticating service requests. We should give it a different context, and as a non user role, we shouldn't allow certain permissions things, but this can start to allow us to require auth for many of the .do services ... even ones that have lots of dependenciesThe text was updated successfully, but these errors were encountered: