Hi,



i would like to have the following scenario:



external server contacts custom endpoint and has the rights to modify all the contents of the collection X (update/add/delete any record from any user)



I think i need a new user for this, lets says custom_user ? But what do i need to configure then, i guess something with the acl property?



I know i can use the master secret for this, but i think it is better to limit the access to only that collection, if possible?



Thanks in advance

Hi!



I have the same problem.



Why do we have to deploy our applications with the master secret inside?



Maybe I didn't understand the security model.



Is it possible to use Rest Api Client passing only user/password without passing the master secret?



Thx!



Bruno

Hi @Jonas‌,



This is quite an unusual thing to try to do. Can you expound on your use case a little more so I can get an idea of what you are trying to achieve?



Thanks

Hi @brunovix‌,



It is highly inadvisable to deploy your application with the master secret inside. You should only be using your app secret. The only functions that require master secret authentication are administrative (eg. user restoration) and we wouldn't expect this to be built into an app that will be exposed to the public.



There is some information on our permissions model here: [http://devcenter.kinvey.com/rest/guides/security](http://devcenter.kinvey.com/rest/guides/security).



What is it you are trying to achieve that you cannot do without using the master secret?

@Pete Basically i use another server which does a special service, which takes more time then the default timeout, so i want to send a request to my server, and once my server is done with its task, update the data in the kinvey data store.



Better thing todo is maybe store that particular dataset on my own server and connect it via an custom endpoint :) but i rather keep all data on kinvey, so that is the reason why i need something like i mentioned.



Thanks

Hi @Jonas‌



Thanks. I see the use-case more clearly now.



Why not hand off the authentication token that the original RPC call was made with to the server that will eventually call RPC again - that way you can also keep the security context that the original call was made with, and as far as Kinvey is concerned the external server is merely acting on behalf of the original user. Does that make sense?



Pete

@pete I've implemented it with another user that connects to a custom endpoint and modifies the data. I thought i needed to add my user to every object in that collection as a writer (in the _acl, because i modify data of other users) but from what i noticed is that, the user can modify all data even if it is not a writer/creator of it?



The collection is private, so i'm not sure if this is the intended behavior?



Thanks for the info though, but it seems to work fine like it is right now ;)

Yes, code executed from within a BL endpoint does not retain the security context that the endpoint was invoked with, and the collectionAccess module does not perform the same security checking that would be happening if you invoked one of the REST endpoints directly.



I'm glad you've got your usecase working.