[GH-ISSUE #247] Support for reverse proxies #86

New issue

Closed

opened 2026-02-27 08:15:09 +03:00 by kerem · 27 comments

kerem commented 2026-02-27 08:15:09 +03:00

Owner

Copy link

Originally created by @k3nd0x on GitHub (Jul 13, 2022).
Original GitHub issue: https://github.com/lldap/lldap/issues/247

Hi,

I really appreciate your work :)
can you please add the option to change the subdirectory of the webinterface. It is much easier to reverse proxy a request to for example /lldap than to /

State now: http://0.0.0.0:17170/
Example cool for reverse proxies: http://0.0.0.0:17170/lldap/

Originally created by @k3nd0x on GitHub (Jul 13, 2022). Original GitHub issue: https://github.com/lldap/lldap/issues/247 Hi, I really appreciate your work :) can you please add the option to change the subdirectory of the webinterface. It is much easier to reverse proxy a request to for example /lldap than to / State now: http://0.0.0.0:17170/ Example cool for reverse proxies: http://0.0.0.0:17170/lldap/

kerem 2026-02-27 08:15:09 +03:00

• closed this issue
• added the
  enhancement
  good first issue
  backend
  labels

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Jul 13, 2022):

I'm not sure I understand why it makes it easier:

• If you do domain-based reverse proxy, you'll have http://lldap.example.com/foo redirecting to http://my_lldap_docker/foo
• If you do path-based reverse proxy, you'll have http://example.com/lldap/foo redirecting to http://my_lldap_docker/foo

In both cases, you don't really need help from LLDAP. What reverse proxy are you using? Maybe someone can help you with the precise config needed.

<!-- gh-comment-id:1182950479 --> @nitnelave commented on GitHub (Jul 13, 2022): I'm not sure I understand why it makes it easier: - If you do domain-based reverse proxy, you'll have http://lldap.example.com/foo redirecting to http://my_lldap_docker/foo - If you do path-based reverse proxy, you'll have http://example.com/lldap/foo redirecting to http://my_lldap_docker/foo In both cases, you don't really need help from LLDAP. What reverse proxy are you using? Maybe someone can help you with the precise config needed.

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@k3nd0x commented on GitHub (Jul 15, 2022):

I'm using apache as reverse proxy. The "problem" are the subdirectories. LLDAP provides the static/ and the pkg/ folder directly to https://example.com/static but they are at https://example.com/ldap/static.

The apache config is complex as hell:
<Location /ldap/>
ProxyPass http://:17170/
ProxyPassReverse http://:17170/

Of course i can add some rules to the apache config to catch the real directories but it is easier for everybody with a subdirector that is directly provided by the LLDAP Container :)
With a own subdomain it is no problem, but I don't want to create a own subdomain for every software :)
In the most selfhosted software solution you can change this setting (for example: grafana, icinga, promtheus, SOGo, vaulwarden...)

<!-- gh-comment-id:1185310151 --> @k3nd0x commented on GitHub (Jul 15, 2022): I'm using apache as reverse proxy. The "problem" are the subdirectories. LLDAP provides the static/ and the pkg/ folder directly to https://example.com/static but they are at https://example.com/ldap/static.  The apache config is complex as hell: <Location /ldap/> ProxyPass http://<dockerhost>:17170/ ProxyPassReverse http://<dockerhost>:17170/ </Location> Of course i can add some rules to the apache config to catch the real directories but it is easier for everybody with a subdirector that is directly provided by the LLDAP Container :) With a own subdomain it is no problem, but I don't want to create a own subdomain for every software :) In the most selfhosted software solution you can change this setting (for example: grafana, icinga, promtheus, SOGo, vaulwarden...)

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Jul 15, 2022):

I'll see if I have time for this later on, but given that it can be easily addressed with reverse proxy configuration (you just need to handle the static folder and *.html/js files), it's not very high on my list.

<!-- gh-comment-id:1185326187 --> @nitnelave commented on GitHub (Jul 15, 2022): I'll see if I have time for this later on, but given that it can be easily addressed with reverse proxy configuration (you just need to handle the `static` folder and `*.html/js` files), it's not very high on my list.

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@Roemer commented on GitHub (Oct 13, 2022):

I think getting the reverse proxy to work correctly is not that easy without a possibility to tell lldap a base-path. In fact, I do not know a working nginx configuration. So I think this should be a bit higher on the list ;)

<!-- gh-comment-id:1278216691 --> @Roemer commented on GitHub (Oct 13, 2022): I think getting the reverse proxy to work correctly is not that easy without a possibility to tell lldap a base-path. In fact, I do not know a working nginx configuration. So I think this should be a bit higher on the list ;)

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Oct 14, 2022):

I'm always open to PRs!

<!-- gh-comment-id:1278658162 --> @nitnelave commented on GitHub (Oct 14, 2022): I'm always open to PRs!

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@wailashi commented on GitHub (Oct 25, 2022):

FWIW I'm running lldap behind Traefik and https://lldap.example.com/ works fine with no modifications to lldap or base-path shenanigans.

<!-- gh-comment-id:1290599857 --> @wailashi commented on GitHub (Oct 25, 2022): FWIW I'm running lldap behind Traefik and https://lldap.example.com/ works fine with no modifications to lldap or base-path shenanigans.

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@Cyrix126 commented on GitHub (Nov 8, 2022):

nginx configuration which works for me for https://ldap.example.com

server {
    server_name ldap.example.com;

    client_max_body_size 10M;

    listen [::]:443 ssl;
    listen 443 ssl;
    ssl_certificate /etc/letsencrypt/live/ldap.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ldap.example.com/privkey.pem;

location / {
  proxy_set_header        Host $host;
  proxy_set_header        X-Real-IP $remote_addr;
  proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header        X-Forwarded-Proto $scheme;

  proxy_pass              http://localhost:17170/;

  proxy_read_timeout      600s;
  proxy_send_timeout      600s;
}
}

server {

    if ($host = ldap.example.com) {
        return 301 https://$host$request_uri;
    }


    listen 80;
    listen [::]:80;
    server_name ldap.example.com;
}

<!-- gh-comment-id:1307455143 --> @Cyrix126 commented on GitHub (Nov 8, 2022): nginx configuration which works for me for https://ldap.example.com ``` server { server_name ldap.example.com; client_max_body_size 10M; listen [::]:443 ssl; listen 443 ssl; ssl_certificate /etc/letsencrypt/live/ldap.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/ldap.example.com/privkey.pem; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://localhost:17170/; proxy_read_timeout 600s; proxy_send_timeout 600s; } } server { if ($host = ldap.example.com) { return 301 https://$host$request_uri; } listen 80; listen [::]:80; server_name ldap.example.com; } ```

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@khangp0000 commented on GitHub (Feb 14, 2023):

So I look into this a bit (because I want path reverse proxy rather than host reverse proxy). These changes would be required:

1. Add parameter (e.g. /subpath) into run command [EASY] (Server)
2. Add ::scope to all endpoint [EASY] (Server)
3. Migrate yew router app to 0.16 at least for this fix and possibly more, best scenario all the way to 0.17.0 that have all the fixes [HARD] (UI)
4. Add base tag into index html, something like:
   <base href="/subpath" />
   and fix all fetch (or rather yew's Request) call to accept the base url. We can pass around the basename field which was initialized by yew in Router, Link, e.t.c. objects [HARD] (UI)
5. (Optional) to make this fully configurable by one single config file, we have to inject the base path from Server to index.html somehow, maybe using a string template engine, or just load the whole html into memory and prepend the tag. [EASY-MEDIUM]

Also we should rename this issue to something like Add basepath support or Path based reverse proxy support because domain based reverse proxy is still working as mentioned above.

<!-- gh-comment-id:1429055503 --> @khangp0000 commented on GitHub (Feb 14, 2023): So I look into this a bit (because I want path reverse proxy rather than host reverse proxy). These changes would be required: 1. Add parameter (e.g. `/subpath`) into run command [EASY] (Server) 2. Add `::scope` to all endpoint [EASY] (Server) 3. Migrate yew router app to 0.16 at least for [this](https://github.com/yewstack/yew/pull/2177) fix and possibly more, best scenario all the way to 0.17.0 that have all the fixes [HARD] (UI) 4. Add `base` tag into index html, something like: ```<base href="/subpath" />``` and fix all `fetch` (or rather yew's `Request`) call to accept the base url. We can pass around the `basename` field which was initialized by yew in `Router`, `Link`, e.t.c. objects [HARD] (UI) 5. (Optional) to make this fully configurable by one single config file, we have to inject the base path from Server to `index.html` somehow, maybe using a string template engine, or just load the whole html into memory and prepend the <base/> tag. [EASY-MEDIUM] Also we should rename this issue to something like `Add basepath support` or `Path based reverse proxy support` because domain based reverse proxy is still working as mentioned above.

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Feb 16, 2023):

I didn't investigate this properly, but if what you say is true, then the biggest blocker I see is updating yew/yew_router. This requires a huge change in how the frontend is written (not conceptually, thankfully, but the syntax is very different). I'll open an issue for that.

<!-- gh-comment-id:1433058999 --> @nitnelave commented on GitHub (Feb 16, 2023): I didn't investigate this properly, but if what you say is true, then the biggest blocker I see is updating yew/yew_router. This requires a huge change in how the frontend is written (not conceptually, thankfully, but the syntax is very different). I'll open an issue for that.

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@infogulch commented on GitHub (Feb 25, 2023):

Not to rain on anyone's parade, but I haven't seen this stated yet... There is a cross-contamination security risk from hosting multiple applications in different paths on a single domain, which is particularly impactful in this case because lldap acts as the root of trust. I think it would be reasonable for an "opinionated, simplified LDAP" server to have the opinion that it should be hosted on its own dedicated domain.

<!-- gh-comment-id:1444868880 --> @infogulch commented on GitHub (Feb 25, 2023): Not to rain on anyone's parade, but I haven't seen this stated yet... There is a cross-contamination security risk from hosting multiple applications in different paths on a single domain, which is particularly impactful in this case because lldap acts as the root of trust. I think it would be reasonable for an "opinionated, simplified LDAP" server to have the opinion that it should be hosted on its own dedicated domain.

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Feb 25, 2023):

@infogulch could you expand on the security risk? Or do you have documents/articles that I could read about it? I'm curious

<!-- gh-comment-id:1445027850 --> @nitnelave commented on GitHub (Feb 25, 2023): @infogulch could you expand on the security risk? Or do you have documents/articles that I could read about it? I'm curious

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@infogulch commented on GitHub (Feb 26, 2023):

Sure, this comes down to basic browser security protocols like the Same-origin policy and CORS.

An example attack would be an application in a different directory is exploited (e.g. fails to sanitize a <script> element out of a user comment) making a request to an endpoint in the lldap app, and the browser happily makes the request using the lldap app's cookies. Technically speaking, if everything is set up correctly (cookies, headers, etc), I believe it's possible to make this design secure. But at best I would describe this as precarious.

Here are some stackexchange discussions about it:

Preventing insecure webapp on subdomain compromise security of main webapp

(This has links to a bunch of related discussions.)

Is security increased by using a subdomain per customer in a web-app?

The most robust strategy is to use an unrelated domain for each customer (e.g., customera.com, customerb.com). ... However, using one unrelated domain per customer makes you pay the cost of a separate domain per customer. ...

The next-most robust strategy is to use a different subdomain per customer (e.g., customera.mysite.com, customerb.mysite.com). This gets you most of the benefits of the same-origin policy, but with some caveats and holes: ...

The least robust strategy is to serve all of your customers from your same domain (e.g., mysite.com/customera, mysite.com/customerb; or mysite.com with a different login per customer). The downside of this approach is that you can no longer rely upon the browser's same-origin policy to help you keep customers separate, so now the responsibility passes to your server.

Some web app management platforms have a policy to run every app on its own subdomain, which offers a good balance of admin cost and security. For example, Cloudron, which I use.

<!-- gh-comment-id:1445464330 --> @infogulch commented on GitHub (Feb 26, 2023): Sure, this comes down to basic browser security protocols like the [Same-origin policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) and [CORS](https://developer.mozilla.org/en-US/docs/Glossary/CORS). An example attack would be an application in a different directory is exploited (e.g. fails to sanitize a `<script>` element out of a user comment) making a request to an endpoint in the lldap app, and the browser happily makes the request using the lldap app's cookies. Technically speaking, if everything is set up correctly (cookies, headers, etc), I believe it's *possible* to make this design secure. But at best I would describe this as **precarious**. Here are some stackexchange discussions about it: [Preventing insecure webapp on subdomain compromise security of main webapp](https://security.stackexchange.com/questions/24155/preventing-insecure-webapp-on-subdomain-compromise-security-of-main-webapp) (This has links to a bunch of related discussions.) [Is security increased by using a subdomain per customer in a web-app?](https://security.stackexchange.com/questions/7451/is-security-increased-by-using-a-subdomain-per-customer-in-a-web-app) > The most robust strategy is to use an unrelated domain for each customer (e.g., customera.com, customerb.com). ... However, using one unrelated domain per customer makes you pay the cost of a separate domain per customer. ... > > The next-most robust strategy is to use a different subdomain per customer (e.g., customera.mysite.com, customerb.mysite.com). This gets you most of the benefits of the same-origin policy, but with some caveats and holes: ... > > The least robust strategy is to serve all of your customers from your same domain (e.g., mysite.com/customera, mysite.com/customerb; or mysite.com with a different login per customer). The downside of this approach is that you can no longer rely upon the browser's same-origin policy to help you keep customers separate, so now the responsibility passes to your server. Some web app management platforms have a policy to run every app on its own subdomain, which offers a good balance of admin cost and security. For example, [Cloudron](https://docs.cloudron.io/security/#app-isolation-and-sandboxing), which I use.

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@Fawa commented on GitHub (Mar 30, 2023):

FWIW I'm running lldap behind Traefik and https://lldap.example.com/ works fine with no modifications to lldap or base-path shenanigans.

You able to post your Traefik labels for this? This is the only container I can't seem to get to work with Traefik, just get a gateway timeout after about 30 seconds. Below is what I run for my other 30ish containers without issue, couldn't seem to get lldap to agree with it, even after adjusting the TOML file with the relevant info. (or is that where my issue lies?). Just know I am knew to LDAP stuff.

labels:
      - "traefik.http.routers.lldap.rule=Host(`lldap.some.domain`)"
      - "traefik.http.routers.lldap.tls=true"

      # Set port to use
      - "traefik.http.services.lldap.loadbalancer.server.port=17170"
      - "traefik.http.services.lldap.loadbalancer.server.scheme=http"


      # Redirect to HTTPS
      - "traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https"
      - "traefik.http.routers.lldap-redirs.rule=hostregexp(`{host:.+}`)"
      - "traefik.http.routers.lldap-redirs.entrypoints=web"
      - "traefik.http.routers.lldap-redirs.middlewares=redirect-to-https"

      # Enable traefik
      - traefik.enable=true

<!-- gh-comment-id:1489753197 --> @Fawa commented on GitHub (Mar 30, 2023): > FWIW I'm running lldap behind Traefik and https://lldap.example.com/ works fine with no modifications to lldap or base-path shenanigans. You able to post your Traefik labels for this? This is the only container I can't seem to get to work with Traefik, just get a gateway timeout after about 30 seconds. Below is what I run for my other 30ish containers without issue, couldn't seem to get lldap to agree with it, even after adjusting the TOML file with the relevant info. (or is that where my issue lies?). Just know I am knew to LDAP stuff. ``` labels: - "traefik.http.routers.lldap.rule=Host(`lldap.some.domain`)" - "traefik.http.routers.lldap.tls=true" # Set port to use - "traefik.http.services.lldap.loadbalancer.server.port=17170" - "traefik.http.services.lldap.loadbalancer.server.scheme=http" # Redirect to HTTPS - "traefik.http.middlewares.redirect-to-https.redirectscheme.scheme=https" - "traefik.http.routers.lldap-redirs.rule=hostregexp(`{host:.+}`)" - "traefik.http.routers.lldap-redirs.entrypoints=web" - "traefik.http.routers.lldap-redirs.middlewares=redirect-to-https" # Enable traefik - traefik.enable=true ```

kerem commented 2026-02-27 08:15:10 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Mar 30, 2023):

Just a note on a potential TCP router for the LDAP ports. The TCP router is only needed if you want to expose the LDAP traffic to internet. This is highly not recommended since LDAP is not encrypted and the passwords are in plain text. You would at least want to use LDAPS (with an SSL layer), but the best is probably to restrict LDAP traffic to your local host, or even inside the docker networks.

Now, back to @Fawa's question:

lldap:
  image: nitnelave/lldap
  container_name: lldap
  volumes:
    - "./lldap:/data"
  environment:
    - LLDAP_JWT_SECRET=abcdefgh
    - LLDAP_LDAP_USER_PASS=password
    - LLDAP_LDAP_BASE_DN=dc=example,dc=com
  labels:
    - "traefik.enable=true"
    - "traefik.http.routers.lldap.rule=Host(`lldap.${ROOT_DOMAIN}`)"
    - "traefik.http.routers.lldap.entrypoints=https"
    - "traefik.http.routers.lldap.tls=true"
    - "traefik.http.services.lldap-service.loadbalancer.server.port=17170"
    - "traefik.http.services.lldap-service.loadbalancer.server.scheme=http"

EDIT: Reworded the first sentence since the proposal for a TCP router was deleted.

<!-- gh-comment-id:1489962511 --> @nitnelave commented on GitHub (Mar 30, 2023): Just a note on a potential TCP router for the LDAP ports. The TCP router is only needed if you want to expose the LDAP traffic to internet. This is *highly not recommended* since LDAP is not encrypted and the passwords are in plain text. You would at least want to use LDAPS (with an SSL layer), but the best is probably to restrict LDAP traffic to your local host, or even inside the docker networks. Now, back to @Fawa's question: ```yaml lldap: image: nitnelave/lldap container_name: lldap volumes: - "./lldap:/data" environment: - LLDAP_JWT_SECRET=abcdefgh - LLDAP_LDAP_USER_PASS=password - LLDAP_LDAP_BASE_DN=dc=example,dc=com labels: - "traefik.enable=true" - "traefik.http.routers.lldap.rule=Host(`lldap.${ROOT_DOMAIN}`)" - "traefik.http.routers.lldap.entrypoints=https" - "traefik.http.routers.lldap.tls=true" - "traefik.http.services.lldap-service.loadbalancer.server.port=17170" - "traefik.http.services.lldap-service.loadbalancer.server.scheme=http" ``` EDIT: Reworded the first sentence since the proposal for a TCP router was deleted.

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@wailashi commented on GitHub (Mar 30, 2023):

Good point. I should have mentioned the security aspects. I've deleted my comment to avoid leading people astray.

<!-- gh-comment-id:1489978399 --> @wailashi commented on GitHub (Mar 30, 2023): Good point. I should have mentioned the security aspects. I've deleted my comment to avoid leading people astray.

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Aug 3, 2023):

I'm going to close this as not completed, in parts due to lack of time, and in part due to the security concerns.

<!-- gh-comment-id:1664121220 --> @nitnelave commented on GitHub (Aug 3, 2023): I'm going to close this as not completed, in parts due to lack of time, and in part due to the security concerns.

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@habr05 commented on GitHub (Mar 24, 2024):

"The least robust strategy is to serve all of your customers from your same domain (e.g., mysite.com/customera, mysite.com/customerb; or mysite.com with a different login per customer). The downside of this approach is that you can no longer rely upon the browser's same-origin policy to help you keep customers separate, so now the responsibility passes to your server."

This concern is out place, I think. LDAP is not a random end-user nor intended to be exposed to the web system. There are more robust, dedicated players that handle web facing IAM.

As for sub-folder and sub-domain, that choice should be left to intended audience. Everyone has different requirements, environment and constrains.

<!-- gh-comment-id:2016836499 --> @habr05 commented on GitHub (Mar 24, 2024): "The least robust strategy is to serve all of your customers from your same domain (e.g., mysite.com/customera, mysite.com/customerb; or mysite.com with a different login per customer). The downside of this approach is that you can no longer rely upon the browser's same-origin policy to help you keep customers separate, so now the responsibility passes to your server." This concern is out place, I think. LDAP is not a random end-user nor intended to be exposed to the web system. There are more robust, dedicated players that handle web facing IAM. As for sub-folder and sub-domain, that choice should be left to intended audience. Everyone has different requirements, environment and constrains.

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Apr 3, 2024):

@habr05 it's possible (but not officially supported) to use a reverse-proxy to serve LLDAP on a subpath, see https://github.com/lldap/lldap/issues/870#issuecomment-2004237991

<!-- gh-comment-id:2035679872 --> @nitnelave commented on GitHub (Apr 3, 2024): @habr05 it's possible (but not officially supported) to use a reverse-proxy to serve LLDAP on a subpath, see https://github.com/lldap/lldap/issues/870#issuecomment-2004237991

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

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

An unsupported method using nginx to rewrite HTTP headers and content is noted here: https://github.com/lldap/lldap/issues/1055#issue-2720098045

<!-- gh-comment-id:2520114215 --> @Zepmann commented on GitHub (Dec 5, 2024): An unsupported method using nginx to rewrite HTTP headers and content is noted here: https://github.com/lldap/lldap/issues/1055#issue-2720098045

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@rhclayto commented on GitHub (Apr 9, 2025):

Please add this feature if time permits, & leave the security cost:benefit analysis to the system administrators. Whether there is any security problem in practice, not just in theory, is highly dependent on context.

<!-- gh-comment-id:2788046382 --> @rhclayto commented on GitHub (Apr 9, 2025): Please add this feature if time permits, & leave the security cost:benefit analysis to the system administrators. Whether there is any security problem in practice, not just in theory, is highly dependent on context.

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Apr 9, 2025):

It's already somewhat ready to do: https://github.com/lldap/lldap/issues/870

I'd rather make the insecure things hard to do but not impossible than just documenting them (because people who have security holes don't read the docs), so I think the status quo is reasonable.

<!-- gh-comment-id:2788071825 --> @nitnelave commented on GitHub (Apr 9, 2025): It's already somewhat ready to do: https://github.com/lldap/lldap/issues/870 I'd rather make the insecure things hard to do but not impossible than just documenting them (because people who have security holes don't read the docs), so I think the status quo is reasonable.

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@Zepmann commented on GitHub (Apr 9, 2025):

I'd rather make the insecure things hard to do but not impossible than just documenting them (because people who have security holes don't read the docs), so I think the status quo is reasonable.

That does not make any sense. If people who have security holes do not read documentation then it does not matter what you write in the documentation. Just ensure that the default configuration is secure.

I am wary of security products that rely on security by obscurity. Do not go down that path, please.

<!-- gh-comment-id:2790564083 --> @Zepmann commented on GitHub (Apr 9, 2025): > I'd rather make the insecure things hard to do but not impossible than just documenting them (because people who have security holes don't read the docs), so I think the status quo is reasonable. That does not make any sense. If people who have security holes do not read documentation then it does not matter what you write in the documentation. Just ensure that the default configuration is secure. I am wary of security products that rely on security by obscurity. Do not go down that path, please.

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Apr 9, 2025):

This is hardly security through obscurity, there is no security hole that I hope no one notices. This is making the insecure things hard. What you're asking for, secure defaults, is exactly what I'm doing: the default thing is secure (one domain for LLDAP), and the insecure thing (shared domain) is possible but harder (and not officially documented apart from issues).

<!-- gh-comment-id:2791177931 --> @nitnelave commented on GitHub (Apr 9, 2025): This is hardly security through obscurity, there is no security hole that I hope no one notices. This is making the insecure things hard. What you're asking for, secure defaults, is exactly what I'm doing: the default thing is secure (one domain for LLDAP), and the insecure thing (shared domain) is possible but harder (and not officially documented apart from issues).

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@Zepmann commented on GitHub (Apr 10, 2025):

Not documenting an insecure function due to it being insecure is security through obscurity. "It is secure as long as someone does not know about..." is the definition of security through obscurity, after all.

My preference for these kind of things is documenting them with a big fat warning at the top and call it a day. You are not responsible for how others use LLDAP. It is up to system administrators to make the security risk/functional reward-analysis themselves based on provided information.

<!-- gh-comment-id:2792237542 --> @Zepmann commented on GitHub (Apr 10, 2025): Not documenting an insecure function due to it being insecure is security through obscurity. "It is secure as long as someone does not know about..." is the definition of security through obscurity, after all. My preference for these kind of things is documenting them with a big fat warning at the top and call it a day. You are not responsible for how others use LLDAP. It is up to system administrators to make the security risk/functional reward-analysis themselves based on provided information.

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Apr 10, 2025):

In this case I disagree. It's not "don't enable that option because it's unsafe", but "don't modify the provided software in unsupported ways to do something unsafe because that's, uhh, unsafe". The software, as provided, doesn't support sub-paths. You can overwrite a provided file with a custom one to enable that, but at that point that's your problem, you can't really come back here and say that LLDAP is unsafe.

As for "let admins be admins", this software is opinionated, and one of the core tenets is that it should be easy/safe to use by inexperienced sysadmins. I am trying very hard to reduce any sharp edges, I do not need or want big fat red warnings.

<!-- gh-comment-id:2792546878 --> @nitnelave commented on GitHub (Apr 10, 2025): In this case I disagree. It's not "don't enable that option because it's unsafe", but "don't modify the provided software in unsupported ways to do something unsafe because that's, uhh, unsafe". The software, as provided, doesn't support sub-paths. You can overwrite a provided file with a custom one to enable that, but at that point that's your problem, you can't really come back here and say that LLDAP is unsafe. As for "let admins be admins", this software is opinionated, and one of the core tenets is that it should be easy/safe to use by inexperienced sysadmins. I am trying very hard to reduce any sharp edges, I do not need or want big fat red warnings.

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@Zepmann commented on GitHub (Apr 10, 2025):

It's not "don't enable that option because it's unsafe", but "don't modify the provided software in unsupported ways to do something unsafe because that's, uhh, unsafe".

You state doing this is unsafe as an absolute fact, while it does not have to be. It could be unsafe if a sysadmin is not aware of the risks and just does it based on some comments in some obscure discussion.

As for "let admins be admins", this software is opinionated, and one of the core tenets is that it should be easy/safe to use by inexperienced sysadmins. I am trying very hard to reduce any sharp edges, I do not need or want big fat red warnings.

I think this is how inexperienced sysadmins stay inexperienced. It can also be documented as unsupported ("here be dragons") and only have the big fat red warning in the documentation where it is warranted. That is how inexperienced sysadmins become experienced, because they can learn what they can do but probably should not do. This knowledge will also help them in being a good sysadmin with different products.

Of course I will respect your vision for LLDAP. It's great and I use it every day! Just be ready to have this question asked more often due to LLDAP becoming more popular. 😄

If you are open for a PR I might see if I have some time in the future to document this with proper warnings to have a good reference for when this discussion pops up again ("this is community documentation, unsupported, unsafe, and you really should not do this because...)". If you are not, all's well. 👍

[edit]
I can also host this documentation somewhere else if you'd like, so it has no official link to LLDAP (community contribution). It can be useful to refer to in a discussion. Just let me know what you think is most convenient. I am also willing to give it a rest. For my use case I have solved this issue, so I am fine either way.

<!-- gh-comment-id:2792949911 --> @Zepmann commented on GitHub (Apr 10, 2025): > It's not "don't enable that option because it's unsafe", but "don't modify the provided software in unsupported ways to do something unsafe because that's, uhh, unsafe". You state doing this is unsafe as an absolute fact, while it does not have to be. It could be unsafe if a sysadmin is not aware of the risks and just does it based on some comments in some obscure discussion. > As for "let admins be admins", this software is opinionated, and one of the core tenets is that it should be easy/safe to use by inexperienced sysadmins. I am trying very hard to reduce any sharp edges, I do not need or want big fat red warnings. I think this is how inexperienced sysadmins stay inexperienced. It can also be documented as unsupported ("here be dragons") and only have the big fat red warning in the documentation where it is warranted. That is how inexperienced sysadmins become experienced, because they can learn what they can do but probably should not do. This knowledge will also help them in being a good sysadmin with different products. Of course I will respect your vision for LLDAP. It's great and I use it every day! Just be ready to have this question asked more often due to LLDAP becoming more popular. :smile: If you are open for a PR I might see if I have some time in the future to document this with proper warnings to have a good reference for when this discussion pops up again ("this is community documentation, unsupported, unsafe, and you really should not do this because...)". If you are not, all's well. 👍 [edit] I can also host this documentation somewhere else if you'd like, so it has no official link to LLDAP (community contribution). It can be useful to refer to in a discussion. Just let me know what you think is most convenient. I am also willing to give it a rest. For my use case I have solved this issue, so I am fine either way.

kerem commented 2026-02-27 08:15:11 +03:00

Author

Owner

Copy link

@nitnelave commented on GitHub (Apr 10, 2025):

With respect to educating admins, let them break their teeth on a project with a better support structure :D I don't have time for this, part of the opinionated structure of LLDAP is to reduce the maintenance burden.

As for appetite for PRs, I'd rather stay with the status quo for now until I'm fed up with the requests

<!-- gh-comment-id:2793044905 --> @nitnelave commented on GitHub (Apr 10, 2025): With respect to educating admins, let them break their teeth on a project with a better support structure :D I don't have time for this, part of the opinionated structure of LLDAP is to reduce the maintenance burden. As for appetite for PRs, I'd rather stay with the status quo for now until I'm fed up with the requests

kerem referenced this issue 2026-02-27 08:17:55 +03:00

[PR #94] [MERGED] Fix issues with docker around users and permissions #540

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

dependabot/github_actions/codecov/codecov-action-6

copilot/fix-equality-filters-list-attributes

dependabot/github_actions/docker/build-push-action-7

dependabot/github_actions/docker/metadata-action-6

dependabot/github_actions/docker/setup-buildx-action-4

dependabot/github_actions/docker/login-action-4

copilot/update-download-artifact-action

copilot/fix-opensuse-warnings

copilot/fix-1268

copilot/fix-727

copilot/fix-898

copilot/fix-1256

copilot/fix-1251

copilot/fix-1249

copilot/fix-1206

user-attribute-form

user-ui

group-ui

server-user-attribute-schema

crates

haveibeenpwned

v0.6.2

v0.6.1

v0.6.0

v0.5.0

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.0

v0.2.0

v0.0.1

Labels

Clear labels   

backend

  

blocked

  

bug

  

cleanup

  

dependencies

  

docker

  

documentation

  

duplicate

  

enhancement

  

enhancement

  

frontend

  

github_actions

  

good first issue

  

help wanted

  

help wanted

  

integration

  

invalid

  

ldap

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

rust

  

rust

  

tests

  

wontfix

No labels

backend

blocked

bug

cleanup

dependencies

docker

documentation

duplicate

enhancement

enhancement

frontend

github_actions

good first issue

help wanted

help wanted

integration

invalid

ldap

pull-request

question

rust

rust

tests

wontfix

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/lldap-lldap#86

No description provided.