A powerful feature of the general NetKernel resource oriented middleware is that endpoints can resolve resources within the request scope of the request which invoked them. This leads to many interesting patterns such as language runtimes.
NKP supports this capability by optionally allowing servers to issue requests back to the invoking client but by default, for security, this is disabled. However within the trusted environment of a datacenter or by carefully structuring your clientside address space enabling it can lead to powerful patterns.
The NKP client may choose to allow remote requests to enter the client-side address space (request scope) by indicating in their configuration...
The standard module provides a number of technologies which you may use to implement sandboxes to constrain the addressable resources accessible to the server-side. Sensible use of these tools mean that admitting access of server-side requests is an acceptable design pattern, with the space entirely constrained to manage any risk of malicious requests from compromised servers.
Placing one or more limiter endppoints in the client-side space ensures that server-originated requests can access only your prescribed range of resources.
In particular placing a very broad limiter as the last endpoint in the client space will guarantee that the server-side requests can only reach the immediate scope of the client request space and cannot go any higher.
Along with the limiter you may use the mapper to alias, hide or completely reroute access to any endpoints contained inside the mapper's space.
Advanced - call us if you need to know the details of this method You can implement your own custom endpoint that filters all requests such that only those for services that you know are part of your application domain are resolved. You would create an NKFEndpoint and implement the onResolve() method.