Cannot query view in sync gateway via user port

I’ve been trying to create a query a view in the sync gateway as described in the docs.

It works up to the point where I try and query the view on the user port at which point I get back a 403 ({“error”:“Forbidden”,“reason”:“forbidden”}). I can see the view in the Admin pages, and I can query the view on the admin port using curl.

I can successfully query other data on the user port, for example the _all_docs endpoint works fine (which I believe confirms that my session token is set up correctly).

What would cause the view to not be accessible on the user port? Do I need to permission users to access it?

1 Like

Reading the doc, seems like it should work. Can you show us the code?

There’s no code, I’m just following the docs (just using curl). The only difference is that the docs talk about logging in with Facebook for some reason. I’m using a user account I’ve created, and generated a session token using a bit of java code. I’ve tested the session token by using it to hit the ‘all docs’ endpoint and it worked.

Any thoughts on this? If I query a view via the user port I receive a HTTP/1.1 403 Forbidden response. If I query through the admin port it works, except that I get documents that have id’s looking like _sync:rev:... which I don’t want.

What permissions do I need to be able to query a view?

Here’s a shell script that reproduces the problem:

#!/usr/bin/env bash

BUCKET=sync_gateway
USER_ID=chef123

echo '{ "views":{ "all_lists":{ "map":"function (doc, meta) { if (doc.type != \"list\") { return; } emit(doc.title, doc.owner); }" } } }' > testview

curl -X PUT -H "Content-type: application/json" localhost:4985/${BUCKET}/_design/all_lists --data @testview

echo 'Query via admin port'
curl localhost:4985/${BUCKET}/_design/all_lists/_view/all_lists

echo
echo 'Creating user'
echo '{ "name": "'${USER_ID}'", "password": "a new password", "admin_roles": ["admin"] }' > testuser
curl -X PUT -H "Content-type: application/json" localhost:4985/${BUCKET}/_user/${USER_ID} --data @testuser

# Getting using session
curl -s -X POST -H "Content-type: application/json" -d '{"name": "'${USER_ID}'"}' localhost:4985/${BUCKET}/_session > session
SESSION=`cut -c 16-55 session`
echo "Session id: $SESSION"

echo 'Query via user port'
#this bit fails with a 403 Forbidden
curl --cookie "SyncGatewaySession="${SESSION} localhost:4984/${BUCKET}/_design/all_lists/_view/all_lists

echo
echo done

I second this issue!

Having the same problem accessing a view via the user port.

Does anyone out there have any idea why this might be happening? The user I am querying with on 4984 definately has access to the docs the view should return but I get Forbidden!

The admin port works fine! Is there something missing from the docs? Should we be giving the view a channel some how?

Reviewing the Sync Gateway commit log, see this issue

If you are using SG 1.2 then this feature can still be enabled via a new config setting - adding the following to your database config will re-enable view query support over the public API:

        "unsupported": {
          "user_views": {
            "enabled":true
          }
        }

Thanks for the tip, that got me a bit further. Problem is now the query result looks like this:

{
  total_rows: 5,
  rows: [ ],
  Collator: { }
}

No Data. Doesn’t matter if I use the admin port or the user port. I guess the docs are simply wrong and this feature doesn’t exist in either 1.1 or 1.2 unless you go via the admin port.

If views in the sync-gateway are a bad idea because of performance problems would creating a shadow be a sensible workaround? And put the view in the shadow? Where are the docs on shadowing by the way!?

Is this a good place to ask for the docs to be updated? They’re wrong in quite a number of places.

@nick-couchbase

The view needs to be created after the “unsupported” config change to get the appropriate view wrapper to support the User API.

If you are testing against a view created prior to the config change, try creating a new view and then test.

View performance issues are related to the underlying Couchbase Server views.

Shadowing is not a recommended approach and view performance is still limited by Couchbase Server.

Thanks Andy, I’ll try that.

Can I ask, what are the performance concerns around couch base views? Are there any alternatives?

@nick-couchbase

Sync Gateway calls the CBS views with ‘stale=false’ to ensure that the latest doc revisions have been indexed, before running the view query.

The indexing overhead when many users are querying views can have an impact on response times.

Depending on your use case, you might consider creating and querying views directly in Couchbase Server, on the Sync Gateway bucket, this is safe as views only read document contents.

If you can accept stale data in the views, you would not incur the indexing overhead on every view query.

I added this to my config and now views are working via the user api, however, it breaks any views that have a reduce function returning only

{ "total_rows": 0, "rows": [], "Collator": {} }

So i needed to include the ?reduce=true parameter to the query. it is now running the reduce function.

I have also worked out that each value from the map function is now an array of arrays, the first element being an array containing the channels, the second containing the actual value.

this is only working on the admin port

the problem now is that I am unable to get a result back using the user port. I assume it is due to permissions. Is it that the result from the reduce function is somehow not passing the permissions from the documents to allow the user to see the result???

Any ideas?

Thanks Andy, I think I understand. So, just to recap…

I’ve been unable to get the unsupported / user_views workaround you mentioned to work. I’ve tried creating the view after changing my config and restarting the gateway as you suggest but still no luck. I don’t get any data back from it, just a doc that looks like this:

{
  total_rows: 11,
  rows: [ ],
  Collator: { }
}

Has anyone managed to get this working?

However, it sort of doesn’t matter however. As you said, these views may cause an awful lot of indexing which may in turn cause some performance problems due to the staleness element of the view query.

The suggested workaround is to create a view directly on the sync-gateway bucket, rather than via the sync-gateway api. The view can be configured to allow state results if that’s acceptable to my application. By creating the view in this way it not be accessible via the sync-gateway rest api on user port (4984). Instead it will be necessary to query the view via the couch base api port (8092), correct?

any updates on this issue? I’m dealing with this same issue. I’m querying a view that I created in the Couchbase server console and getting this:

{
"total_rows": 0,
"rows": [],
"Collator": {}
}