To be a bit more verbose - 

mod_autoindex hides directories and files that require authentication, which
leads to a catch-22; how does someone find the file to log in if they can't see
that it exists?

It's very nifty that it can hide authentiated resources *if* the site requires
users to log in earlier; however, this doesn't work in all situations.

Therefore, it's necessary to have an option where this behaviour is turned off.

[changing the severity, as this isn't an enhancement; it's a bug in a 2.0
enhancement ]

I know It's silly to argue over the serverity level, but this was a deliberate
design decision, 
and hence can't be classified as a bug.  It was considered unsafe to
give un-authenticated users information on areas of the server to which
they don't have access.

Yes, it would be nice to be able to turn this off.  But it's not a bug.

wow i forgot this bug report even existed since ive stopped using autoindex (due
to this problem actually).  this might only be an enhancement but it is very
necessary for doing seemingly simple things like indexing userdirs and forces
the user to create their own custom cgi or similar autoindex which is not at all
an ideal solution.  other than requiring auth in the root directory which is not
an option there is currently no possible way to have a completely autoindexed
site that uses any sort of authentication.  with the new header / footer options
and other enhancements mod_autoindex is becoming much more useable and more
integrated in websites structures; it would be very nice if it wasnt
incompatable with authentication.

 i had to tweak the mod_autoindex.c in the
latest version of apache to get it
to work right.  here are my work-arounds:

         //if (!(p->icon = find_icon(d, rr, 1))) {
                // was getting wrong icons on folders
                p->icon = find_default_icon(d, "^^DIRECTORY^^");
            //}
            if (!(p->alt = find_alt(d, rr, 1))) {
                if (!(p->alt = find_default_alt(d, "^^DIRECTORY^^"))) {
                    p->alt = "DIR";
                }
            }
        }
        else {
            p->icon = find_icon(d, rr, 0);
            p->alt = find_alt(d, rr, 0);
            p->size = rr->finfo.size;
        }


        p->desc = find_desc(d, rr->filename);

        if ((!p->desc) && (autoindex_opts & SCAN_HTML_TITLES)) {
                //added this check -- was getting garbage description on folder
           if (dirent->filetype != APR_DIR)  
                p->desc = apr_pstrdup(r->pool, find_title(rr));
        }

This patch doesn't solve the problem of hiding directories with authenticated
access does it?
Is there any patch which does this work? Or any other workaround? I need it very
much...

Thanks,
Martin

Created attachment 11165 [details]
Finally I found a workaround - this dirty hack disables directory hiding feature.

Can this feature be brought back?  Perhaps be default, auth protected dirs files
can be hidden, but allow to specify to display hidden directories and files with
IndexOptions?

Incoming Patch adds a new IndexOptions Command "ShowForbidden".  This will list
directories or files that normaly wouldn't be shown because the subrequest
returns  forbidden.  This patch is against 2.1-CVS Head.

Created attachment 11890 [details]
Adds "ShowForbidden" to IndexOptions

Oooh, nice, +1.  Watch the code style though:

+    if((autoindex_opts & SHOW_FORBIDDEN) && 
+       (rr->status == HTTP_UNAUTHORIZED || rr->status == HTTP_FORBIDDEN)) {

should be:

   if ((blah)
       && (blee)) {

(I also detest the (1 == foo) style rather than (foo == 1) but that's not in the
style guide :)

Patch Commited to 2.1.  Thanks for the feature request!

-Paul Querna

*** Bug 30854 has been marked as a duplicate of this bug. ***

*** Bug 35443 has been marked as a duplicate of this bug. ***

This change classifies as 'security-through-obscurity', and shows a trend towards a lack of common sense.

The correct way to have done this was not to switch horses mid-stream from correct security methods to incorrect security methods, in the instance creating babylonian confusion and wasting thousands of man-hours while others and myself looked for the workaround to the deliberate hack; instead to have a security protocol whereby x number of login retries within x number of minutes blocks the account for x number of minutes.

Making 'security-through-obscurity' -something I hear more sensible people decry as incorrect and wrong-headed- standard on Apache, an option rather than the default. This way the lesser number of people who's time is worth a lot more than whomever made this the default, don't waste it on this guy's poor-quality decision.

I don't think we will change the default for ShowForbidden. Closing again.