Bug #1564

auth.backend.ldap.filter not working with conditionals/not being rebuilt

Added by Anonymous over 6 years ago. Updated about 6 years ago.

Status:FixedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:mod_auth
Target version:1.4.20
Missing in 1.5.x:

Description

If you define a (dynamic) filter within a conditional like this:


$HTTP["host"] == "a.host.name" {
 var.customer             = "customer-name" 
 auth.backend.ldap.filter = "(&(uid=$)(|(gidNumber=345)(cn=" + var.customer + ")))" 
 auth.require             = ( 
  "" => (
   "method"  => "basic",
   "realm"   => "Login",
   "require" => "valid-user",
  ),
 )
}

the filter seems to be built ONLY ONCE and never be rebuild based on the HTTP-Host.

Therefore the first Login-Attempt from a HTTP-Host fixes the LDAP-Filter, making it quite unusable with virtual hosting.

Using "require => user=xxx|user=yyy" doesn't work for us - we have hundreds of them, some shared between V-Servers, some not. Therefore we need "dynamic" LDAP-Filters based on the HTTP-Host conditional.

-- laph

History

#1 Updated by Anonymous over 6 years ago

I have the same problem, I need to match against UID in some parts and CN in some other parts of the Webserver. And the filters are not regenerated.

It's even worse, I tried using (|(uid=$)(cn=$)) as a filter, but only the first occurence of $ is expanded to the auth user as can be seen from the slapd debug log

filter="(|(uid=lana)(cn=$))"

The problem is still present on 1.4.19

-- uspoerlein

#2 Updated by stbuehler over 6 years ago

  • Status changed from New to Fixed
  • Resolution set to invalid
  1. The "var.xxxx" variables in the config are replaced while parsing the config (by design, won't change).
  2. The doc says "the $ is replaced", and imho this includes that you should use only one.

#3 Updated by Anonymous over 6 years ago

  • Status changed from Fixed to Need Feedback
  • Resolution deleted (invalid)

Well, if the documentation mentions this shortcoming, then this is probably not a bug report.

I hope you don't mind me reopening it as a feature request instead? Without such a functionality, I'm unable to authorize various parts of my webserver. I'd have to use multiple lighty instances or switch to Apache. :(

-- uspoerlein

#4 Updated by stbuehler over 6 years ago

Are you really sure you need this and it would not be solvable with conditionals? I.e. you would have many lighty instances in a mod_proxy chain to do it?

#5 Updated by Anonymous over 6 years ago

No, it cannot be solved by conditionals, that's what this bug is all about.

The trick with mod_proxy should work, but this is so much overhead for what I'm doing. I'd then have to track multiple lighty instances, etc.

LDAP support in lighty could really do with some lovin. Whould it be so hard to make the filter dynamic like pretty much all the rest of lighty configuration?

-- uspoerlein

#6 Updated by stbuehler over 6 years ago

I have just more important things to do, and i don't see the need for it in a clean system.

So if someone provides a nice patch to do this, i will apply it.

#7 Updated by Anonymous about 6 years ago

Replying to stbuehler:

I have just more important things to do, and i don't see the need for it in a clean system.

So if someone provides a nice patch to do this, i will apply it.

Well, I don't agree. If you have multiple vhosts you simply expect to be able to set different LDAP Filters in different vhosts - just like you can do with htdigest or any other auth mechanism.
Using a LDAP Filter, you "select" a group of people being able to access a vhost. You don't expect that this group is granted access to ALL vhosts hosted by this lighty server instance.

From my point of view, I'd still call it a defect.

-- laph

#8 Updated by stbuehler about 6 years ago

If you need separate filters for different vhosts, why don't you just put them into a vhost conditional?

Before you claim it is a defect you should understand how the config works!

#9 Updated by Anonymous about 6 years ago

Replying to stbuehler:

If you need separate filters for different vhosts, why don't you just put them into a vhost conditional?

Before you claim it is a defect you should understand how the config works!

'''But that's exactly the issue !!! '''

I've put different filters into different vhosts (== HTTPhost conditionals), but as soon as there's a auth request for one of them, the filter used within this (first accessed) one, is also used for all the others, without respecting the different filters in different conditionals.


$HTTP["host"] == "foo.host.name" {
 var.customer             = "Foo-customer" 
 auth.backend.ldap.filter = "(&(uid=$)(|(gidNumber=345)(cn=" + var.customer + ")))" 
 auth.require             = ( 
  "" => (
   "method"  => "basic",
   "realm"   => "Login",
   "require" => "valid-user",
  ),
 )
}

$HTTP["host"] == "bar.host.name" {
 var.customer             = "Bar-customer" 
 auth.backend.ldap.filter = "(&(uid=$)(|(gidNumber=345)(cn=" + var.customer + ")))" 
 auth.require             = ( 
  "" => (
   "method"  => "basic",
   "realm"   => "Login",
   "require" => "valid-user",
  ),
 )
}

If "foo.host.name" is accessed first (right after a lighty-restart), the conditional "(&(uid=$)(|(gidNumber=345)(cn=Foo-customer)))" is used for each and every vhost. If "bar.host.name" is accessed first, it's the other way around.

But it's never in the expected way, that "cn=Foo-customer" is used for "foo.host.name" and "cn=Bar-customer" for "bar.host.name", even though I define them in HTTPhost conditionals.

-- laph

#10 Updated by stbuehler about 6 years ago

  • Status changed from Need Feedback to Fixed
  • Resolution set to fixed

Thank you very much for finally give the details i need to understand you.

You are right, it is a defect - fixed in r2280.

uspoerlein: if you have a patch for your requested enhancement (or just want a ticket for it), please open a new ticket for it.

Also available in: Atom