| [reply] |
RewriteEngine on
RewriteMap lowercase int:tolower
# allow CGIs to work
RewriteCond %{REQUEST_URI} !^/cgi-bin/
# check the hostname is right so that the RewriteRule works
RewriteCond ${lowercase:%{SERVER_NAME}} ^www\.[a-z-]+\.isp\.com$
# concatenate the virtual host name onto the start of the URI
# the [C] means do the next rewrite on the result of this one
RewriteRule ^(.+) ${lowercase:%{SERVER_NAME}}$1 [C]
# now create the real file name
RewriteRule ^www\.([a-z-]+)\.isp\.com/(.*) /home/$1/$2
# define the global CGI directory
ScriptAlias /cgi-bin/ /www/std-cgi/
This also changes the url to www.username.yourdomain.com, which your users would probably love...
Update
I just realized this doesn't solve the question of user authentication. <sigh> I'm tired. I need a vacation.
For authentication, combine this with mod_auth (not sure if that can be done dynamically) or .htaccess (which you were already doing).
Update 2
Another swing and a miss by bean! Strike two! While my suggestions are, of course, brilliant, I guess I didn't read the question very well - you want to use your perl script to show the users' directories. While the wisdom of doing this is debateable, I'll answer the question posed (perhaps you want to serve advertising on the directory listings, I don't know).
If your users can access their directory trees directly, follow my previous advice - otherwise ignore it.
.htaccess files won't help if the perl script is accessing the directories instead of apache. I'd suggest giving the user an encrypted cookie with her name in it (or a key the server can use to find the username) - then just check the name against the directory being accessed (I'm going to assume the username maps to the filesystem somehow). Be sure to collapse "/../" into "/" - and watch out for url encoded dots (you know how %20 is a space?). I think someone already suggested this...
Update 3
Ok, I thought of good reasons to do this in Perl - you want to provide filemanager-style access, right? So the user will be able to add/delete/move directories/files, upload, etc. In which case you will have to do some sort of cookie check against directory thing, and will have to deal with people trying to mess with the files of other people via "/../". I'm going to assume people will be able to access their files and therefore their directories directly (it would be sheer folly to try to reinvent the most basic function of Apache), so you'll have to do something like my previous suggestions as well if you want to keep them from seeing each other's files. I'm going to stop adding to this comment now - it's just near and dear to my heart, because I was once the head of the Orbita homepages system <sniff>. Good times... good times. Over and out. | [reply]
[d/l] |
You could use a config file that has patterns that match directories to allow or deny. Like this:
Allow=/home/you/openfolder
Deny=/usr/.*
Deny=/bin/.*
Default=Allow
Then just run the pattern against the current directory, if it matched and Allow pattern then show it, if it matches a deny pattern then show an error. If it doesn't match either, you could set up a default directive.
Each user that uses the script would only need to setup one of these files or you could just keep track of their rights in a DB.
You could authenticate, using a user/password and dropping a cookie.
| [reply]
[d/l] |
/me sets the query to /home/you/openfolder/../../../etc/passwd
=)
-Waswas
| [reply] |
You are probably better off using the .htaccess solution -- it is robust, time tested, and scrutinized. It is just far too easy to make mistakes when parsing directories. The .htaccess solution has already done the hard stuff for you. You just need to tell it what groups to allow in.
| [reply] |
You can also configure Apache to have README files displayed as part of the directory listing, and to have custom icons and/or file descriptions for each file type.
I agree with the others that this is a situation where you are better off using the existing platform, rather than re-inventing the wheel to run on top of it.
</ajdelore>
| [reply] |
You can set it up so that every time a user clicks on a directory it would call your script and check a cookie that is stored on the computer when they login. This cookie will contain the user login info and a session id or such. These values can be pulled and checked against the values stored in a DB. So in essence everytime a user attempts to navigate through the listing they relogin without knowing it. Now each directory should have permissions set for certain groups or users. So after the user's login info is verified you must verify that that specific user has access to the directory he is attempting to browse. | [reply] |