Chapter 19. Internet Services

Any non-disabled SQL account with the U_DAV_ENABLE column set to non-zero is a valid DAV account. The administration user interface provides a check box for enabling DAV access and will make a default home collection etc. Alternately, regular SQL can be used for setting the DAV flag on. The DAV API or protocol requests can be used for creating collections and resources for the user.

Any non-disabled SQL account with the U_DAV_ENABLE column set to non-zero is a valid DAV account. The administration user interface provides a check box for enabling DAV access and will make a default home collection etc. Alternately, regular SQL can be used for setting the DAV flag on. The DAV API or protocol requests can be used for creating collections and resources for the user.

There is an automatically created initial DAV enabled account called "dav". This has general administration privileges over all DAV.

There are four predefined DAV accounts.

	Note:
	The WebDAV admin user "dav" can be deleted. However, after a server restart the initial setting of this account will be added again.

	Important
	It is strongly recommended that the Virtuoso administrator change the default account password of the DAV administrative user after installation.

USER_CREATE ('user', 'userpassword',
  vector ('SQL_ENABLE', 0, 'DAV_ENABLE', 1, 'PERMISSIONS', '110100000RR', 'DISABLED', 0));

DAV_ADD_USER ('user', 'userpassword', '110100000RR', 0, '/DAV/home/user/',
  'Full User Name', 'user@example.com', 'dav', 'davpassword');

      GRANT ADMINISTRATORS TO "user";

      USER_GRANT_ROLE ('user', 'administrators');

    USER_SET_OPTION ('user', 'DISABLED', 1);

    DAV_DELETE_USER ('user' , 'dav', 'davpassword');

	See Also:
	WS & DAV System Tables

Virtuoso WebDAV offers two types of authentication dependent on the connecting clients abilities. These are:

¶

Basic Authentication

Basic Authentication is a widely used, industry-standard method for collecting user name and password information. The following steps outline how a client is authenticated using Basic authentication:

1. The client browser displays a dialog box for a user to enter a user name and password (his/her credentials).

2. The client browser then attempts to establish a connection to the server using the user's credentials. The clear text password is Base64-encoded before it is sent over the network.

3. If a user's credentials are rejected, the client may re-display the authentication dialog box to re-enter the user's credentials. Failing to supply correct details will terminate the connection, reporting an error to the user.

4. When Virtuoso verifies that the user name and password are valid, a connection is established.

The advantage of Basic authentication is that most clients support it. The disadvantage is that it transmits passwords in an unencrypted form. Simple network monitoring can easily reveal your password. Basic authentication is not recommended unless you are confident that the connection between the user and Virtuoso is secure.

	Note:
	Base64 encoding is not encryption. A Base64-encoded password can be easily intercepted by a network sniffer and easily decoded.

¶

Digest Authentication

Digest authentication provides a security improvement over Basic authentication in how a user's credentials are sent across the network. Digest authentication transmits credentials across the network as an MD5 hash, or message digest, where the original username and password cannot be deciphered from the hash. Digest authentication relies on the HTTP 1.1 protocol as defined in RFC 2617, which not all browsers support.

The following steps outline how a client is authenticated using Digest authentication:

Figure 19.1. Digest Authentication

1. The client requests a file or connection from Virtuoso.

2. Virtuoso challenges the request, informing that client: Digest is in use, what the realm name is.

3. The client prompts the user for credentials. The client creates an MD5 hash of the credentials and the realm name and resubmits the request, this time supplying the MD5 hash.

4. If Virtuoso approves the credentials then the resource or connection is granted to the client, and the data is returned.

Virtuoso supports a special type of WebDAV resources, a redirect reference resource, named WebDAV links. This is to extend the WebDAV service to allow multiple access paths to existing resources.

As with conventional HTTP, the redirect reference simply responds to the client with an HTTP/1.1 302 (Found) status code, redirecting the client to a different resource, the target specified in the redirect resource, using the Location: header. This behavior is equivalent to UNIX symbolic links. A redirect reference makes it possible to access the target resource indirectly through any URI mapped to the redirect reference resource. The integrity is not guaranteed for associated redirect reference resources.

WebDAV links do not provide a way to circumvent WebDAV security or virtual directories. The target resource must be directly available to the client being redirected.

WebDAV links are achieved by adding a special WebDAV property, 'redirectref ', whose value must contain the reference target URL.

WebDAV link targets are not limited to the WebDAV repository, and may target any HTTP accessible resource.

The WebDAV links can be made with DAV API function DAV_PROP_SET() , or can be done via the Content Management interface of the Admin UI. In the admin UI select WebDAV/WebDAV Services/Content Management and press on the Create Link button to create a link. In the form choose the target, permissions, owner and enter the name of the link. Pressing the Add button will create the new link in the current WebDAV folder.

SQL> select DAV_RES_UPLOAD ('/DAV/a/b.html','','','110100000NN', 'dav', 'nobody', 'dav', 'dav');

SQL> DAV_PROP_SET ('/DAV/a/b.html', 'redirectref', '/c/d/f.html', 'dav', 'dav');

	See Also:
	DAV Add and Update functions and DAV Manipulation functions .

WebDAV links behaviour in resource manipulation requests.  When some link is moved the target will have the same properties as source, ie. it will be a link. When a copy operation is made the target will have content of the reference i.e. it will be a resource, not a link. Delete operation on link will remove only the redirect reference resource, not the referenced target itself. Content upload requests will change the content of the referenced target.

The WebDAV resources have two sorts of access right permissions. 'Classical' UNIX filesystem style permissions let assign different permissions for owner user, owner group and public access. Access Control Lists (ACLs) let assign permissions in more flexible Windows style but they are less convenient for simple tasks. Both set of permissions can be applied to the same resource or collection. In any case, each resource or collection (directory/folder) can have defined Read, Write and Execute permissions. The write permission applies to operations which perform content or property change or locking as PUT, PROPPATCH, MOVE, destination URI in COPY, LOCK, UNLOCK, DELETE, MPUT and MUPDATE. The read permission applies to read operations as GET, POST, PROPFIND, HEAD, source URI in COPY and MGET; read permission is also required for any write operation.

	See Also
	RFC2518 for more details of methods/operations

The execute permission applies only to the active content stored in the WebDAV domain. If a VSP or VSPX page stored in a WebDAV domain has execute permissions then retrieval of that page will perform execution of active content. Note also a special flag to the virtual directory which can override the execution flags for active pages. (for the details how this flag can be set see 'options' in VHOST_DEFINE() function). If such a flag is set to the virtual directory, then all active pages under that directory (direct and indirect children) will be treated as execution flag of the resource is set. In almost any case, user should have both read and execute permissions to access active content.

Resources with the following extensions are treated as executable content: .vsp, .vspx, .xml if this has the XML template properties set. Any other extension is also considered executable if there is a corresponding WS.WS."__http_handler_<extension>" PL procedure.

The UNIX style permissions can be set for user, group or public access. ACL consists of records called Access Control Entries (ACEs). Every ACE allow or deny some sorts of access to an individual user or to a group. Resource owner or administrator can add an "explicit" ACE to the ACL of particular resource or "recursively" add "implicit" ACEs to every resource and subcollection of some collection. The server checks permissions in the following order:

According to these rules, the order of records in ACL is important. ACEs are ordered following two rules: "deny" ACEs has higher priority than "allow" ACEs; "local" rules has higher priority that "global":

New resources and collections take their initial permissions from the user default permissions mask, U_DEFAULT_PERMS of SYS_USERS. (see: WebDAV Users Administration ). In the case of a resource created as public or a collection mask of '110110110' (equivalent of UNIX 'rw-rw-rw'), then everybody can read and write it.

'111110100'

Every resource or collection has two additional flags in permissions, that instruct the server whether resources should be indexed for free-text search and whether resources should be parsed to extract metadata:

Free-text indexing flag can take one of three values: "N", "R" and "T". If a resource has this flag set to R or T then the resource will be free-text indexed. If a collection has this flag set to T then resources directly contained within the collection will be free-text indexed. If a collection has this flag set to R then resources contained within the collection will be free-text indexed, and the setting will be applied to all members and collections underneath recursively. New resources and collections acquire this setting from their parent collection.

Similarly, metadata extraction flag can take one of three values: "N", "R" and "M". If a resource has this flag set to R or M then its metadata are extracted. If a collection has this flag set to T then metadata are extracted from resources directly contained within the collection. If a collection has this flag set to R then metadata are extracted from resources contained within the collection, and the setting will be applied to all members and collections underneath recursively. New resources and collections acquire this setting from its parent collection.

When a Virtuoso server has a URIQA default host setting, it will make metadata extracted from DAV resources available for querying via SPARQL. All metadata for public readable DAV resources are stored in a system graph. The graph IRI is composed from the DAV path of the resource and the URIQA default host name.

see DefaultHost in the URIQA section of the virtuoso.ini file, described in the URIQA section of the documentation for details on configuration.

The automatic maintenance of the SPARQL queryable metadata can be disabled and enable using the function DB.DBA.DAV_REPLICATE_ALL_TO_RDF_QUAD. An argument of 1 enables this and a 0 disables this. The setting stays in effect until it is changed with the same function. For new database, the feature is on by default. Old databases are by default upgraded to have a SPARQL queryable DAV metadata graph upon startup if the URIQA default host name is defined.

If the URIQA default host name changes, the RDF graph can be updated by simply re-enabling the feature. This will adjust the graph and resource IRI's.

If the URIQA default name of the host is example.com, then, the graph will be http://example.com/DAV .

The IRI's of DAV resources will be like http://example.com/DAV/docsrc/XMLDOM.xml , meaning that these are directly usable from a user agent for accessing the resource.

SQL> sparql select ?s ?o from <http://example.com/DAV> where {?s <http://www.openlinksw.com/schemas/DAV#ownerUser> ?o};
s                                                                                 o
VARCHAR                                                                           VARCHAR
_______________________________________________________________________________

http://example.com/DAV/docsrc/2pc.xml                                          mailto:somebody@example.domain
http://example.com/DAV/docsrc/Virtdocs.spp                                     mailto:somebody@example.domain

SQL> sparql select ?p ?o from <http://example.com/DAV> where {<http://example.com/DAV/docsrc/2pc.xml> ?p ?o};
p                                                                                 o
VARCHAR                                                                           VARCHAR
_______________________________________________________________________________

http://purl.org/dc/terms/created                                                  2006-05-23 15:10:32
http://purl.org/dc/terms/modified                                                 2006-05-23 15:10:32
http://www.openlinksw.com/schemas/DAV#ownerUser                                   mailto:somebody@example.domain
http://purl.org/dc/terms/extent                                                   7850

The examples above show how simple SPARQL queries can be used to retrieve information about DAV resources.

The properties supported for all public readable resources are:

http://purl.org/dc/terms/created - The creation date as SQL datetime.

http://purl.org/dc/terms/modified - Modification time as SQL datetime.

http://www.openlinksw.com/schemas/DAV#ownerUser - The contents of u_e_mail in sys_users for the SQL account owning the resource. This has the protocol prefix mailto:, as in mailto:somebody@example.com.

http://purl.org/dc/terms/extent The size of the resource in bytes as a SQL integer.

http://www.openlinksw.com/schemas/DAV#tag - There is one triple for each public tag of the DAV resource. The value is the string of the tag as a SQL string.

http://www.w3.org/1999/02/22-rdf-syntax-ns#type - The RDF schema for MIME-type of of the DAV resource. If the resource is not recognized as one of the below, this predicate will be omitted.

Additional predicates may exist as a result of resource type specific metadata extraction.

The Virtuoso WebDAV implementation provides a set of special attributes (properties) for the resources to manipulate the retrieval of XML documents. Properties can be set generate dynamic content based on XML/SQL queries. Special properties can also be applied to WebDAV folders for storing XML data in a special pre-parsed persistent XML format.

The following special properties are supported: