search

drivly / ctx.do

Context Enrichment API
https://ctx.do
MIT License
6 stars 1 forks source link

Figure out worker-to-worker auth contexts #29

Open nathanclevenger opened 1 year ago

nathanclevenger commented 1 year ago

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 dependencies

sam-lippert commented 1 year ago

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.

nathanclevenger commented 1 year ago

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: @.***>

sam-lippert commented 1 year ago

https://lodash.do/get/zones/map/name/groupBy/split(.).last()/mapValues/map(split(.).first())/api-cf.drivly.workers.dev/zones

sam-lippert commented 1 year ago

@nathanclevenger Why don't we use queues for worker-to-worker communication?

nathanclevenger commented 1 year ago

@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