requireUser not working for me

[Brian Hardy]

requireUser not working for me

I authenticate using persona and I see a message in the sync gateway logs that confirms I’m authenticated as user bs...@gmx.com

My sync function reads like this:
"sync": `function(doc, oldDoc) {
    channel(doc.channels);
    if (doc.type == "user") {
        channel("profiles");
        requireUser(["Admin", "bs...@gmx.com"]);
    }
}`

I keep getting a "wrong user" message and cannot update data on my server. I'm not sure what I'm doing wrong.

Here is the log output from sync gateway.

22:59:52.475176 HTTP:  #368: POST /bsg_sync/_persona

22:59:52.585914 Persona: Verifying assertion "eyJhbGciOiJSUzI1NiJ9.eyJwdWJsaWMta2V5Ijp7ImFsZ29yaXRobSI6IkRTIiwieSI6IjI4NGRlYjM2ZWZjYWVjOGEwNjUyMzU0Mjc2MTVjNDg3ZmZmODZkNjFhNDI4MTYwY2Y4MDYzMThhYzk0NmNhNmM2NmYwYzk3Yzc1ZjYzMTBjMjFlMjcwNGI3MTRkMDc1ZWZmNWQ1NTk0YjQ4YzZiNmFjM2Y5ZmQ5MTZiYTk0NDE0OGZjOTYxNmM2NGQ5NDVkNWU5MzU4YzcyZWFkZjcxOTU5MjI5MWM1MjFjMTg4MDkzZTljOTA5MWIyOThlN2IwYjE2MDU5NjZiZmQ1MDY2NGIyYmM4NDEyMWNkNGRiZDI1ODQ2MzM0NTVkZDgyM2Q1MTAxOGM1YjI3YzVjY2UwNzMiLCJwIjoiZmY2MDA0ODNkYjZhYmZjNWI0NWVhYjc4NTk0YjM1MzNkNTUwZDlmMWJmMmE5OTJhN2E4ZGFhNmRjMzRmODA0NWFkNGU2ZTBjNDI5ZDMzNGVlZWFhZWZkN2UyM2Q0ODEwYmUwMGU0Y2MxNDkyY2JhMzI1YmE4MWZmMmQ1YTViMzA1YThkMTdlYjNiZjRhMDZhMzQ5ZDM5MmUwMGQzMjk3NDRhNTE3OTM4MDM0NGU4MmExOGM0NzkzMzQzOGY4OTFlMjJhZWVmODEyZDY5YzhmNzVlMzI2Y2I3MGVhMDAwYzNmNzc2ZGZkYmQ2MDQ2MzhjMmVmNzE3ZmMyNmQwMmUxNyIsInEiOiJlMjFlMDRmOTExZDFlZDc5OTEwMDhlY2FhYjNiZjc3NTk4NDMwOWMzIiwiZyI6ImM1MmE0YTBmZjNiN2U2MWZkZjE4NjdjZTg0MTM4MzY5YTYxNTRmNGFmYTkyOTY2ZTNjODI3ZTI1Y2ZhNmNmNTA4YjkwZTVkZTQxOWUxMzM3ZTA3YTJlOWUyYTNjZDVkZWE3MDRkMTc1ZjhlYmY2YWYzOTdkNjllMTEwYjk2YWZiMTdjN2EwMzI1OTMyOWU0ODI5YjBkMDNiYmM3ODk2YjE1YjRhZGU1M2UxMzA4NThjYzM0ZDk2MjY5YWE4OTA0MWY0MDkxMzZjNzI0MmEzODg5NWM5ZDViY2NhZDRmMzg5YWYxZDdhNGJkMTM5OGJkMDcyZGZmYTg5NjIzMzM5N2EifSwicHJpbmNpcGFsIjp7ImVtYWlsIjoiYnNnMkBnbXguY29tIn0sImlhdCI6MTM5ODIwNzU5MTg3NSwiZXhwIjoxMzk4MjExMTkxODc1LCJpc3MiOiJsb2dpbi5wZXJzb25hLm9yZyJ9.Mz-IETr3N-WJhEcRwzyvI0o9yz0PQabclpOyeBG7aQf-3h0rmx3-opB___DaRX4I7QdD4gpi27sHeFLgGBstRRRcYju2xttuARi1UswKcyxKNiM7y_MaiX9jUJiNm1oGGzq5tAmHlzj6PO5cPmE2HJkHHXbsj_dWHrsjafWgH41GAt8MuQjTZSFHTUCeSrq4uqE4_e3R-XHChG-um61Ab5uJ4n71IYBtbZrtQwKo6VVisdb_3hDO7KmENmG5vzgI8TA3U5PFxAQGK8LE7iyQZ3tuRYRepVqFG2r8GNdBiR85CdS80T6W_CzvEORjKww-OzjoBZOHlQ0bAnRWLZBHOA~eyJhbGciOiJEUzEyOCJ9.eyJleHAiOjEzOTgyMDc3MTE4NjAsImF1ZCI6Imh0dHA6Ly9lYzItNTQtMjA1LTE1NC0yMDAuY29tcHV0ZS0xLmFtYXpvbmF3cy5jb206NDk4NCJ9.0XAWfQu4cS71oXDHSXYMIxZBWjk9nRlR6p1AqpBGXS7X-blGbGZ6PA" for "http://myserver.com:4984/"

22:59:52.656405 Persona: Logged in "bs...@gmx.com"!

22:59:55.761679 HTTP:  #369: POST /bsg_sync/_revs_diff

22:59:56.069154 HTTP:  #370: POST /bsg_sync/_bulk_docs

22:59:56.070818 CRUD+: Invoking sync on doc "bs...@gmx.com" rev 45-1a60af2e-0f6f-40d3-aab2-4f03f91daf42

22:59:56.071227 Sync fn rejected: new=map[_rev:45-1a60af2e-0f6f-40d3-aab2-4f03f91daf42 mySchedule:[session:1088 session:1087 session:1072] type:user _id:bs...@gmx.com _revisions:map[start:45 ids:[1a60af2e-0f6f-40d3-aab2-4f03f91daf42 4d9b16e1-ee20-458c-9cce-de4d11a219fe 3dec05ef-6c45-4231-9428-3031799da7e2 9ad339fef7aa38b7ab72acb89b01f619 6e89560e-cdc7-4bb6-8488-bc612c205fc8 6de5f6f0-97f0-4257-a74c-fa9d2e294d81 2ed180912d7f3270ee28e82cd4f07d16 0e5aa60e-afba-4d0e-b7dc-e4471c004a00 2b4dd002-b68d-446b-a741-e7a14657eb41 640812e8-0466-442e-bfd7-53c91bbc6361 e71c7609-a4f9-4c0b-b96a-30387cdd55be 13b12e50-655b-4a58-8f0e-17ba3458607f e1cac9f5-1ce5-4354-9049-771a3e7a45e4 8570f6367d747ccfefa3b7cef0fb0614 dc67f05e7b3fb9fb847189d0afbae299 4fc3e75a-6279-43a1-8c8c-7ce68fd5a795 4ea71239-b744-4ae4-93e7-b4638e11049e 88e69867-ae3c-4db8-a3c7-919c585f1894 3d15168e-8277-4dc5-8eeb-ba97919cdcb3 2c80be5ddba15ae404913d2ca69b0000 7e6e9610-2722-4c31-928a-528493dd4820 f8e91ddb-3001-46bf-80f1-e8d7a98e071c 82e61bfb-cbc4-4a0f-a2ab-ca895f60abda 2a5890c1-c51c-4a86-8c1b-c4f190b3bcad 2284c7a2375f425067d202cdf71cfb45 8c762fac-ded6-43dc-a892-e4f49fbf4b56 7115b582-1d14-4830-8dee-5bdc5b03bf6c b636b01d-bb73-47af-a908-9f26a8c25535 fb715bd0-c169-4430-8f1f-0b5304e7098b 435447843442c2b1f66b918d8f8431e4 f6e42c1e-deea-408c-b8ae-3b11f1df4d78 b9cb30dd-d039-4222-ab39-db1adafede29 fe6883c0bcd398b29de1fa2c37cb4375 e6b67a7b-0acd-4f05-bacd-1b2ca3354106 207373a6-69e2-4879-8378-e6dde99a7ab4 2cb1c65b-d3eb-4fc3-9e1f-62e56a46222d 9e71963b-6358-4204-b951-15bf1a1a2ec4 369b08c6717773fe5ca407113bb1ed21 33df2f89-6d80-46de-8961-c3bfbfe4fea1 78fda554-38b6-47f8-8287-76397e0fcd6d b5e0cf62-03b8-4267-8b82-6fa640d324f9 6260da18-f6fc-411c-a726-a8e88a6e3fc1 c446c043-1a3a-4171-9ac7-dcfba5a74fac 9268fbbe-4353-4a8f-b5c7-7a93d4229f51 6b2ffa4a-b1b8-4c03-83b5-4604cb65395b]]]  old={"_id":"bs...@gmx.com","_rev":"44-4d9b16e1-ee20-458c-9cce-de4d11a219fe","mySchedule":["session:1088","session:1087"],"type":"user"} --> wrong user

22:59:56.071259 BulkDocs: Doc "bs...@gmx.com" --> 403 wrong user (wrong user)

I modified the user bs...@gmx.com to have open access as you can see here:

curl -X GET localhost:4985/bsg_sync/_user/bs...@gmx.com

{"name":"bs...@gmx.com","admin_channels":["*"],"all_channels":["*"],"email":"bs...@gmx.com"}

[Jens Alfke]

On Apr 22, 2014, at 5:04 PM, Brian Hardy <brian...@gmail.com> wrote:

> 22:59:52.475176 HTTP: #368: POST /bsg_sync/_persona

> 22:59:52.656405 Persona: Logged in "bs...@gmx.com"!
> 22:59:55.761679 HTTP: #369: POST /bsg_sync/_revs_diff
> 22:59:56.069154 HTTP: #370: POST /bsg_sync/_bulk_docs

The requests sent after the login don’t include a session cookie, so they’re treated as being from the guest user. You can tell because the “HTTP:” log lines don’t end with “(as bs...@gmx.com)”.

This seems like a problem on the client side where the cookie returned from the login isn’t being sent back in subsequent requests. Is the client Android? IIRC there were some bugs in that area. Traun would know for sure.

—Jens

[Brian Hardy]

Thanks.

Yes this is on Android. Do I have to get the session cookie myself and somehow include it in subsequent calls to the sync gateway, or do you believe that is supposed to get handled automatically?

[Brian Hardy]

After using the Persona assertion with the _persona REST endpoint, do I need to re create the Replication using a new URL where the assertion is appended as a query parameter?

   URL replicationUrl = new URL("http://myserver.com:4984/bsg_sync?personaAssertion=" + assertion));
   Database database = getDatabase(databaseName);
   Replication pullReplication = database.createPullReplication(replicationUrl);
   Replication pushReplication = database.createPushReplication(replicationUrl);

Or do I somehow need to specify the session cookie on the Replication after person login?

Thanks

[Jens Alfke]

On Apr 22, 2014, at 6:38 PM, Brian Hardy <brian...@gmail.com> wrote:

After using the Persona assertion with the _persona REST endpoint, do I need to re create the Replication using a new URL where the assertion is appended as a query parameter?

Oh, I see, you’re POSTing to _persona yourself. The situation on Android as I understand it:

• The betas don’t have API to tell the Replication to log in using Persona (this was either checked in very recently, or will be very soon)
• There’s a disconnect in the cookie storage between CBL’s HTTP requests and the ones you make in your own code, so after you do the authentication the cookie isn’t known to CBL’s replicator. (We’re adding API to manually propagate cookies.)

I’ll let Traun or Andy give the detailed answer about what you should do to work around this…

—Jens

[Brian Hardy]

I tried to add the cookie I got back from the _persona endpoint to the Replications with replication.setHeaders(map); Where the map had a header 

"Set-Cookie" with the String value for the cookie I received from the _persona endpoint as the associated header value in the map. That didn't seem to help.

[Brian Hardy]

Ok, I believe I set the cookie on the replications correctly. Now I see in the logs that is does things as user bs...@gmx.com.

However, I still see in the logs it says "wrong user". Strange, but when I look at the document in question it appears to have been updated on the server as I intended but not what I expected since the log says wrong user. Why do you think it still says wrong user?

02:48:12.892316 HTTP:  #181: POST /bsg_sync/_persona

02:48:13.003641 Persona: Verifying assertion "eyJhbGciOiJSUzI1NiJ9.eyJwdWJsaWMta2V5Ijp7ImFsZ29yaXRobSI6IkRTIiwieSI6ImFiNzk0YWE5ZDUyZmY2MjM0ZTAyNjE2NGNiMWY3MDc0YmFlZjBhNmM0MzMxZGQyN2NlMDFlYTVmZjEzZmE5MmRhMmQ2ZjAwOGYwZDdhYWZlYzBmYjQ3MTc3OWIwOWJjYWVjMTI3NDE1OTMwZTg5MDQyYzdlYjJkNGE4ZTljNTE1ZWZjYTA3ODkwZDhmM2M1ZDhhZmZhZTM3NGUxZjUxN2ZiMWU3NWQwOTg1OTRlY2M3ZjA4NjJlOGU2N2Y4YjlmNzE1OGUxNDdjNDE0ODkwY2IyZWE2MjJiYmM1YmMxMmE4OTc1NjQ4ZmM5YmRhZjdmMGIxYjQxOTgwMjZmOWU1ZjAiLCJwIjoiZmY2MDA0ODNkYjZhYmZjNWI0NWVhYjc4NTk0YjM1MzNkNTUwZDlmMWJmMmE5OTJhN2E4ZGFhNmRjMzRmODA0NWFkNGU2ZTBjNDI5ZDMzNGVlZWFhZWZkN2UyM2Q0ODEwYmUwMGU0Y2MxNDkyY2JhMzI1YmE4MWZmMmQ1YTViMzA1YThkMTdlYjNiZjRhMDZhMzQ5ZDM5MmUwMGQzMjk3NDRhNTE3OTM4MDM0NGU4MmExOGM0NzkzMzQzOGY4OTFlMjJhZWVmODEyZDY5YzhmNzVlMzI2Y2I3MGVhMDAwYzNmNzc2ZGZkYmQ2MDQ2MzhjMmVmNzE3ZmMyNmQwMmUxNyIsInEiOiJlMjFlMDRmOTExZDFlZDc5OTEwMDhlY2FhYjNiZjc3NTk4NDMwOWMzIiwiZyI6ImM1MmE0YTBmZjNiN2U2MWZkZjE4NjdjZTg0MTM4MzY5YTYxNTRmNGFmYTkyOTY2ZTNjODI3ZTI1Y2ZhNmNmNTA4YjkwZTVkZTQxOWUxMzM3ZTA3YTJlOWUyYTNjZDVkZWE3MDRkMTc1ZjhlYmY2YWYzOTdkNjllMTEwYjk2YWZiMTdjN2EwMzI1OTMyOWU0ODI5YjBkMDNiYmM3ODk2YjE1YjRhZGU1M2UxMzA4NThjYzM0ZDk2MjY5YWE4OTA0MWY0MDkxMzZjNzI0MmEzODg5NWM5ZDViY2NhZDRmMzg5YWYxZDdhNGJkMTM5OGJkMDcyZGZmYTg5NjIzMzM5N2EifSwicHJpbmNpcGFsIjp7ImVtYWlsIjoiYnNnMkBnbXguY29tIn0sImlhdCI6MTM5ODIyMTI5MjI4MCwiZXhwIjoxMzk4MjI0ODkyMjgwLCJpc3MiOiJsb2dpbi5wZXJzb25hLm9yZyJ9.E_l3j3wWrpIrwSRY_Lsm8_ZtV9DbZInRrjntKcotQdmJmSPUYtKMO7fWjhR1MD3yaHPMnRX5JRa9V6NxfelzrY9MQdPjIBTYI07nvuhErdp6OmUrtRu0fvFKMu9MLsteeRiMyb55t35VPuaDIQOBbYJTTsCsG-DMJY2fwa111ctDEJdDIYBLE23EflaMa3Df9Oz5Cr6kBh5RzWIKLhRvlGI1yaQwZGFM6kU4ijiLqIlevE3s0mp-dYLhVgI0-mJiTfeEU1VvdXGuGmdKceYnWiHeT7HlVFDvcnwq8YyjddV_91geXdWLiMAbBRVL8zFTAIPe03RWPBl-no8LdTBKag~eyJhbGciOiJEUzEyOCJ9.eyJleHAiOjEzOTgyMjE0MTIyMzIsImF1ZCI6Imh0dHA6Ly9lYzItNTQtMjA1LTE1NC0yMDAuY29tcHV0ZS0xLmFtYXpvbmF3cy5jb206NDk4NCJ9.poWHCTLtNR-D2iGP7UDdczPa4AXE_TAyBMuhUt5a1gwoUIzX-owndQ" for "http://myserver.com:4984/"

02:48:13.406276 Persona: Logged in "bs...@gmx.com"!

02:48:13.816967 HTTP:  #182: GET /bsg_sync/_session  (as bs...@gmx.com)

02:48:13.818249 HTTP:  #183: GET /bsg_sync/_session  (as bs...@gmx.com)

02:48:14.007040 HTTP:  #184: GET /bsg_sync/_local/0538fb29d703d5fe65e770a09de275604f6e2faf  (as bs...@gmx.com)

02:48:14.145410 HTTP:  #185: POST /bsg_sync/_revs_diff  (as bs...@gmx.com)

02:48:14.459224 HTTP:  #186: GET /bsg_sync/_changes?feed=longpoll&limit=50&heartbeat=300000&since=*%3A1532  (as bs...@gmx.com)

02:48:14.459344 Changes: MultiChangesFeed({*}, {Since:*:1532 Limit:50 Conflicts:false IncludeDocs:false Wait:true Terminator:0x1921b2a0}) ...

02:48:14.459440 Changes: MultiChangesFeed: channels expand to *:1460 ...

02:48:14.459661 Changes+: Waiting for "bsg_sync"'s count to pass 3

02:48:16.711775 HTTP:  #187: PUT /bsg_sync/_local/12f095b1b648aa1f953eafb30e9673d62c1c8253  (as bs...@gmx.com)

02:48:25.286963 HTTP:  #188: POST /bsg_sync/_revs_diff  (as bs...@gmx.com)

02:48:25.288891 HTTP:  #189: POST /bsg_sync/_revs_diff

02:48:25.599160 HTTP:  #190: POST /bsg_sync/_bulk_docs

02:48:25.604319 CRUD+: Invoking sync on doc "bs...@gmx.com" rev 53-292ffff3-ecc6-4a68-9d3e-e15b200f6bd7

02:48:25.606025 HTTP:  #191: POST /bsg_sync/_bulk_docs  (as bs...@gmx.com)

02:48:25.607583 CRUD+: Invoking sync on doc "bs...@gmx.com" rev 53-292ffff3-ecc6-4a68-9d3e-e15b200f6bd7

02:48:25.745631 Sync fn rejected: new=map[_rev:53-292ffff3-ecc6-4a68-9d3e-e15b200f6bd7 mySchedule:[session:1084] type:profile _id:bs...@gmx.com _revisions:map[start:53 ids:[292ffff3-ecc6-4a68-9d3e-e15b200f6bd7 27f8ecb85a80ccb6ace900891243722b e2ebf1bd-9b33-4068-94e9-0f15392b6cf2 08b43b10-8c45-426e-b92b-65bebdfbeeff 1bb7ee01-6bbe-4632-a7b9-c44d19d36ffd de55adec-fa16-48ac-8db3-dc21de265850 d3d673c2-080a-40f0-91be-9b8207d5d07e 62162b9a-5360-496d-983d-68f2ea5da4cb d2f7e2b8f8a24220054bacc1db1836ab 4d9b16e1-ee20-458c-9cce-de4d11a219fe 3dec05ef-6c45-4231-9428-3031799da7e2 9ad339fef7aa38b7ab72acb89b01f619 6e89560e-cdc7-4bb6-8488-bc612c205fc8 6de5f6f0-97f0-4257-a74c-fa9d2e294d81 2ed180912d7f3270ee28e82cd4f07d16 0e5aa60e-afba-4d0e-b7dc-e4471c004a00 2b4dd002-b68d-446b-a741-e7a14657eb41 640812e8-0466-442e-bfd7-53c91bbc6361 e71c7609-a4f9-4c0b-b96a-30387cdd55be 13b12e50-655b-4a58-8f0e-17ba3458607f e1cac9f5-1ce5-4354-9049-771a3e7a45e4 8570f6367d747ccfefa3b7cef0fb0614 dc67f05e7b3fb9fb847189d0afbae299 4fc3e75a-6279-43a1-8c8c-7ce68fd5a795 4ea71239-b744-4ae4-93e7-b4638e11049e 88e69867-ae3c-4db8-a3c7-919c585f1894 3d15168e-8277-4dc5-8eeb-ba97919cdcb3 2c80be5ddba15ae404913d2ca69b0000 7e6e9610-2722-4c31-928a-528493dd4820 f8e91ddb-3001-46bf-80f1-e8d7a98e071c 82e61bfb-cbc4-4a0f-a2ab-ca895f60abda 2a5890c1-c51c-4a86-8c1b-c4f190b3bcad 2284c7a2375f425067d202cdf71cfb45 8c762fac-ded6-43dc-a892-e4f49fbf4b56 7115b582-1d14-4830-8dee-5bdc5b03bf6c b636b01d-bb73-47af-a908-9f26a8c25535 fb715bd0-c169-4430-8f1f-0b5304e7098b 435447843442c2b1f66b918d8f8431e4 f6e42c1e-deea-408c-b8ae-3b11f1df4d78 b9cb30dd-d039-4222-ab39-db1adafede29 fe6883c0bcd398b29de1fa2c37cb4375 e6b67a7b-0acd-4f05-bacd-1b2ca3354106 207373a6-69e2-4879-8378-e6dde99a7ab4 2cb1c65b-d3eb-4fc3-9e1f-62e56a46222d 9e71963b-6358-4204-b951-15bf1a1a2ec4 369b08c6717773fe5ca407113bb1ed21 33df2f89-6d80-46de-8961-c3bfbfe4fea1 78fda554-38b6-47f8-8287-76397e0fcd6d b5e0cf62-03b8-4267-8b82-6fa640d324f9 6260da18-f6fc-411c-a726-a8e88a6e3fc1 c446c043-1a3a-4171-9ac7-dcfba5a74fac 9268fbbe-4353-4a8f-b5c7-7a93d4229f51 6b2ffa4a-b1b8-4c03-83b5-4604cb65395b]]]  old={"mySchedule":[],"type":"profile"} --> wrong user

02:48:25.745934 BulkDocs: Doc "bs...@gmx.com" --> 403 wrong user (wrong user)

02:48:25.764973 CRUD+: Saving old revision "bs...@gmx.com" / "52-27f8ecb85a80ccb6ace900891243722b" (34 bytes)

02:48:25.770364 CRUD+: Backed up obsolete rev "bs...@gmx.com"/"52-27f8ecb85a80ccb6ace900891243722b"

02:48:25.771225 CRUD: Stored doc "bs...@gmx.com" / "53-292ffff3-ecc6-4a68-9d3e-e15b200f6bd7"

02:48:25.771335 Changes: Updating #1534 "bs...@gmx.com"/"53-292ffff3-ecc6-4a68-9d3e-e15b200f6bd7" in channels {}

02:48:26.582021 Changes+: Notifying that "bsg_sync" changed (key="_sync:log2:profiles") count=6

02:48:26.582063 Changes+: Notifying that "bsg_sync" changed (key="_sync:log2:*") count=7

02:48:26.582334 Changes: MultiChangesFeed: channels expand to *:1218 ...

02:48:26.582440 Changes: MultiChangesFeed: channels expand to *:1460 ...

02:48:26.583043 Changes: MultiChangesFeed done

02:48:26.583182 Changes: MultiChangesFeed done

02:48:26.735427 HTTP:  #192: GET /bsg_sync/_changes?feed=longpoll&limit=50&heartbeat=300000&since=*%3A1534

02:48:26.735528 Changes: MultiChangesFeed({*}, {Since:*:1534 Limit:50 Conflicts:false IncludeDocs:false Wait:true Terminator:0x192f2030}) ...

02:48:26.735608 Changes: MultiChangesFeed: channels expand to *:1218 ...

02:48:26.735825 Changes+: Waiting for "bsg_sync"'s count to pass 7

02:48:26.735935 HTTP:  #193: GET /bsg_sync/_changes?feed=longpoll&limit=50&heartbeat=300000&since=*%3A1534  (as bs...@gmx.com)

02:48:26.735997 Changes: MultiChangesFeed({*}, {Since:*:1534 Limit:50 Conflicts:false IncludeDocs:false Wait:true Terminator:0x192f2270}) ...

02:48:26.736061 Changes: MultiChangesFeed: channels expand to *:1460 ...

02:48:26.736227 Changes+: Waiting for "bsg_sync"'s count to pass 7

02:48:28.051798 HTTP:  #194: PUT /bsg_sync/_local/12f095b1b648aa1f953eafb30e9673d62c1c8253

02:48:28.052091 HTTP:  #194:     --> 409 Document update conflict

02:48:28.052827 HTTP:  #195: PUT /bsg_sync/_local/12f095b1b648aa1f953eafb30e9673d62c1c8253  (as bs...@gmx.com)

02:48:29.382523 HTTP:  #196: PUT /bsg_sync/_local/0538fb29d703d5fe65e770a09de275604f6e2faf

02:48:29.383753 HTTP:  #197: PUT /bsg_sync/_local/0538fb29d703d5fe65e770a09de275604f6e2faf  (as bs...@gmx.com)

02:48:29.384013 HTTP:  #197:     --> 409 Document update conflict

By the way, I basically made sure I did this to get the session cookie set on the replications

Authorizer auth = new Authorizer() {
    @Override public boolean usesCookieBasedLogin() { return true; } 

}; 

 replicator.setAuthorizer(auth); 

 String cookie = CookieManager.getInstance.getCookie(MY_SESSION_COOKIE);

 replicator.getHeaders().put("Cookie", cookie);

[Jens Alfke]

On Apr 22, 2014, at 7:57 PM, Brian Hardy <brian...@gmail.com> wrote:

02:48:25.599160 HTTP:  #190: POST /bsg_sync/_bulk_docs
02:48:25.604319 CRUD+: Invoking sync on doc "bs...@gmx.com" rev 53-292ffff3-ecc6-4a68-9d3e-e15b200f6bd7
02:48:25.606025 HTTP:  #191: POST /bsg_sync/_bulk_docs  (as bs...@gmx.com)
02:48:25.607583 CRUD+: Invoking sync on doc "bs...@gmx.com" rev 53-292ffff3-ecc6-4a68-9d3e-e15b200f6bd7

Oh man, this took me way too long to figure out. I chased down some red herrings until I realized that you’ve got two replicators running at once. The lines I quoted above show two almost-simultaneous requests to push the same document, but one request is logged-in and the other isn’t. So the first request gets the ‘wrong user’ error, while the second succeeds.

I don’t know why there are two replications. Are you running two clients?

—Jens

[Brian Hardy]

I had been creating replications via a Couchbase Lite Database object obtained from a Manager.

Database database = manager.getDatabase(dbName);
Replication pullReplication = database.createPullReplication(syncUrl);
Replication pushReplication = database.createPushReplication(syncUrl);

I was under the impression that the Database object maintained these and I could get them again using the same createPullReplication method, but after what you saw, I think they create brand new Replications.

After creating replications I tried to invoke getAllReplications to see what the database object knew about.

List<Replication> replications = database.getAllReplications();

But this returned null. I do not know how to set or add a Replication to a database.

[Brian Hardy]

Does this log look like I fixed my issue with Replications for multiple users?

00:57:19.886530 Persona: Verifying assertion "eyJhbGciOiJSUzI1NiJ9.eyJwdWJsaWMta2V5Ijp7ImFsZ29yaXRobSI6IkRTIiwieSI6IjU1ODRmOWM4NjFjODg0MGQyNjA3Mzc5MDNkNzkwMTc2MzE1ZmQzMDZmZDhhYWE0MzBiM2E5MDRiY2I2ZWQyNjc5MzM0NzNlMGQ4MTMxYTkzM2M1ZGRjYThhY2QyNDBkNWZhYmIzMjI4MzJiNTAyN2Q0YjQ4MjAzZjM3ZmI5NmUzM2U2MzZlMDA2OGQyMjMyZmVjYmQ4MjE0YmEwM2ViY2Q5MTk2ZmFhM2FmMTlmOWNmODdhOGYxMTQ0ZGRjMjcwOTRmOTc2NzlkZDE4ZDYxNGQ4OGIwYjQ5ZDk0MDBjZjg4Njc5ZDE5MzczYmQ2MDFmMjBkNzQwOGZhODJiYTEwNCIsInAiOiJmZjYwMDQ4M2RiNmFiZmM1YjQ1ZWFiNzg1OTRiMzUzM2Q1NTBkOWYxYmYyYTk5MmE3YThkYWE2ZGMzNGY4MDQ1YWQ0ZTZlMGM0MjlkMzM0ZWVlYWFlZmQ3ZTIzZDQ4MTBiZTAwZTRjYzE0OTJjYmEzMjViYTgxZmYyZDVhNWIzMDVhOGQxN2ViM2JmNGEwNmEzNDlkMzkyZTAwZDMyOTc0NGE1MTc5MzgwMzQ0ZTgyYTE4YzQ3OTMzNDM4Zjg5MWUyMmFlZWY4MTJkNjljOGY3NWUzMjZjYjcwZWEwMDBjM2Y3NzZkZmRiZDYwNDYzOGMyZWY3MTdmYzI2ZDAyZTE3IiwicSI6ImUyMWUwNGY5MTFkMWVkNzk5MTAwOGVjYWFiM2JmNzc1OTg0MzA5YzMiLCJnIjoiYzUyYTRhMGZmM2I3ZTYxZmRmMTg2N2NlODQxMzgzNjlhNjE1NGY0YWZhOTI5NjZlM2M4MjdlMjVjZmE2Y2Y1MDhiOTBlNWRlNDE5ZTEzMzdlMDdhMmU5ZTJhM2NkNWRlYTcw NGQxNzVmOGViZjZhZjM5N2Q2OWUxMTBiOTZhZmIxN2M3YTAzMjU5MzI5ZTQ4MjliMGQwM2JiYzc4OTZiMTViNGFkZTUzZTEzMDg1OGNjMzRkOTYyNjlhYTg5MDQxZjQwOTEzNmM3MjQyYTM4ODk1YzlkNWJjY2FkNGYzODlhZjFkN2E0YmQxMzk4YmQwNzJkZmZhODk2MjMzMzk3YSJ9LCJwcmluY2lwYWwiOnsiZW1haWwiOiJic2czMEBnbXguY29tIn0sImlhdCI6MTM5ODMwMTAzODQyNSwiZXhwIjoxMzk4MzA0NjM4NDI1LCJpc3MiOiJsb2dpbi5wZXJzb25hLm9yZyJ9.Ir78_RItLBFotAKhmGAbWHfS-0P3iYjG1pN36XYOlu0KUEzGIrvofjRSeo4BziRD1oJxynDk1Pk59meZc-JcYEgtg3jcNWDPfX6vItIuV1eeQAhs2bsBKiF4U0DwWv8s6PQHAPjZZq0wf-gLBc5q-9OeH4gMofRWuuPjEVFlrOEa4qqkE_6IGM94cdY-0MpC40UPSOE1hx05mYqAqa2iThjSUIrHH6gb3ZLfW-oIiZ2cgTZGFj7mOdqBJZ_E-bQ2doAvTruwsEpk41HcyxHPCsxsq6eW0bYDTY6RyV2yf47IjOFUZ_a0KOTfnx2tJCLk_7A1bywj8DKyb5bGWdpEUA~eyJhbGciOiJEUzEyOCJ9.eyJleHAiOjEzOTgzMDExNTg0NTYsImF1ZCI6Imh0dHA6Ly9lYzItNTQtMjA1LTE1NC0yMDAuY29tcHV0ZS0xLmFtYXpvbmF3cy5jb206NDk4NCJ9.i_ljHSeHqS3uY3SmAZf0Nmo3czANS408sN4l-KJ3v0nj2gL4cLg67g" for "http://myserver.com:4984/"

00:57:20.253354 Persona: Logged in "bs...@gmx.com"!
00:58:24.345781 HTTP: #243: POST /bsg_sync/_revs_diff (as bs...@gmx.com)
00:58:24.960912 HTTP: #244: POST /bsg_sync/_bulk_docs (as bs...@gmx.com)
00:58:24.961599 CRUD+: Invoking sync on doc "bs...@gmx.com" rev 5-28448158-6b69-43ed-a8b0-6cb08eaf92e0
00:58:24.961902 CRUD+: Saving old revision "bs...@gmx.com" / "4-d5a54999-f570-4e6f-9e65-52a2b6106503" (78 bytes)
00:58:24.962093 CRUD+: Backed up obsolete rev "bs...@gmx.com"/"4-d5a54999-f570-4e6f-9e65-52a2b6106503"
00:58:24.962336 CRUD: Stored doc "bs...@gmx.com" / "5-28448158-6b69-43ed-a8b0-6cb08eaf92e0"
00:58:24.962359 Changes: Updating #1561 "bs...@gmx.com"/"5-28448158-6b69-43ed-a8b0-6cb08eaf92e0" in channels {}
00:58:25.729802 Changes+: Notifying that "bsg_sync" changed (key="_sync:log2:profiles") count=5
00:58:25.729846 Changes+: Notifying that "bsg_sync" changed (key="_sync:log2:*") count=6
00:58:25.730519 Changes: MultiChangesFeed: channels expand to ...
00:58:25.730632 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:58:25.730730 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:58:25.730786 Changes+: Waiting for "bsg_sync"'s count to pass 6
00:58:25.730963 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:58:25.731106 Changes+: Aborting changesFeed
00:58:25.731122 Changes+: Waiting for "bsg_sync"'s count to pass 6
00:58:25.731191 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:58:25.731398 Changes+: Aborting changesFeed
00:58:25.731426 Changes+: Waiting for "bsg_sync"'s count to pass 6
00:58:25.731497 Changes: MultiChangesFeed done
00:58:25.731932 Changes: MultiChangesFeed: channels expand to *:1 ...
00:58:25.732054 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:58:25.732330 Changes: MultiChangesFeed done
00:58:25.732481 Changes+: Aborting changesFeed
00:58:25.732496 Changes+: Waiting for "bsg_sync"'s count to pass 6
00:58:25.732839 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:58:25.732993 Changes: MultiChangesFeed: channels expand to *:1 ...
00:58:25.733300 Changes: MultiChangesFeed done
00:58:25.733565 Changes+: Aborting changesFeed
00:58:25.733584 Changes+: Waiting for "bsg_sync"'s count to pass 6
00:58:25.733950 Changes: MultiChangesFeed done
00:58:25.734386 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:58:25.734549 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:58:25.735020 Changes+: Aborting changesFeed
00:58:25.735040 Changes+: Waiting for "bsg_sync"'s count to pass 6
00:58:25.735109 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:58:25.735211 Changes: MultiChangesFeed done
00:58:25.735567 Changes+: Aborting changesFeed
00:58:25.735586 Changes+: Waiting for "bsg_sync"'s count to pass 6
00:58:25.739730 Changes: MultiChangesFeed: channels expand to *:1 ...
00:58:25.740201 Changes+: Aborting MultiChangesFeed
00:58:25.808621 HTTP: #245: GET /bsg_sync/_changes?feed=longpoll&limit=50&heartbeat=300000&since=*%3A1561 (as Admin)
00:58:25.808713 Changes: MultiChangesFeed({*}, {Since:*:1561 Limit:50 Conflicts:false IncludeDocs:false Wait:true Terminator:0x192649f0}) ...
00:58:25.808833 Changes: MultiChangesFeed: channels expand to *:1 ...
00:58:25.809074 Changes+: Waiting for "bsg_sync"'s count to pass 6
00:58:25.979673 HTTP: #246: GET /bsg_sync/_changes?feed=longpoll&limit=50&heartbeat=300000&since=*%3A1561 (as bs...@gmx.com)
00:58:25.979766 Changes: MultiChangesFeed({*}, {Since:*:1561 Limit:50 Conflicts:false IncludeDocs:false Wait:true Terminator:0x19264c00}) ...
00:58:25.979841 Changes: MultiChangesFeed: channels expand to ...
00:58:25.980119 Changes+: Waiting for "bsg_sync"'s count to pass 6
00:58:26.445981 HTTP: #247: GET /bsg_sync/bs...@gmx.com?rev=5-28448158-6b69-43ed-a8b0-6cb08eaf92e0&revs=true&attachments=true&atts_since=%5B%224-d5a54999-f570-4e6f-9e65-52a2b6106503%22%5D (as Admin)
00:58:27.541365 HTTP: #248: PUT /bsg_sync/_local/50682ab65099cb7245ebea1f0dbfc4c496de9734 (as bs...@gmx.com)
00:58:28.818172 HTTP: #249: PUT /bsg_sync/_local/a6104b36d463722571ffe3532ee85c7695725e21 (as bs...@gmx.com)
00:58:29.623197 HTTP: #250: PUT /bsg_sync/_local/f05b56e076c89af2f7e883a354d91b0c560a2bdf (as Admin)

[Matt Quinn]

On Thu, Apr 24, 2014 at 12:50:57PM -0700, Brian Hardy wrote:
> Database database = manager.getDatabase(dbName);
> Replication pullReplication = database.createPullReplication(syncUrl);
> Replication pushReplication = database.createPushReplication(syncUrl);
>
> I was under the impression that the Database object maintained these and I
> could get them again using the same createPullReplication method, but after
> what you saw, I think they create brand new Replications.

It did used to work that way, but it was changed to create a
new replication every time a while ago. (Some background is available in issue
#180[0]).

> After creating replications I tried to invoke getAllReplications to see
> what the database object knew about.
>
> List<Replication> replications = database.getAllReplications();
>
> But this returned null. I do not know how to set or add a Replication to a
> database.

It looks like replications aren't tracked by the Database until start()
is called[1].

[0] https://github.com/couchbase/couchbase-lite-android/issues/180
[1] https://github.com/couchbase/couchbase-lite-java-core/blob/78b83276d921c3d8acc221b274d8fe261dbfc4d7/src/main/java/com/couchbase/lite/replicator/Replication.java#L466-L467

[Brian Hardy]

Hmmm. My Replications are started yet I cannot get them from the Database object.

I am not keeping the Database object around I am keeping the database name around and calling the following code to get the database as needed.

database = manager.getDatabase(dbName);

I keep getting null for replications when I run this 

[Brian Hardy]

I'm assuming I am running a different version of the code than what you showed me.

I'm using these libraries in my Android client:

under libs/x86 I have these:

CBLite-1.0.0-beta2.jar

CBLiteJavascript-1.0.0-beta2.jar

CBLiteListener-1.0.0-beta2.jar

under libs/armeabi and libs/mips I have libcom_couchbase_touchdb_TDCollateJSON.so

[Matt Quinn]

On Thu, Apr 24, 2014 at 02:07:19PM -0700, Brian Hardy wrote:
> I'm assuming I am running a different version of the code than what you
> showed me.
> I'm using these libraries in my Android client:
> under libs/x86 I have these:
> CBLite-1.0.0-beta2.jar
> CBLiteJavascript-1.0.0-beta2.jar
> CBLiteListener-1.0.0-beta2.jar

Yes, sorry -- I was looking at the latest code. It looks like the
replication tracking code has changed a fair bit since beta2. It's
possible that it wasn't really working back then.

[Brian Hardy]

Can you tell me where I should get the latest libraries for coucbase lite for android? My sync gateway and couchbase server run on the prebuilt ec2 image so that is not the very latest backend.

Thank you.

[Traun Leyden]

I just added some instructions to the README on how to get the latest builds for:

Maven artifacts (Android Studio)

Zipfile with jars (Eclipse / Phonegap)

Let me know if that works for you.

On Thu, Apr 24, 2014 at 4:44 PM, Brian Hardy <brian...@gmail.com> wrote:

Can you tell me where I should get the latest libraries for coucbase lite for android? My sync gateway and couchbase server run on the prebuilt ec2 image so that is not the very latest backend.

Thank you.

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/d00421a0-af2e-4f5f-b12d-bbb652911594%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Brian Hardy]

Ok for now I'm keeping track of replications myself. I'm keeping two around - one for pull and one for push.

When our app starts up its accessing couchase as guest. A liveQuery with a query listener is created. Its works well.

Once I log in via persona, I update my two replications to have the header set with the cookie.

It seems the live query previously setup as GUEST stopped working. 

I never noticed this issue before perhaps because I had two sets of replications. One for GUEST and one for an authenticated user.

After persona login all I did to the replication was the following:

replication.getHeaders().put("Cookie", cookie);
replication.setAuthorizer(authorizer);

Do I have to recreate a query and reregister the query listener after modifying the replications?

Is this the right thing to do or was it better to have more replications running - one set for GUEST and one for the logged in user?

Thanks

[Brian Hardy]

I tried to post a response about the jar files. Did it go to you directly? I didn't see it show up here. The zip supplied seemed to be javadocs. I'm not sure what files to pull from the build.

[Traun Leyden]

Yeah that got sent as a private message.

couchbase-lite-0.0.0-273-android-community.zip is the right link, I just fixed the README.  (great catch!)

The jars have been renamed from the beta2 jars.  

android-0.0.0-273.jar -> couchbase-lite-android

java-core-0.0.0-273.jar -> couchbase-lite-java-core  

cbl_collator_so-0.0.0-273.jar -> "collator" .so objects packaged in a jar  

java-javascript-0.0.0-273.jar -> couchbase-lite-java-javascript (needed in phonegap/rest apps)

java-listener-0.0.0-273.jar -> couchbase-lite-java-listener (needed in phonegap/rest apps)

The rest of the jars are dependencies.

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/f6faed32-4d1c-479e-896a-a7f552ebb536%40googlegroups.com.

[Traun Leyden]

In ToDoLite-Android, we don't have that problem because we don't start the replicators until the user logs in.

In your case I'd recommend shutting down the GUEST replicators and starting new replicators with the cookie as soon as the user logs in.

Btw, we added a new API call recently:

    Replication.setCookie(String name, String value, String path, Date expirationDate, boolean secure, boolean httpOnly)

 

--

You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/a9ad4610-e946-4e0c-bdf7-0c8445b21c1b%40googlegroups.com.

[Brian Hardy]

Thanks Traun.

How do you shut down a replicator? Would all live queries need to be restarted when using the new replicator.

If I used the updated software, then when I updated the replicator with the cookie information about the authenticated user, would my existing live queries still function? Or would I still need to shut them down and replace them with new replicators regardless of the software upgrade?

As another strategy, Could I have guest replicators and authenticated-user replicators running then use public channels and authenticated user channels? Or do you think it's easier to shut down the guest replicator?

Can you point me to any documents to better understand and learn about the sync function and especially channels. I'm having a tough time understanding how to use them.

[J. Chris Anderson]

On Friday, April 25, 2014 10:23:17 AM UTC-7, Brian Hardy wrote:

Thanks Traun.

How do you shut down a replicator? Would all live queries need to be restarted when using the new replicator.

Live queries are against the local Couchbase Lite instance, so they should be totally independent of the replicator. It sounds like the important thing is to restart the replications after setting credentials.

[Brian Hardy]

When I start my app as GUEST I create a liveQuery and I get expected results. 

If I modify data on the backend via curl -X PUT localhost:4985, I see the results update. 

Here is the output in sync gateway log of backend update with successful update on client:

00:02:38.080213 HTTP: #198: GET /bsg_sync/session:1088 (as Admin)
00:02:38.233805 HTTP: #199: PUT /bsg_sync/session:1088 (as Admin)
00:02:38.234978 CRUD+: Invoking sync on doc "session:1088" rev 38-dab8ca4f415536ae4af8b427450fa93b
00:02:38.235208 CRUD+: Saving old revision "session:1088" / "37-a5fbcf22bfa59319c55f286e461b7efc" (258 bytes)
00:02:38.235420 CRUD+: Backed up obsolete rev "session:1088"/"37-a5fbcf22bfa59319c55f286e461b7efc"
00:02:38.236055 CRUD: Stored doc "session:1088" / "38-dab8ca4f415536ae4af8b427450fa93b"
00:02:38.236083 Changes: Updating #1618 "session:1088"/"38-dab8ca4f415536ae4af8b427450fa93b" in channels {}
00:02:39.007719 Changes+: Notifying that "bsg_sync" changed (key="_sync:log2:*") count=22
00:02:39.008151 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:02:39.008234 Changes: MultiChangesFeed: channels expand to *:1 ...
00:02:39.008662 Changes: MultiChangesFeed done
00:02:39.008961 Changes: MultiChangesFeed done
00:02:39.087488 HTTP: #200: GET /bsg_sync/_changes?feed=longpoll&limit=50&heartbeat=300000&since=*%3A1618
00:02:39.087679 Changes: MultiChangesFeed({*}, {Since:*:1618 Limit:50 Conflicts:false IncludeDocs:false Wait:true Terminator:0x19256480}) ...
00:02:39.087804 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:02:39.088049 Changes+: Waiting for "bsg_sync"'s count to pass 22
00:02:39.570984 HTTP: #201: GET /bsg_sync/_changes?feed=longpoll&limit=50&heartbeat=300000&since=*%3A1618%2Csessions%3A1607 (as Admin)
00:02:39.571108 Changes: MultiChangesFeed({*}, {Since:*:1618,sessions:1607 Limit:50 Conflicts:false IncludeDocs:false Wait:true Terminator:0x19272450}) ...
00:02:39.571203 Changes: MultiChangesFeed: channels expand to *:1 ...
00:02:39.571413 Changes+: Waiting for "bsg_sync"'s count to pass 22
00:02:39.703481 HTTP: #202: GET /bsg_sync/session:1088?rev=38-dab8ca4f415536ae4af8b427450fa93b&revs=true&attachments=true&atts_since=%5B%2237-a5fbcf22bfa59319c55f286e461b7efc%22%5D
00:02:40.179066 HTTP: #203: GET /bsg_sync/session:1088?rev=38-dab8ca4f415536ae4af8b427450fa93b&revs=true&attachments=true&atts_since=%5B%2237-a5fbcf22bfa59319c55f286e461b7efc%22%5D (as Admin)
00:02:42.883226 HTTP: #204: PUT /bsg_sync/_local/4bb53e64435ac524c952093b1f90b0d1c420fe5f

Next I authenticate as bs...@gmx.com via persona. 

00:04:59.678283 HTTP: #206: POST /bsg_sync/_persona
00:04:59.759642 Persona: Verifying assertion "eyJhbGciOiJSUzI1NiJ9.eyJwdWJsaWMta2V5Ijp7ImFsZ29yaXRobSI6IkRTIiwieSI6IjQ1YjQ1OTYzMmViNWJmMWI0YTA2ODQyNmFhOTEwYWE4YTdlYTVjODZhNGQ3MGZlMTFhZGUxMDFmMjY4OTYzNWMyOWI0ODkyOWNiYjIxYzA4ZmRiYjUxMTIyMWY5NTIwNDk2NWNmZTBhMDhkYzNlNTY0ZGFlYmQwMDIzYmUxNjcwNzIzZWU2ZWE4MjAzNDdjYjFmN2UwY2M5NmEwZTE0YWM1MGZjOWQ4ZTViMjczZDk0YWRmMWMzZGQ1MTU5OTk2MDNmMmFiYTgxNzk3YWEzNmI2NjJhNDAyMWQ1YjY1NGU0YTEzMjI5OTk0Y2IzYjA1NGYxNDFiZjBlZWI0MTkzOGYiLCJwIjoiZmY2MDA0ODNkYjZhYmZjNWI0NWVhYjc4NTk0YjM1MzNkNTUwZDlmMWJmMmE5OTJhN2E4ZGFhNmRjMzRmODA0NWFkNGU2ZTBjNDI5ZDMzNGVlZWFhZWZkN2UyM2Q0ODEwYmUwMGU0Y2MxNDkyY2JhMzI1YmE4MWZmMmQ1YTViMzA1YThkMTdlYjNiZjRhMDZhMzQ5ZDM5MmUwMGQzMjk3NDRhNTE3OTM4MDM0NGU4MmExOGM0NzkzMzQzOGY4OTFlMjJhZWVmODEyZDY5YzhmNzVlMzI2Y2I3MGVhMDAwYzNmNzc2ZGZkYmQ2MDQ2MzhjMmVmNzE3ZmMyNmQwMmUxNyIsInEiOiJlMjFlMDRmOTExZDFlZDc5OTEwMDhlY2FhYjNiZjc3NTk4NDMwOWMzIiwiZyI6ImM1MmE0YTBmZjNiN2U2MWZkZjE4NjdjZTg0MTM4MzY5YTYxNTRmNGFmYTkyOTY2ZTNjODI3ZTI1Y2ZhNmNmNTA4YjkwZTVkZTQxOWUxMzM3ZTA3YTJlOWUyYTNjZDVkZWE3MDRkMTc1ZjhlYmY2YWYzOTdkNjllMTEwYjk2YWZiMTdjN2EwMzI1OTMyOWU0ODI5YjBkMDNiYmM3ODk2YjE1YjRhZGU1M2UxMzA4NThjYzM0ZDk2MjY5YWE4OTA0MWY0MDkxMzZjNzI0MmEzODg5NWM5ZDViY2NhZDRmMzg5YWYxZDdhNGJkMTM5OGJkMDcyZGZmYTg5NjIzMzM5N2EifSwicHJpbmNpcGFsIjp7ImVtYWlsIjoiYnNnMzBAZ214LmNvbSJ9LCJpYXQiOjEzOTg0NzA2OTk0MDgsImV4cCI6MTM5ODQ3NDI5OTQwOCwiaXNzIjoibG9naW4ucGVyc29uYS5vcmcifQ.ZKPuXm4ZbFXbu8i3DbHCYsJ0KC8r_pxyCTbSJFmQGfrjBKUyvpliCrM0fDNzZ8i-bwTGayDIupJXm1fkmA2HrRz0nv1woVRW26pE5Rmu5xVR_zlcPYRVHtxLhtDJdkgdeFxWb74LDEdAHKi1vEE97p89u-OXrTxzW-0cwwB7ZxaiBN-5HK6qiuj8HFKLduBnCIA68y2iiHCBgvrGhwgopI0UBHu-RoYINK5YdLAX7Jb7Dvf-uh4tn-PnVcX-iPV7IpBU3kZrvErvlyoc7InPbC_SPrXpFsuOkGVeYBRHdMAyVQXlxk9fzqgdp0IUur1_bZtVf1wKGkXN0HvwffWKmg~eyJhbGciOiJEUzEyOCJ9.eyJleHAiOjEzOTg0NzA4MTkzNjIsImF1ZCI6Imh0dHA6Ly9lYzItNTQtMjA1LTE1NC0yMDAuY29tcHV0ZS0xLmFtYXpvbmF3cy5jb206NDk4NCJ9.pk4-9YpFvFxAFQX8TSSVuxt34dXQGej9YGx6o8aA2np41wUxJxpfUQ" for "http://myserver.com:4984/"
00:04:59.826721 Persona: Logged in "bs...@gmx.com"!
00:04:59.993202 HTTP: #207: GET /bsg_sync/_session (as bs...@gmx.com)
00:04:59.994825 HTTP: #208: GET /bsg_sync/_session (as bs...@gmx.com)

Now when I go and modify data via curl -X PUT localhost:4985 again. But now I don't get an update in the client app any longer. I see log from sync gateway as below but my app does not receive the update.

00:06:08.670217 HTTP: #209: GET /bsg_sync/session:1088 (as Admin)
00:06:08.823826 HTTP: #210: PUT /bsg_sync/session:1088 (as Admin)
00:06:08.824924 CRUD+: Invoking sync on doc "session:1088" rev 39-4939ceead36467875225a0b11fbe73bc
00:06:08.825175 CRUD+: Saving old revision "session:1088" / "38-dab8ca4f415536ae4af8b427450fa93b" (258 bytes)
00:06:08.825442 CRUD+: Backed up obsolete rev "session:1088"/"38-dab8ca4f415536ae4af8b427450fa93b"
00:06:08.826093 CRUD: Stored doc "session:1088" / "39-4939ceead36467875225a0b11fbe73bc"
00:06:08.826119 Changes: Updating #1619 "session:1088"/"39-4939ceead36467875225a0b11fbe73bc" in channels {}
00:06:09.018389 Changes+: Notifying that "bsg_sync" changed (key="_sync:log2:*") count=23
00:06:09.018771 Changes: MultiChangesFeed: channels expand to *:1218 ...
00:06:09.018911 Changes: MultiChangesFeed: channels expand to *:1 ...
00:06:09.019126 Changes: MultiChangesFeed done
00:06:09.019453 Changes: MultiChangesFeed done
00:06:09.403285 HTTP: #211: GET /bsg_sync/_changes?feed=longpoll&limit=50&heartbeat=300000&since=*%3A1619%2Csessions%3A1607 (as Admin)
00:06:09.403407 Changes: MultiChangesFeed({*}, {Since:*:1619,sessions:1607 Limit:50 Conflicts:false IncludeDocs:false Wait:true Terminator:0x19281bd0}) ...
00:06:09.403512 Changes: MultiChangesFeed: channels expand to *:1 ...
00:06:09.403771 Changes+: Waiting for "bsg_sync"'s count to pass 23
00:06:10.000829 HTTP: #212: GET /bsg_sync/session:1088?rev=39-4939ceead36467875225a0b11fbe73bc&revs=true&attachments=true&atts_since=%5B%2238-dab8ca4f415536ae4af8b427450fa93b%22%5D (as Admin)

Again, I'm currently using CBLite-1.0.0-beta2.jar libraries.

Here is my config.json with sync function. I feel like there is an access problem. Like data was created under one channel that another user does not have access too.

{
      "interface": ":4984",
      "adminInterface": ":4985",
      "log": ["CRUD", "CRUD+", "HTTP", "HTTP+", "Access", "Cache", "Shadow", "Shadow+", "Changes", "Changes+"],
      "persona": { "origin": "http://myserver.com:4984/", "register": true },
      "databases": {
          "bsg_sync": {
              "server": "http://localhost:8091",
              "bucket": "bsg_sync",
              "users": {
                  "GUEST": {"disabled": false, "admin_channels":["*"], "all_channels":["*"]},
                  "bs...@gmx.com": {"disabled": false, "admin_channels":["*"], "all_channels":["*"]}
              },
             "sync": `function(doc, oldDoc) {
                  channel(doc.channels);
                  if (doc.type == "profile") {
                     if (oldDoc) {

                         requireUser(["Admin", "bs...@gmx.com"]);
                    }
                }
            }`
        }
    }
}

Any ideas??

Thanks

[Brian Hardy]

Ahh I just noticed you said liveQueries are agains the local CBLite datastore. When I'm performing the curl command I'm updating data on the server but it is not being reflected in the local client I guess. I assume that is because the replicator does not see a need to sync the data after I have authenticated. I'm not sure why though.

[Brian Hardy]

I noticed this output with a NullPointer exception in Replication.fetchRemoteCheckpointDoc.

I'm running this code in my Android client when I update the Replications with a Authentication cookie:

private void updateReplicators(Authorizer authorizer) {
    Database database = getDatabase(databaseName);
    String cookie = CookieManager.getInstance().getCookie(SITE_URL);
    if (authorizer.usesCookieBasedLogin() && cookie == null) {
        Log.d(TAG, "Using cookie based authentication however no cookies have been set for key "+ syncUrl.toExternalForm());
    }
    if (!authorizer.usesCookieBasedLogin()) {
        CookieManager.getInstance().setCookie(SITE_URL, null);
    }

   // I'm keeping track of these myself since my beta2 CBL doesn't seem too

   List<Replication> replications = getAllReplications();
   if (replications != null) {
       for (Replication replication : replications) {
           showHeaders(replication);
           replication.getHeaders().put("Cookie", cookie);
           showHeaders(replication);
           replication.setAuthorizer(authorizer);
           replication.restart();
        }
    }
}

I noticed this output with a NullPointer exception in Replication.fetchRemoteCheckpointDoc:

04-25 17:35:37.015: D/Database(3262): PersonaAuthorizer exp: 1398472715889 class: class java.lang.Long

04-25 17:35:37.026: D/Database(3262): PersonaAuthorizer exp: 1398472715889 class: class java.lang.Long

04-25 17:35:37.115: D/dalvikvm(3262): GC_CONCURRENT freed 935K, 7% free 15411K/16455K, paused 1ms+1ms

04-25 17:35:37.685: D/Database(3262): PersonaAuthorizer exp: 1398472715889 class: class java.lang.Long

04-25 17:35:37.685: D/Syncer(3262): Puller for http://myserver.com:4984/bsg_sync headers are: 

04-25 17:35:37.685: D/Syncer(3262): Puller for http://myserver.com:4984/bsg_sync headers are: Cookie; 

04-25 17:35:37.685: D/Database(3262): changed tracker asked to stop

04-25 17:35:37.685: V/Database(3262): Change tracker run loop exiting

04-25 17:35:37.685: D/Database(3262): change tracker in stopped

04-25 17:35:37.685: D/Database(3262): change tracker client should be null now

04-25 17:35:37.685: V/Database(3262): Puller[http://myserver.com:4984/bsg_sync] STOPPING...

04-25 17:35:37.685: V/Database(3262): Puller[http://myserver.com:4984/bsg_sync] STOPPED

04-25 17:35:37.685: V/Database(3262): Puller[http://myserver.com:4984/bsg_sync] STARTING ...

04-25 17:35:37.696: D/Syncer(3262): Pusher for http://myserver.com:4984/bsg_sync headers are: 

04-25 17:35:37.696: D/Syncer(3262): Pusher for http://myserver.com:4984/bsg_sync headers are: Cookie; 

04-25 17:35:37.696: V/Database(3262): Pusher[http://myserver.com:4984/bsg_sync] STOPPING...

04-25 17:35:37.696: V/Database(3262): Pusher[http://myserver.com:4984/bsg_sync] STOPPED

04-25 17:35:37.696: V/Database(3262): Pusher[http://myserver.com:4984/bsg_sync] STARTING ...

04-25 17:35:37.715: W/EGL_emulation(3262): eglSurfaceAttrib not implemented

04-25 17:35:37.845: D/Database(3262): com.couchbase.lite.replicator.Replication$3@b3f769a0 Active session, logged in as bs...@gmx.com

04-25 17:35:37.845: E/Database(3262): RemoteRequestCompletionBlock throw Exception

04-25 17:35:37.845: E/Database(3262): java.lang.NullPointerException

04-25 17:35:37.845: E/Database(3262): at com.couchbase.lite.replicator.Replication.fetchRemoteCheckpointDoc(Replication.java:856)

04-25 17:35:37.845: E/Database(3262): at com.couchbase.lite.replicator.Replication$3.onCompletion(Replication.java:621)

04-25 17:35:37.845: E/Database(3262): at com.couchbase.lite.support.RemoteRequest$2.run(RemoteRequest.java:224)

04-25 17:35:37.845: E/Database(3262): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)

04-25 17:35:37.845: E/Database(3262): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)

04-25 17:35:37.845: E/Database(3262): at java.util.concurrent.FutureTask.run(FutureTask.java:137)

04-25 17:35:37.845: E/Database(3262): at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:150)

04-25 17:35:37.845: E/Database(3262): at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:264)

04-25 17:35:37.845: E/Database(3262): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)

04-25 17:35:37.845: E/Database(3262): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)

04-25 17:35:37.845: E/Database(3262): at java.lang.Thread.run(Thread.java:856)

04-25 17:35:37.855: D/Database(3262): com.couchbase.lite.replicator.Replication$3@b3e43b68 Active session, logged in as bs...@gmx.com

04-25 17:35:37.855: E/Database(3262): RemoteRequestCompletionBlock throw Exception

04-25 17:35:37.855: E/Database(3262): java.lang.NullPointerException

04-25 17:35:37.855: E/Database(3262): at com.couchbase.lite.replicator.Replication.fetchRemoteCheckpointDoc(Replication.java:856)

04-25 17:35:37.855: E/Database(3262): at com.couchbase.lite.replicator.Replication$3.onCompletion(Replication.java:621)

04-25 17:35:37.855: E/Database(3262): at com.couchbase.lite.support.RemoteRequest$2.run(RemoteRequest.java:224)

04-25 17:35:37.855: E/Database(3262): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)

04-25 17:35:37.855: E/Database(3262): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)

04-25 17:35:37.855: E/Database(3262): at java.util.concurrent.FutureTask.run(FutureTask.java:137)

04-25 17:35:37.855: E/Database(3262): at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:150)

04-25 17:35:37.855: E/Database(3262): at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:264)

04-25 17:35:37.855: E/Database(3262): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)

04-25 17:35:37.855: E/Database(3262): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)

04-25 17:35:37.855: E/Database(3262): at java.lang.Thread.run(Thread.java:856)

04-25 17:35:37.855: D/OpenGLRenderer(3262): Flushing caches (mode 0)

[Brian Hardy]

when trying to simply stop the replicator on destroy activity I saw this NullPointerException as well:

04-25 18:06:29.343: E/AndroidRuntime(3262): Caused by: java.lang.NullPointerException

04-25 18:06:29.343: E/AndroidRuntime(3262): at com.couchbase.lite.replicator.Replication.stop(Replication.java:440)

04-25 18:06:29.343: E/AndroidRuntime(3262): at com.couchbase.lite.replicator.Puller.stop(Puller.java:100)

04-25 18:06:29.343: E/AndroidRuntime(3262): at com.company.data.synchronization.Syncer.stopSync(Syncer.java:334)

04-25 18:06:29.343: E/AndroidRuntime(3262): at com.company.MainActivity.onDestroy(MainActivity.java:282)

04-25 18:06:29.343: E/AndroidRuntime(3262): at android.app.Activity.performDestroy(Activity.java:4629)

04-25 18:06:29.343: E/AndroidRuntime(3262): at android.app.Instrumentation.callActivityOnDestroy(Instrumentation.java:1079)

04-25 18:06:29.343: E/AndroidRuntime(3262): at android.app.ActivityThread.performDestroyActivity(ActivityThread.java:3099)

04-25 18:06:29.343: E/AndroidRuntime(3262): ... 11 more

[Brian Hardy]

So I'm using the new libraries / jars now

I'm seeing a NullPointerException when I'm restarting my replications:

04-25 20:22:08.016: E/RemoteRequest(5618): RemoteRequestCompletionBlock throw Exception

04-25 20:22:08.016: E/RemoteRequest(5618): java.lang.NullPointerException

04-25 20:22:08.016: E/RemoteRequest(5618): at com.couchbase.lite.replicator.Pusher.beginReplicating(Pusher.java:205)

04-25 20:22:08.016: E/RemoteRequest(5618): at com.couchbase.lite.replicator.Replication$8.onCompletion(Replication.java:1200)

04-25 20:22:08.016: E/RemoteRequest(5618): at com.couchbase.lite.support.RemoteRequest$2.run(RemoteRequest.java:282)

04-25 20:22:08.016: E/RemoteRequest(5618): at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)

04-25 20:22:08.016: E/RemoteRequest(5618): at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)

04-25 20:22:08.016: E/RemoteRequest(5618): at java.util.concurrent.FutureTask.run(FutureTask.java:137)

04-25 20:22:08.016: E/RemoteRequest(5618): at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:150)

04-25 20:22:08.016: E/RemoteRequest(5618): at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:264)

04-25 20:22:08.016: E/RemoteRequest(5618): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)

04-25 20:22:08.016: E/RemoteRequest(5618): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)

04-25 20:22:08.016: E/RemoteRequest(5618): at java.lang.Thread.run(Thread.java:856)

[Traun Leyden]

I filed an issue on github to track this:

https://github.com/couchbase/couchbase-lite-java-core/issues/183

and have a few questions posted on the issue.

--
You received this message because you are subscribed to the Google Groups "Couchbase Mobile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobile-couchba...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/mobile-couchbase/3ae5e405-d114-4165-8349-e21b543d841a%40googlegroups.com.