I have a collection called "Invitations". This is a "shared" collection - i.e. not set to Private. The collection has custom onPreFetch BL that filters out what is sent back to the requestor based on their _id. This prevents exposing private information to them. It works great.



However, I have a cron on another server that needs ALL the information from this "Invitations" collection. When it queries the collection, it fails because the request has no associated username. By default, the "username" when requesting with the MasterSecret is the same as the appKey. I can't trust this appKey because anyone could have modified their request to use it, right?



To solve this problem, I created a custom endpoint for the cron to query. That works okay. However, now I need to have a custom endpoint for every collection this cron needs to access. Kind of a pain in the rear.



So, I started dabbling with the concept of bypassing the filtering on the onPreFetch method of the collection. Of course, I'd need to know if the user is really authenticated and used the Master Secret. So, my questions?



* Can I assume that if the "request.username" === The App Key, the authentication REALLY is based on the App Key and the Master Secret and that a user has not spoofed it somehow?



* If not, is there some other way in the onPreFetch BL to be certain that the request is really coming from my script with a Master Key?



Please advise.



Thanks,

Justin

Okay, I THINK I've confirmed this. However, I'd really like an official response from Kinvey when y'all can.



I used PostMan to put a "username" parameter in the Header of my request. It does carry through to the request. However, it stays inside the "request.headers".



So, I THINK that Kinvey puts the "username" in the actual "request" section based on the authentication. So, I THINK it is safe to assume that if "request.username" === APP KEY, then it is safe to consider this root access.



I'd really appreciate a confirmation.



Thanks,

Justin

"request.username" === APP KEY is ok for me too.

request.username === APP KEY should *almost always* work.



The wrinkle is that when the request is made with App Secret, request.username will also be APP KEY. (Requests made with those secrets take Basic Auth format appKey:appSecret or appKey:masterSecret and we put the appKey in request.username as you found). I saw almost always, because the App Secret is only used for initial user creation, or POST (before-save) to 'user'. For any other requests your assumption is completely safe, because if the App Secret is (erroneously) used there, the request will fail authentication and won't even reach Business Logic.



This is not good enough and confusing, though, so we'll add a property to request or modules.backendContext.

We added modules.backendContext. getSecurityContext() which directly answers the question



See http://devcenter.kinvey.com/reference/business-logic/reference.html#backendcontext-module