I have a SQL Worklight Adapter with procedures that should not be exposed to anything except my http Worklight Adapter. I cannot have the procedures as private functions in the http adapter since you cannot mix SQL calls and HTTP calls in the same adapter.
I have considered defining a security test to only let invocations coming from the server use it, is there a secure way to do this? Is there any other approach I should use?
I use Worklight 6.2.0 CLI version.
You could use a "poor-man's" security approach, code all your DB adapters to take an extra parameter, require that parameter to take some value that only the server can supply.
Using a security-test can surely be made to work, I'm just not sure how much work it will be. So far as I know you don't have the ability on the server to install a ChallengeHandler, and hence use the simple authentication patterns in the tutorials. So I think you'd be into writing your own Realm.
My question would be whether there is real value in doing this. Suppose instead you just protected all your adapter procedures with the same security test (and that's much easier because the standard ChallengeHandler patterns work because the procedure client is in the WL.CLient space). Now only clients authorised to use the HTTP adapters can use the SQL adapters. What extra privilege have they gained by going direct to the SQL adapter? If you are doing some additional security checks in the HTTP adapter perhaps this needs refactoring into the security layer or some common functions.