search:search returns results in query console but no results when its hit from an application by http get?

130 Views Asked by At

I have a strange situation here. I am trying to build an application that sends http get request to the MarkLogic server. It hits the XQuery code that perform search:search(""). I am passing empty query to the search so the default relevant results are returned.
And I am using Roxy for deployment. When I call the typical Roxy deployment function by the command -

ml local deploy content.  

It loads all the document and later when I hit localhost:7040, I get the results as expected. So far so good.
Now, I override Roxy's existing method deploy_content and define my new method that calls an XQuery function, which performs xdmp:document-load() to load all the data to the content database. Here is the code snippet -

declare function loadTS:load($path) {
    let $result :=
        for $d in xdmp:filesystem-directory($path)//dir:entry
            let $log := xdmp:log(fn:concat("$d-->",xdmp:describe($d)))
            return xdmp:document-load($d//dir:pathname,
                <options xmlns="xdmp:document-load">
                    <uri>{fn:concat("/",$d//dir:filename)}</uri>
                    <permissions>{xdmp:default-permissions()}</permissions>
                    <format>xml</format>
                    <collections>
                        <collection>all</collection>
                    </collections>
                </options>)
     return $result
};

Now, when I hit the application I get 0 result, while the same code works fine from query console. I think this is related to roles and privileges concept because when I provide the admin role to the newly created user from roxy I get the result as expected. I do not want to provide admin role to the default users that will be using my application later on. So what modification I need to do in terms of roles, privileges and authentication that will solve my problem?
Note: when I hit localhost:7040 it doesn't ask for authentication.

ml.app-role:xyz-role  

Is there a function to get all the default permissions under this user's role.
This is the user used for app server as it's more a vanilla install.
The user used for query console is admin.
I ran the command xdmp:document-get-permissions() to one of the load document but it returned empty sequence.
xdmp:document-get-permissions("/a-ha+Take-on-Me.xml").
authentication-method=application-level

2

There are 2 best solutions below

3
On

David has made good points, but I think I know what is happening..

When you run ml local deploy content with an out of the box Roxy app, it uploads files to your content-db while explicitly setting document permissions for app-role. It applies at least read and update permissions, maybe also execute.

If you override the built-in deploy content with custom code, and don't use Roxy internal methods like load_data, you have to apply those permissions yourself. Using xdmp:default-permissions() is probably not good enough, as by default Roxy deploys using admin, and that usually doesn't have default permissions defined, nor would it be likely that they would be read/update permissions for the app-role of the app you happen to be working with.

Most elegant way out would be to use an app-specific upload user, with the correct default permissions. You would have to configure that yourself, and then somehow make sure Roxy uses it.

An easier way out is to replace xdmp:default-permissions() in your loadTS:load function with explicit xdmp:permission calls, for either a hardcoded xyz-role, or better $app-name || "-role" where $app-name would be loaded via src/app/config/config.xqy, or you pass $app-name through from your custom deploy_content.

HTH!

2
On

You state alot, but you never mention anything much about the security side of things:

  • The user you deploy with?
  • The default permissions as listed under that user's role(s)?
  • The user used for the app server?
  • The user used for query console?
  • The actual permissions attached to a sample document?

To fast track this help, I'll answer assuming a very vanilla install of ML and Roxy:

  • You are likely using Query console as admin.
  • You are likely using
  • Roxy's deployer as admin. You are likely using another user via the application server.

Your code above uses the default permissions of the user through Roxy. If admin, then there may be no default permissions because admin circumvents almost all security (including even needing a write permission on documents).

The big thing to look at is : xdmp:document-get-permissions() on one of the documents.

Anser the following question: Does your application user have read access to the document? If not, adjust your approach above to insert documents with more appropriate permissions).

No longin needed? That is because you have set the login to application level and are likely using just the default user from Roxy. Need authentication? Change to digest and define more users/roles in the Roxt xml config.

What roles are needed? Well, you need at least one user (non-admin) with trights to use your aplpication and read and write access to your documents. Explainig more than that will make too many assumptions. You need to understand the security model and make your own choices. But as an example, create 'user1' with a password and a role 'user1' and also give this access to the role for your app user as defined with Roxy and set authentication to digest. Now you have authentication and a user that can use your app with a password. Change your document load script above to give read/write access of loaded documents to the user1 role.

Now you have an app with:

  • A user to log in with
  • Auhentication
  • Doucments loaded that can be read by that user (and modified).

This will give you the absolute basics. It is still not production ready, because your default user (non login app user) should have minimum priviliges and the rest moved to your login user, for example.

Not enough to fix things? Answer the questions I mention above and there will be more for people to assist with.