[GH-ISSUE #1055] [FEATURE REQUEST] Support configuration of URL path for web interface #379

New issue

Closed

opened 2026-02-27 08:16:57 +03:00 by kerem · 2 comments

kerem commented

2026-02-27 08:16:57 +03:00

Owner

Originally created by @Zepmann on GitHub (Dec 5, 2024).
Original GitHub issue: https://github.com/lldap/lldap/issues/1055

Motivation
Normally LLDAP is offered through a regular (local) URL, such as:
http://localhost:17170

A reverse proxy on the same host can be used to offer LLDAP and other services through a single port. Ideally, in this scenario it also adds TLS support and some kind of frontend authentication site before LLDAP's login page can be accessed. The URL of LLDAP could be:
https://lldap.domain.example

Imagine the situation in which it is not possible to host lldap on a subdomain. In that case, the URL could be:
https://domain.example/lldap

LLDAP currently does not allow this. Setting http_url = "http://localhost:17170/lldap" does not offer the static web files (and possibly other files) under the proper path. While LLDAP will try to load the files from http://localhost:17170/lldap/static, the files are not offered from there, resulting in a 404 error for main.js when accessing the login page (and therefore, an unusable web interface).

Describe the solution you'd like
Including a path in http_url should ensure that all web resources are offered through that path, so that the full web interface is usable through that path (without any reference to web resources outside of that path).

Describe alternatives you've considered
A workaround is NOT adjusting http_url (just leave it on http://localhost:17170) and letting a reverse proxy or a web server rewrite the URL requests from the client to LLDAP and the responses from LLDAP to the client. An example configuration snippet for nginx:

        location ^~ /lldap {
            # URL to LLDAP without trailing slash (see http_url in lldap.toml)
            proxy_pass http://localhost:17170;

            set $app 'lldap';

            # Strip /lldap from the URL path before the URL is passed to LLDAP
            rewrite ^/lldap$ / break;
            rewrite ^/lldap/(.*)$ /$1 break;

            # Add /lldap to location headers offered by LLDAP before offered to the client
            proxy_redirect ^ /$app;

            # Sub filters to replace hardcoded paths in web content
            proxy_set_header Accept-Encoding "";  
            sub_filter_once off;
            sub_filter_types *; 
            sub_filter 'href="/"' 'href="/$app"';
            sub_filter '\'/pkg/' '\'/$app/pkg/';  
            sub_filter '"static/' '"$app/static/';
        }

This seems to allow the web interface to work fully, aside of spinner.gif being unable to load. It is still requested from the root path, and I believe this is done by some WebAssembly code which is not easy to replace using a sub filter. It concerns a missing loading animation that is not strictly required.

This is a dirty workaround and could break in the future if LLDAP changes the web paths that are used. Official support would be welcome.

Originally created by @Zepmann on GitHub (Dec 5, 2024). Original GitHub issue: https://github.com/lldap/lldap/issues/1055 **Motivation** Normally LLDAP is offered through a regular (local) URL, such as: `http://localhost:17170` A reverse proxy on the same host can be used to offer LLDAP and other services through a single port. Ideally, in this scenario it also adds TLS support and some kind of frontend authentication site before LLDAP's login page can be accessed. The URL of LLDAP could be: `https://lldap.domain.example` Imagine the situation in which it is not possible to host lldap on a subdomain. In that case, the URL could be: `https://domain.example/lldap` LLDAP currently does not allow this. Setting `http_url = "http://localhost:17170/lldap"` does not offer the static web files (and possibly other files) under the proper path. While LLDAP will try to load the files from `http://localhost:17170/lldap/static`, the files are not offered from there, resulting in a 404 error for main.js when accessing the login page (and therefore, an unusable web interface). **Describe the solution you'd like** Including a path in `http_url` should ensure that all web resources are offered through that path, so that the full web interface is usable through that path (without any reference to web resources outside of that path). **Describe alternatives you've considered** A workaround is **NOT** adjusting http_url (just leave it on `http://localhost:17170`) and letting a reverse proxy or a web server rewrite the URL requests from the client to LLDAP and the responses from LLDAP to the client. An example configuration snippet for nginx: ``` location ^~ /lldap { # URL to LLDAP without trailing slash (see http_url in lldap.toml) proxy_pass http://localhost:17170; set $app 'lldap'; # Strip /lldap from the URL path before the URL is passed to LLDAP rewrite ^/lldap$ / break; rewrite ^/lldap/(.*)$ /$1 break; # Add /lldap to location headers offered by LLDAP before offered to the client proxy_redirect ^ /$app; # Sub filters to replace hardcoded paths in web content proxy_set_header Accept-Encoding ""; sub_filter_once off; sub_filter_types *; sub_filter 'href="/"' 'href="/$app"'; sub_filter '\'/pkg/' '\'/$app/pkg/'; sub_filter '"static/' '"$app/static/'; } ``` This seems to allow the web interface to work fully, aside of spinner.gif being unable to load. It is still requested from the root path, and I believe this is done by some WebAssembly code which is not easy to replace using a sub filter. It concerns a missing loading animation that is not strictly required. This is a dirty workaround and could break in the future if LLDAP changes the web paths that are used. Official support would be welcome.

kerem

2026-02-27 08:16:57 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 08:16:58 +03:00

Author

Owner

@nitnelave commented on GitHub (Dec 5, 2024):

There has been a discussion of that there: https://github.com/lldap/lldap/issues/247
It's not officially supported, but it's possible (not too hard)

@nitnelave commented on GitHub (Dec 5, 2024): There has been a discussion of that there: https://github.com/lldap/lldap/issues/247 It's not officially supported, but it's possible (not too hard)

kerem commented

2026-02-27 08:16:58 +03:00

Author

Owner

@Zepmann commented on GitHub (Dec 5, 2024):

I did not find that one. I was searching for specific URL support, and not explicit reverse proxy support. Closing this one since it is clearly a duplicate. Thanks, @nitnelave!

@Zepmann commented on GitHub (Dec 5, 2024): I did not find that one. I was searching for specific URL support, and not explicit reverse proxy support. Closing this one since it is clearly a duplicate. Thanks, @nitnelave!

kerem referenced this issue

2026-02-27 09:09:27 +03:00

[PR #379] [MERGED] fix: use async api for email sending #708