Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
lemonldap-ng
lemonldap-ng
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 244
    • Issues 244
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 2
    • Merge Requests 2
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • LemonLDAP NG
  • lemonldap-nglemonldap-ng
  • Issues
  • #2285

Closed
Open
Opened Aug 19, 2020 by Maxime Besson@maxbes🔧Maintainer

LLNG should not rely on virtual hosts so much

The current model of LLNG is heavily based around "Virtual Hosts" and the notion of having a common domain for portal, manager, 'reload' and apps, but three (at least) different hostnames.

But we have many users who do not use the handler at all, and instead only use the SAML/OIDC issuers. For them, having to dedicate an entire subdomain to LemonLDAP makes little sense.

We have users who would like to deploy LLNG components in a sub-path: the manager in /manager, for exemple. Or even, the portal in /portal, why not! And maybe apps in /test1 and /test2?

This would allow us to run an entire "demo instance" under a single URL, without even requiring apache or nginx, just plackup! No more DNS or /etc/hosts issues. Much easier for us devs, too, no more make start_web_server.

Good news: because the LLNG router uses $req->path, it wouldn't take a huge amount of work to achieve this. (but it will take a lot of testing). Mostly we would just have to write a new handler type that does not depend on the VHost name, but perhaps on a FastCGI environment variable set by the admin within a location block. The regexp in this new handler type would only be matched against $req->path instead of the entire URL. This handler could solve #2238 too.

Opening this low-priority ticket for discussion, and so I can have a reference to put in commits when I do little improvements towards this long-term goal.

Assignee
Assign to
3.0.0
Milestone
3.0.0
Assign milestone
Time tracking
None
Due date
None
Reference: lemonldap-ng/lemonldap-ng#2285