Wrong user exception not thrown in client code.

I'm using authorization in my couchbase config.

In my config.json, my sync function says this:

if (oldDoc) {
requireUser("importantUser@consultant.com");
}

This does indeed stop un authorized users from updating documents. I see in the sync gateway logging a message that says:

BulkDocs: Doc "eric@consultant.com" --> 403 wrong user (wrong user)

My problem is that I don't get an exception thrown in my client code.
In my Android client code I do something like this:

Document document = getDocumentById(identity.getUser().getId());
properties = document.getProperties();
Map newProperties = new HashMap(properties);
newProperties.put("mySchedule", updatedSchedule);
try {
document.putProperties(newProperties);
} catch (CouchbaseLiteException e) {
status = AddStatus.FAILURE;
}

No exception is thrown on the call to document.putProperties even though the sync function failed with wrong user. Can you tell me how to know a problem occurred in the client code?

I just noticed that document has a method update that takes a DocumentUpdater. Will that help?

Thank you,
Brian

- See more at: http://www.couchbase.com/communities/q-and-a/trouble-authorization-sync-...

1 Answer

« Back to question.

Replication isn't synchronous. There's no direct connection between making a change to your local database and what happens on the server. (Consider that the user could be making the local change while offline. Or that your app might replicate to multiple servers.)

The document change you make on the device is purely local, so it succeeds regardless of what the rules on the server are. At some future point (very soon if the device is online and has an active push replication) the change will get sent to the server. The server may then reject it and send back a 403 to the replicator.

We don't currently have an API for the client to detect individual documents that failed to replicate to the server. Most of the time this happens, it's a bug in the app's validation code rather than an issue that needs to be reported to the user — that is, you should be using the same validation logic on the device as on the server.

In your case, you should be preflighting the change in the local database (perhaps by registering a local validation function) to prevent changes from being made that won't be allowed by the server.

--Jens