Project

General

Profile

Actions

Feature #965

closed

New conditional: Physical path

Added by hoffie over 17 years ago. Updated over 7 years ago.

Status:
Wontfix
Priority:
Normal
Category:
core
Target version:
-
ASK QUESTIONS IN Forums:

Description

It would be nice to have something like $REQUESTpath =~ "^/var/www/customer/subdir/" { ... }

I don't know if this is even possible, but while developing a patch for SysCP (control panel like Confixx) a problems arose: A lot of the settings should be directory-specific, for example authentication, error pages, ... and currently it's not possible to do such things with lighttpd. For now I hacked up a combination of $HTTPhost and $HTTPurl but this gets very messy (think of x1.example.org => /var/www/, x2.example.org => /var/www/foo and you want to protect /var/www/foo...).
I already thought about doing this with a mod_magnet script as you can check against the physical path there, but things like password authentication etc. are not possible there (at least not as easy as with the config file).

SysCP of course is just an example, such a conditional can be useful for any other "automated" config generation system as well.

Actions #1

Updated by hoffie about 17 years ago

This was implemented (for 1.5) in r1528.

Actions #2

Updated by gstrauss almost 8 years ago

  • Description updated (diff)
  • Status changed from New to Need Feedback
  • Assignee deleted (jan)

@hoffie, not sure if you're still watching this.

While it would be possible to add a conditional to lighttpd 1.4.x branch, doing so would increase complexity and, more importantly, increase potential confusion for users attempting to properly configure their systems. I have seen many times where Apache admins had trouble grasping that physical path conditionals occur much later in request processing (i.e. after URL-to-physical path mapping, and after other processing has occurred).

Can you be more specific about what you are (were) trying to protect and in what ways you are (were) trying to protect it? Between CGI, FastCGI, SCGI, path aliases, symlinks, and more, it can be difficult to protect assets which are accessible to the web server, but which you wish to handle differently for multiple internal users who all have access to modify server content and processing. Best practices suggest better isolation into different processes running under different user accounts or VMs, accessed via HTTP proxying or other mechanisms.

Actions #3

Updated by hoffie over 7 years ago

Yes, I am still watching this. ;)
I agree that there is a chance that this feature may end up confusing users.

Personally, I do not have any interest in this feature any longer since I am currently not maintaining any environments where this would be relevant. Unless there are other users requesting this feature, we could close this one as WONTFIX, I guess.

Regarding the use case: I was trying to map a specific Apache configuration to lighty syntax. The semantics had been dictated by the generating tool (http://syscp.org). Sadly, I do not remember any more details after 9 years ;)

Actions #4

Updated by gstrauss over 7 years ago

  • Status changed from Need Feedback to Wontfix

As you suggest, I am going to mark this WontFix. Also, syscp itself does not appear to have been updated in 6+ years.

Regarding lighttpd and physical paths: while it would not be difficult to add a hook to call modules once the physical path was determined, the brunt of making it useful requires evaluating each module to determine whether or not it should be called from this hook, and then modifying the module to potentially be called more than once at different phases of the request. For example, mod_access is called early in the request and operates on the URL. mod_access would need to be called again, once that physical path is determined, perhaps with new directives path.access-allow and path.access-deny in addition to the existing url.access-allow and url.access-deny.

For this reason, I am going to mark this WontFix. If someone has a must-have use case which must operate on physical paths, please explain it here in detail and we may reconsider this feature request.

Actions

Also available in: Atom