security.xqymodule, control access to functions you write.
Every installation of MarkLogic Server includes a set of pre-defined execute privileges. You can view this list either in the Admin Interface or in Appendix B: Pre-defined Execute Privileges of the Administrator's Guide.
http://my/privs/allow-display-salary) to the execute privilege.
display-salaryXQuery function, include an xdmp:security-assert call to test for the
allow-display-salaryexecute privilege as follows:
You can also control access to specific HTTP, WebDAV, ODBC, or XDBC servers using an execute privilege. Using the Admin Interface, you can specify that a privilege is required for server access. Any users that access the server must then possess the specified privilege. If a user tries to access an application on the server and does not possess the specified privilege, an exception is thrown. For an example of using this technique to control server access, see Example: Using the Security Database in Different Servers.
To create or update a document and add it to a collection, the
unprotected-collections privilege is required. You also need a role corresponding to an insert or update permission on the document. For a protected collection (a protected collection is created using the Admin Interface), you either need permissions to update that collection or the
any-collection execute privilege. If the collection is an unprotected collection, then you need the
unprotected-collections execute privilege. For details on adding collections while creating a document, see the documentation for xdmp:document-load, xdmp:document-insert, and xdmp:document-add-collections in the MarkLogic XQuery and XSLT Function Reference.
Amps provide users with additional authorization to execute a specific function. Assigning the user this authorization permanently could compromise the security of the system. When executing an amped function, the user is part of an amped role, which temporarily grants the user additional privileges and permissions of that role. Amps enable you to limit the effect of the additional roles (privileges and permissions) to a specific function.
For example, a user may need a count of all the documents in the database in order to create a report. If the user does not have read permissions on all the documents in the database, queries run by the user do not 'see' all the documents in the database. If you want anyone to be able to know how many documents are in the database, regardless of whether they have permissions to see those documents, you can create a function named
document-count() and use an amp on the function to elevate the user to a role with read permission for all documents. When the user executes the amped function, she temporarily has the necessary read permissions that enable the function to complete accurately. The administrator has in effect decided that, in the context of that
document-count() function, it is safe to let anyone execute it.
Amps are security objects and you use the Admin Interface to create them. Amps are specific to a single function in a library module, which you specify by URI and local name when creating the amp. You can only amp a function that resides in a library module stored in the
Modules directory (
Modules database or in the
Modules directory because these locations are trusted. Allowing amped functions from under a server root or from functions submitted by a client could compromise security. For details on creating amps, see the 'Security Administration' chapter of the Administrator's Guide.