joepio
commented
2 years ago This problem seems interesting and difficult. Let's look at some approaches. We'll name the server holding the cached resources the Cacher and the other server the Source.
Cacher never downloads non-public resources
This is currently the case. (which means this issue is not a concern right now) It works, but it limits what the Cacher can do with external data. In practice, this means that the Client (browser client) always has to fetch data from the source itself, making it impossible to cache it in the Cacher.
Cacher performs authorization checks for external resources
Similar to how regular collections are implemented, the Cacher perform authorization checks on each resource for the user making the request before sending it.
- Performance hit that can be big if the Source has a complex / deeply nested structure for determining authorization
- Fails when the Source has different logic / rules / plugins to determine authorization.
I don't think this approach will suffice.
Cached resources are only shown to the Pod owner
Collections can simply skip all non-local resources if anyone else but the owner is making the request. Severely limits what you can do, such as when a team is using one Server.
Whenever the server requires an external resource, it will save it to the store which helps to keep it fast (especially for Properties).
As of now, all these resources are also available in collections (when you pass a query param). This means external resources are public, too. Since currenlty all atomic resources are public anyway, this is not a problem. But if Servers, for any reason, could access private data, this could be a possible leak.
See authentication #13