kanboard: Nginx reverse proxing on sub location not working with kanboard container

This issue is:

  • Bug report
  • Feature request
  • Improvement

Actual behaviour

When configuring nginx to connect to the exposed port of the kanboard container, the connection fails as I cannot set a base url in kanboard. I tried setting the application URL in the settings, but it does not seem to help.

As a result, when I connect to https://website.com/kanboard I get redirected to https://website.com/login , and this does not work. If I force https://website.com/kanboard/login, I get a web page without CSS and that does not proceed further.

Expected behaviour

I am able to set a base url to allow for reverse proxing, or I can configure my proxy server in a way that works as expected

Configuration

  • Kanboard version: 1.2.7
  • Database type and version: as in the docker container
  • PHP version: as in the docker container
  • OS: Debian 9
  • Browser: Firefox

My nginx configuration is now:

# Kanboard
location ~ ^/kanboard {
    proxy_pass http://127.0.0.1:99;
    proxy_set_header    Host            $host;
    proxy_set_header    X-Real-IP       $remote_addr;
    proxy_set_header    X-Forwarded-for $remote_addr;
}

but I already tried many many combinations without success.

About this issue

  • Original URL
  • State: open
  • Created 5 years ago
  • Reactions: 6
  • Comments: 20 (5 by maintainers)

Commits related to this issue

Most upvoted comments

Another workaround here.

  1. set KANBOARD_URL to your external URL in config.php
<?php

define('KANBOARD_URL', 'http://external.foo.bar/kanboard/');
  1. configure the outer nginx (suppose kanboard is exporting at port 8400)
location /kanboard/ {
    proxy_pass http://localhost:8400;
    location /kanboard/assets/ {
        proxy_pass http://localhost:8400/assets/;
    }
}

Note the proxy_pass directive here. One url has URI part (http://localhost:8400/assets/) and the other one doesn’t (http://localhost:8400). In this setup, nignx will rewrite the request passed down to the inner nginx in container like this:

/kanboard/login -> /kanboard/login
/kanboard/assets/foo -> /assets/foo

By this we can bypass the /assets route issue.

I have a fix for this in my fork of kanboard. As far as I can tell using my personal board it works fine without breakages:

freespace@0179701

Simply define KANBOARD_URL in config.php. Make sure to use a trailing /, e.g.

define('KANBOARD_URL', 'https://example.com/kanboard/');

Thanks for your fix! It took me one step in the right direction, although I now have trouble loading css and js.

Loading failed for the <script> with source “http://xxxx/kanboard/assets/js/app.min.js?1580309679”.

I get a 404 if I try the full url to the js file. Any ideas?

EDIT: we solved it. using kubernetes with traefik as ingress controller. added traefik.ingress.kubernetes.io/rule-type: PathPrefixStrip to the ingress annotations and everything loads!

Kanboard has a config variable KANBOARD_URL in which you define your kanboard installation URL. You can configure this on docker by setting those values on a config.php file inside your data volume, like this:

<?php
// Your Kanboard base URL, example: http://demo.kanboard.net/ (used by email notifications or CLI scripts)
define('KANBOARD_URL', 'https://your.domain.com/your/kanboard/path');

The problem is that kanboard only uses this variable to insert its value on the database (application_url on settings table) when you install it.

Try one of these things:

  • run the following update on your kanboard database, setting the value according to your installation. update settings s set s.value = 'https://your.domain.com/your/kanboard/path/' where s.option = 'application_url'; OR
  • start your docker container on /, login as admin, Settings > Application settings, change Application URL to the actual url you will access kanboard, save

Yes, I agree. This is a workaround. If it works and the problem is just this setting, it will be easy to change the code to use this variable over the database value.

You will likely agree that this is anything but deployment friendly. Can’t the env var just override all other settings? I mean, it will only really be set in case it’s needed. And then it’s always the preferrable setting.

To avoid this being closed due to inactivity, just like https://github.com/kanboard/kanboard/issues/3534#issuecomment-375825780 - Please implement a base path feature, so we can run this behind a reverse proxy with locations.