Issue with caldav behind reverse proxy in a subfolder

[mpadwick]

I'm trying to get Baikal working behind a reverse proxy in http://server.domain.com/davcal

I have managed to get the web gui working some what via setting the option base_uri in the baikal.yaml file. Initial page works well, but after hitting login and providing the admin account the server redirects me to http://server.domain.com/admin. Where the correct URI should be /davcal/admin

It also looks like the dav.php file dose not like being called via /baikal/dav.php

I've tried running both Nginx and Caddy as reverse proxy web servers with out any look. My current config is running Caddy

:443 {
        #tls /etc/ssl/private/cert.crt /etc/ssl/private/key.key
        #tls /etc/ssl/private/cert.pem /etc/ssl/private/key.pem
        # or:
        tls /etc/ssl/private/cert.pem /etc/ssl/private/cert.key

        log {
                level DEBUG
        }

        redir /.well-known/carddav /baikal/dav.php 301
        redir /.well-known/caldav /baikal/dav.php 301
        redir /baikal /baikal/ 301

        handle_path /baikal/* {
#               uri /baikal/* strip_prefix /baikal
#               uri replace /baikal/ /
                reverse_proxy http://baikal {
                        header_up Host {http.request.host}
                        header_up X-Real-IP {http.request.remote}
                }
        }
        handle /admin/* {
                reverse_proxy http://baikal {
                        header_up Host {http.request.host}
                        header_up X-Real-IP {http.request.remote}
                }
        }

        handle_path /* {
                # Set this path to your site's directory.
                root * /usr/share/caddy

                # Enable the static file server.
                file_server
        }
}

Baikal:

system:
    configured_version: 0.9.3
    timezone: Europe/
    card_enabled: true
    cal_enabled: true
    dav_auth_type: Digest
    admin_passwordhash: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
    failed_access_message: 'user %u authentication failure for Baikal'
    auth_realm: BaikalDAV
    base_uri: '/baikal/'
    invite_from: [email protected]
database:
    sqlite_file: /var/www/baikal/Specific/db/db.sqlite
    mysql: false
    mysql_host: ''
    mysql_dbname: ''
    mysql_username: ''
    mysql_password: ''
    encryption_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxx

When accessing /baikal/dav.php

<d:error>
<s:sabredav-version>4.3.1</s:sabredav-version>
<s:exception>LogicException</s:exception>
<s:message>
Requested uri (/dav.php) is out of base uri (/baikal/dav.php/)
</s:message>
</d:error>

What I'm I doing wrong?

[mpadwick]

I have found a some what working work around

By changing the the base_uri to base_uri = '' and adding the following to my caddy config

        @baikal_agent {
                header User-Agent *dav*
        }
        rewrite @baikal_agent /baikal/{uri}

But the the web gui is not 100% some things are not showing up as they should. This might be a starting point, and hopefully some one has some pointers to get this working fully

[ckulka]

I like the commit from @jtsymon, it's very straight-forward and simple.

Not sure yet if/how to incorporate that into the images, either

1. with documentation, explaining how to add a /docker-entrypoint.d/50-add-url-prefix.sh file to update the /etc/nginx/conf.d/default.conf file
2. with a container variable that updates the default.conf file on container startup
3. parsing the base_uri value out of the baikal.yml file and updating default.conf file on container startup

[n00b12345]

I think including a self signed certificate might improve things for a lot of users. At the end of the day, there's no tinkering involved here once the setup is up and running and so, a self signed certificate would work fine.

Linuxserver io image of Nextcloud, for example, includes a self signed certificate.

Kindly consider including something like that if it isn't too much trouble.

[ckulka]

Hi @n00b12345,

I think that's a separate ask unrelated to this - if you want, then let's capture this in a new issue.

Btw: the Apache httpd container image comes with a self-signed certificate. It's not something I personally actually like, but we can discuss this in the separate issue.

[n00b12345]

Hi @n00b12345,

I think that's a separate ask unrelated to this - if you want, then let's capture this in a new issue.

Btw: the Apache httpd container image comes with a self-signed certificate. It's not something I personally actually like, but we can discuss this in the separate issue.

Thank you so much for responding. I have created a discussion thread.