Lighttpd

Since I am not a Lighhttp developer I cannot assign this issue to me. However, I am working on it and I should get it done by the end of this weekend.
This is the configuration file that I use to reproduce it :

server.document-root = "/var/www/localhost/htdocs" 
server.port = 80

server.username = "test" 
server.groupname = "test" 

server.modules = ("mod_auth", "mod_setenv", "mod_fastcgi", "mod_alias", "mod_rewrite", "mod_redirect" )
dir-listing.activate = "enable" 

mimetype.assign = (
  ".html" => "text/html", 
  ".txt" => "text/plain",
  ".jpg" => "image/jpeg",
  ".png" => "image/png" 
)

static-file.exclude-extensions = ( ".fcgi", ".php", ".rb", "~", ".inc" )
index-file.names = ( "index.html" )

auth.debug                  = 2
auth.backend                = "plain" 
auth.backend.plain.userfile = "/home/lighttpd/lighttpd.user" 
auth.require = ( "/private/index.html" =>
(
        "method" => "basic",
        "realm" => "test",
        "require" => "user=test" 
)
)

Thanks.
Giuseppe

Your patch is dangerous; it is on purpose that mod_auth is called early before anything else happens.

@stbuehler. Thank you for checking my patch. I guess you are right, but can you explain me why?

Possible alternative solution, the index file can be appended to the uri in the mod_auth before it verify the URI. However, it 's difficult to retrieve the values of the index files from the mod_auth since these values are not directly accessible. This is the reason why I have inverted the order.

I think you have to be more careful; you assumed that this needs to be fixed in some way, and didn't consider that if you force it, you might make it worse.

In this case we have to consider that mod_auth might block the directory, but not the index file (nested in some $HTTP["url"] conditional for example); so changing the order would suddenly allow requests to work that are blocked right now.

Other modules might trigger actions in handlers that come after mod_auth now, but your change might make them get called earlier, removing the protection on those actions.

In this case we probably should restart the request handling, as mod_indexfile modifies con->uri.path and should (but doesn't, another bug) also reset all $HTTP["url"] results (which are cached). (this is similar to what mod_rewrite does)

Reiterating what @stbuehler said:

auth.require matches urls, but index-files.names is about the physical file name mapping - it never changes the url.

While I do get that this is unexpected and bad for some users, this is a direct result of the design of both modules.

mod_auth checks URI requested by client for authorization.

mod_indexfile maps a URI to a physical path, and operates only on URI, requested by client, which end in '/'.
mod_indexfile handles the request after mod_auth checks the URI requested by the client.
You might think about it in such a way that URI requested by the client has been authorized by mod_auth, and is then handled by mod_indexfile (without modifying URI requested by client). (In an alternative implementation, URI could be modified internally, but that is not how mod_indexfile currently behaves)

Perhaps you're looking to authorize both explicit requests for index.html and requests for URI paths ending in '/', which might be handled by mod_indexfile:

var.auth_useradmin = ( "method" => "digest", "realm" => "protected area", "require" => "user=Admin|user=User" )
# require auth for URI which directly request index.html as well as for URI
# which end in '/' and might be handled by mod_indexfile or mod_dirlisting
$HTTP["url"] =~ "/(index.html)?$" {
  auth.require = ("" => auth_useradmin)
}