Configuring DAV server

Introduction

Aurora Files uses DAV server internally, for storing data and syncing it with mobile and other clients. Typically, it will work out of the box, but you might need to perform additional reconfiguration, depending on your needs and specific environment.

By default, URL used for DAV sync is not supplied in product configuration. Standard URL would look like http://www.yourdomain.com/files/dav.php/ (with the trailing slash required), where http://www.yourdomain.com/files/ is URL pointing to Aurora Files installation. For this to work with Apache, you might need to recheck that AcceptPathInfo is not disabled in Apache configuration.

It is strongly advised to configure your web server so that URLs are rewritten and easier to enter from, say, mobile device. Some DAV clients (iOS and MacOS X, for example) won't work with DAV URLs ending with /dav.php/ so you need to ensure a dedicated subdomain or port is used for DAV access. And we recommend setting up SSL on web server so the URLs are accessed via https rather than http. Upon reconfiguring your web server accordingly, be sure to specify the correct URL in "Mobile sync" tab of admin interface.

There's also an alternative solution which assumes configuring .well-known access (see below).

Configuring Apache

For Apache web server, URL rewriting is ensured by adding virtual host with the following configuration:

<VirtualHost>
DocumentRoot /var/www/files/
RewriteEngine On
RewriteRule ^/(.*)$ /dav.php [L]
</VirtualHost>

DocumentRoot should point to root directory of Aurora Files installation location. Standard port 80 is used. Many applications, however, treat port 8008 as a default one, configuration would look a bit different in this case:

NameVirtualHost *:8008
Listen 8008
<VirtualHost>
DocumentRoot /var/www/files/
RewriteEngine On
RewriteRule ^/(.*)$ /dav.php [L]
</VirtualHost>

Also, you need to make sure http methods required by DAV server are not blocked in web server configuration. If there are LimitExcept directives used in VirtualHost or Directory containers, those should be removed.

Configuration for nginx

For nginx webserver, the following configuration ensures /dav.php/ access works as expected:

location ~ ^(.+\.php)(.*)$ {
    fastcgi_split_path_info ^(.+?\.php)(/.*)$;
    fastcgi_pass   unix:/run/php/php-fpm.sock;
    include        fastcgi_params;
    fastcgi_param  SCRIPT_FILENAME $request_filename;
    fastcgi_param  PATH_INFO $fastcgi_path_info;
}

If you choose to use a separate domain or subdomain for DAV access, configuration would look like:

server  {
    listen 80;
    server_name dav.server.com;
    root /var/www/html;
    index dav.php;
    location = / {
        try_files @dav @dav;
    }
    location / {
        try_files $uri $uri/ @dav;
    }
    location @dav {
        fastcgi_pass   unix:/run/php/php-fpm.sock;
        include        fastcgi_params;
        fastcgi_index  dav.php;
        fastcgi_param  SCRIPT_FILENAME $document_root/dav.php;
    }
}

Configuration for IIS

In case of IIS on Windows, you can define the list of allowed methods under Handler Mappings > PHP_via_FastCGI > Request Restrictions... > Verbs tab. Try supplying the following list there: OPTIONS,GET,HEAD,DELETE,PROPFIND,PUT,PROPPATCH,COPY,MOVE,MKCOL,REPORT

One of our customers reported that, to make things work, they needed to supply the following list: GET,HEAD,POST,DEBUG,PUT,DELETE,PATCH,OPTIONS,PROPFIND, COPY,LOCK,MKCOL,MOVE,PROPPATCH,UNLOCK,TRACE,REPORT

Configuring .well-known access

Another good way of ensuring proper mobile sync setup is to use .well-known access. Various clients, including the one used in iOS, attempt to determine correct DAV URL by sending request to a special subdirectory name, and we can handle those requests to redirect to DAV server.

In case of Apache, configuration would look like:

<IfModule>
RewriteEngine on
RewriteRule .* - 
Redirect 301 /.well-known/carddav /webmail/dav.php/
Redirect 301 /.well-known/caldav /webmail/dav.php/
</IfModule>

or just supply the following in .htaccess file:

Redirect 301 /.well-known/carddav /webmail/dav.php/
Redirect 301 /.well-known/caldav /webmail/dav.php/

For nginx, the following configuration should help:

location / {
   rewrite ^/.well-known/carddav /webmail/dav.php/ redirect;
   rewrite ^/.well-known/caldav /webmail/dav.php/ redirect;
}

NB: With configuration settings supplied that way, you'll need to use your Aurora Files installation URL as DAV URL, without any suffixes etc.

Using DAV on cPanel

In case when Aurora Files was installed via cPanel installer using direct embedding approach, using DAV is not an option as it conflicts with webmail authentication layer of cPanel.

If you'd like to use Mobile Sync, consider using alternative installation method which essentially means setting up regular product package.

To allow for using DAV, create .htaccess file in WebMail directory and place the following content there:

<IfModule> 
        RewriteEngine on 
        RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L] 
</IfModule>

If this still doesn't work for you, you might need to recheck ModSecurity configuration which could be blocking some of HTTP methods required by DAV.

Setting base product URL

As of version 9.7.1, DAV server sends out invites out when event is added or edited via DAV client. To ensure the invite links in email messages are correct, you need to set "ProductUrlForExternalClients" value in data/settings/modules/Dav.config.json configuration file to base URL of Aurora Files installation.

Username VS email as login

If your Aurora Files installation and your mail server are configured to accept usernames as login, rather than full email address, you'll need to adjust DAV server accordingly as well. Check data/settings/modules/Dav.config.json configuration file:

    "UseFullEmailForLogin": [
        true,
        "bool",
        null,
        "If true, full email address is used for DAV login; if fals, username part of email address is used" 
    ],
    "DomainForLoginWithoutEmail": [
        "",
        "string",
        null,
        "If UseFullEmailForLogin is false, this value denotes domain part of user's email address" 
    ]

Set UseFullEmailForLogin to false and supply your email domain as DomainForLoginWithoutEmail parameter.

Troubleshooting

In general case, DAV access should work right away. However, in some cases, you might need to reconfigure your web server additionally.

If it looks like the connection to DAV server is established, but your account credentials are not accepted, you can try logging into DAV server via your web browser. That feature is disabled by default, you can enable it by setting UseBrowserPlugin to true in data/settings/modules/Dav.config.json file.

Upon changing the setting, enter your DAV URL in address bar of web browser and enter credentials for any Aurora Files account. If they're rejected and prompt appears again, that means there's a configuration issue with your web server.

In case if you use IIS, or your system is configured to use PHP through CGI or FastCGI, you'll probably need to perform additional configuration. Check Webservers page of DAV server documentation for details on this.

You may also need to recheck ModSecurity configuration which could be blocking some of HTTP methods required by DAV.

By default, DAV server of Aurora Files is configured for Basic authentication. If a particular client requires Digest auth, you can enable it by setting UseDigestAuth to true in data/settings/modules/Dav.config.json file.