I’m working on a mobile project with the sync gateway.
Everything works fine but I’ve got one crucial question about the admin rest API.
It’s something like a chat application, but in my case, using a ‘members’ field in the docs to use an access() or role() in the sync function is a security hole.
So when a ‘chatroom’ is created or updated, I trigger a web hook event to my app server, that does a change in user channels and roles to give access. This change depends from another database.
So my question ?
What happens if several concurrent modifications (read and add something in the admin_channels/roles Array of the user) are made ?
The conflict is easy to handle in the docs with the _rev number, but in the _user/docs, there are no revisions…
process 1 reads user1 roles
process 2 reads user roles
process 1 adds a role in the admin_roles array
process 2 adds a another role in the admin_roles array
process 1 curl the change
process 2 curl the change…
Thank you for your response, it’s really a critical aspect of my app.
You’re correct - there isn’t any concurrency support for the user document operations against the admin REST API.
I can think of three possible options for your use case:
Enhance your app server so that updates for a given user document are single-threaded
Instead of updating the user doc directly, have your app server write a document that triggers an access grant in the sync function.
Review whether the functionality in your app server could be implemented in the Sync Function. What’s your app server doing to add additional write security to the ‘members’ set that can’t be done with things like requireUser/requireRole in the Sync Function?
The use case you’re describing — a change in a chat-room doc that triggers access privileges for users who are members — is literally one of the ‘stories’ that motivated our design of the access() call in the sync function. You shouldn’t need to resort to web-hooks to make this work, not unless there are other complications to it.
@adamf : the idea of creating/updating another document to trigger a grant in the sync function is definitely the best solution for me. Perfect. @jens : In my case, the use of the access function in the ‘chatroom’ means that the list of members is embedded in the doc chatroom. And for security reasons it’s impossible in my application’s case. (this is not really a chat application, that’s what just a model I used to explain my original problem)
I wanted to be sure that there’s no possible conflict resolution for the _user and _role doc.