directory index icons?

[Dan99]

I fought through this with another server, and I'm faced with doing it again. That was long ago, and I've forgotten the tricks. My present web server has a load of great directory icons in /usr/localApache/icons, but I can't get my directories to display them. My .htaccess has

IndexOptions IgnoreClient IgnoreCase FancyIndexing NameWidth=* DescriptionWidth=* SuppressHTMLPreamble

and I have, for example,

AddIcon /usr/local/apache/icons/sound1.gif .mp3

(Even then, no sound icon is displayed with .mp3 files.)

I thought FancyIndexing called for those icons. But I suspect I haven't generally pointed my system at that icon directory, and that's why it isn't using them. How do I do that in .htaccess?

[phranque]

AddIcon /usr/local/apache/icons/sound1.gif .mp3

Icon is either a (%-escaped) relative URL to the icon, a fully qualified remote URL, or of the format (alttext,url) where alttext is the text tag given for an icon for non-graphical browsers.

https://httpd.apache.org/docs/2.4/mod/mod_autoindex.html#addicon

it looks like you are providing an absolute file path and not a relative or external url.

[Dan99]

Sorry, what would a "relative" or "external" URL look like in my case?

[lucy24]

:: detour to cross-check docs for some other mods ::

Just to confuse us, Apache likes to say "relative" when they mean "absolute" (i.e. beginning at the root of whatever domain you are currently in.) The syntax is the same as for, say, ErrorDocument directives--which they also brand with the misleading term “relative”--and you know how those work.

So, assuming your icons are located in the same directory that contains the htaccess for a single domain, all you need to say is
/icons/sound1.gif

It's true that some htaccess directives can point to files located one level higher up, as when a userspace contains multiple hosts that share some material, but let's keep it simple.

[Dan99]

Well, when I put

AddIcon /icons/sound1.gif .mp3

in my .htaccess, my mp3 file lists in the directory with "[ ]" in front of it. When I comment out that statement, I get nothing in front of it. No icons to be seen.

I have to assume that someone, somewhere, has to tell the system that "icons" points to usr/local/apache/icons.

Do you mean I need to have a local "icons" directory with sound1.gif in it? Seems like it would be easier just to point to wherever that file is sitting.

[lucy24]

Do you mean I need to have a local "icons" directory with sound1.gif in it?

When you say “local” do you mean that literally, as in, this is all happening on a pseudo-server working with your local files? Quick detour to MAMP turns up not one but two /icons/ directories; the config file has a couple of lines involving the Alias* directive, as in
Alias /icons/ "/Applications/MAMP/Library/icons/"
(Change this, obviously, to meet your own directory structure. That goes in config, not in htaccess.)

In any case, why not copy the /icons/ directory into the site directory? We're talking about, what, a few Ks worth of files (mine's 130K, and that's with parallel png and gif versions of everything) and surely your HD isn't that full.

Incidentally, o/t but I'm getting curious: What are all these publicly visible directory listings for?


* Since I operate strictly in htaccess, it's funny to meet mod_alias doing its actual, official job.

[Dan99]

Thank you. If I can't access config to mess around with Alias, then yes, just copying the icons that I need into the same directory as my website (I call that "local") is the way to go. I just need two or three of those icons, so the price is minimal. A few K maybe.

I maintain a large list of publicly accessible folders for my professional collegues. I have a list of folder names, each linked to a folder, and they can go click on the folder name, peruse the folder, and look at the directory listing for that folder to see what they want that's in it. In those folders, I have mp3, ppt, and pdf files. Would be nice to have icons that visually conveyed those file types.

[phranque]

I have to assume that someone, somewhere, has to tell the system that "icons" points to usr/local/apache/icons.

Do you mean I need to have a local "icons" directory with sound1.gif in it? Seems like it would be easier just to point to wherever that file is sitting.

you should read these sections of the apache documentation to understand this:

DocumentRoot:
https://httpd.apache.org/docs/current/urlmapping.html#documentroot

Files Outside the DocumentRoot:
https://httpd.apache.org/docs/current/urlmapping.html#outside

[Dan99]

Okeydokey. I put an "icons" directory in the same directory as my website with a few icons in it, and just did

AddIcon /icons/sound1.gif .mp3

and other like statements in my .htaccess. It all works now. Thanks again.

[lucy24]

Hurrah! I have never personally played with FancyIndexing so it is good to know it can be made to behave as intended.

[keyplyr]

Amazing... most everyone wants me to block directory browsing on their sites.

[lucy24]

It's unusual, but he explained it a little ways upthread.

On my personal site I have a couple of image directories with auto-indexing enabled. The directories themselves aren't linked from anywhere on the site, and they're buried deep in the file structure (think /unindexed-dir/subdir/subdir2/) so access is limited to people who legitimately know about them.

[keyplyr]

...access is limited to people who legitimately know about them

Or any agent that's written to open consecutive directories.

[lucy24]

Well, if the agent is already doing that, then an automated directory index is not going to make any difference. But how often have you personally witnessed a robot visiting directories it isn't supposed to know about? I don't even find them snuffling around my /includes/ directory--which I foolishly gave that actual name--except when requesting standard WP filenames from a standard shopping list.

:: idly wondering, once again, what “fckeditor” officially stands for, because I remember the first time I saw the name it was in a non-English-language site and I thought it was just an unfortunate linguistic accident ::

[Dan99]

Exactly right. This is for people who legitimately know about them. Of course, I have an index.html to take care of everyone else.

[keyplyr]

how often have you personally witnessed a robot visiting directories it isn't supposed to know about?

Quite often actually... however you are using human logic, which doesn't apply to machines. Code just does what you tell it.

I think we've had this discussion a couple of times. A bot doesn't need prior "knowledge" to crawl all the files on a server, or an account. It just does what it is programed to do.

[Dan99]

I don't think a bot can get into directories it doesn't know about. That is, if I have a directory the URL for which has never been made public, a bot isn't going to find it's way to it by just nosing around in my domain. Sure, a bot could attack my domain by guessing directory names, in which case it might eventually hit on a real one. But I've never seen any evidence of such "guessing" attacks. All those unsuccessful guesses would be logged. Now, if you don't have an index.html file, yes sure, a bot could certainly nose around in your domain successfully.

I routinely make "secure" websites by just confidentially telling the intended recipient the URL.

[keyplyr]

You're missing the point. The bot doesn't "guess" the name of files... it doesn't need the names of files. The agent can be written to merely open the directory and get all files.

Unless you have some type of blocking method stopping me, I can get every file that's accessible on your server or your account.

I won't give examples, but most all scripting languages can do this.

[Dan99]

Hmm. That's interesting. Is there a way to prevent this? I've always sort of considered a URL as sort of a password to get in. If I don't tell you the URL, you can't know it's there.

I you try to get into my domain with http://example.com, my index.html will keep you from getting any further. But maybe not?

I keep public files and private files in my domain. The bots regularly ransack my domain for the public files. But my records don't show any of them getting my private files. If the bots know my domain, and they know how to get everything in it, you'd think they would have done it.

[edited by: phranque at 9:36 am (utc) on Nov 20, 2017]
[edit reason] exemplified domain [/edit]

[keyplyr]

Good info here: Blocking Methods [webmasterworld.com]

[lucy24]

The agent can be written to merely open the directory

What does this look like in site logs?

[keyplyr]

What does this look like in site logs?

Depending on how your server access reports are set up, most of these directives will display in the GET string, but others won't display at all... just the file request.

[phranque]

The bot doesn't "guess" the name of files... it doesn't need the names of files. The agent can be written to merely open the directory and get all files.

how does this bot discover this directory without "guessing" the path if it isn't linked anywhere?

most of these directives will display in the GET string, but others won't display at all... just the file request.

could you elaborate on this?
in my experience the server access log entries for GET requests display the path to the requested resource whether it is a directory or a file or otherwise.
what "directives" are displayed in the GET string?

[lucy24]

just the file request.

The only requests I have ever seen for /hidden-directory/ (I have a couple of them) are from humans who previously viewed /hidden-directory/subdirectory/sub-sub-dir/ linked from a legitimate site, and now they're experimentally backtracking. And, as noted above, nobody ever cold-requests the bare /includes/ directory except as part of a shopping list.

I remain unconvinced that this is a serious problem that the average website has to spend extra time addressing.

[keyplyr]

I remain unconvinced that this is a serious problem that the average website has to spend extra time addressing.

No not a "serious problem" at all. My comments weren't concerning "hidden directories" either. I only said that a bot doesn't need to know the name of a file it requests. It can just GetFiles() which will return a file list from the current directory. Then it knows :)

That's all I'll say about it. I don't want to teach how to scrape someone's site.

[Dan99]

Well, as I said, I don't know of any bots that know how to "scrape someone's site", because I've never had it happen to me. That's assuming a GET is logged as a GET. Now, you would think that if there were such a scheme, EVERYONE would know about it, and bots would be scraping sites left and right. So I guess it's one of these security threats that no one knows about? I'd be inclined to believe it if I were to hear about someone whose site was compromised in this way. If Apache knew about this, I suspect there would be a lot of hair getting pulled out.

[keyplyr]

Dan99 - bots do scrape sites "left and right." In fact, it is highly doubtful your site has not been scraped thousands of times, unless it has only been online a few days.

Most of Your Traffic is Not Human [webmasterworld.com]

[Dan99]

No, my site has NOT been scraped of files that I consider "secure". That's what we're talking about here. Yes, bots regularly scrape my site doing GETs of files that I have made public, and the URLs are in the public domain. But they've NEVER done a GET on files I have not made public. If they try, then they're failing. You're saying there are ways for people (or bots) to get files I've never revealed to anyone. I'm saying that, as far as I'm concerned, it doesn't happen.

Let's not get off topic here. We're talking about people (or bots) getting access to files that they wouldn't have otherwise known about. We're not talking about general bot scraping, which everyone endures.

[keyplyr]

I just replied to your statement:

Well, as I said, I don't know of any bots that know how to "scrape someone's site", because I've never had it happen to me.

Above, I said

Unless you have some type of blocking method stopping me, I can get every file that's accessible on your server or your account.

So if your "secure" files block access, then no, I would assume bots cannot get to them.

[Dan99]

My secure sites block access only that people don't know their URL. If they can find their URL, they're easily scraped. I think we're done here.