Help with .htaccess

[ffurtado]

Hello Members,

I would like to use the htaccess file holding User Ids and Passwords that I have on my *old* ISP server on a new account I just set up on FutureQuest.

As a test, I created a password protected folder using the Control Panel and added 1 user. I dowloaded the password file that was created to examine the id and password and here is what I found.

For Example:
USER ID: ashcraftd
PASSWORD: 1dpocket

Here is the Id/Pw created on FutureQuest Server and used in the password file:
ashcraftd:HNgFSwZPeG.yo

However, this is the Id/Pw created on my *old* ISP server:
ashcraftd:asvmrJz977ymw

My guess is that the encryption algorythm that FutureQuest uses is different than my old ISP server. ??? If I copy my file over to the new server as is, it probably will not work.

I do not want to manually ADD my 850 users via the Control Panel.
Can someone please offer a solution?

Thanks,
Fred

[Slim]

I think, from what you are saying, that you created a password entry on both machines, using the same password, and they didn't match in the encrypted file, right?

That is normal. If a password always encrypted the same way, then it would be too easy to decrypt passwords.

Try copying the entry directly into the password file, exactly as it is on your other server, and then see if it works. It probably will; I've moved password entries between hosts before with no problem.

[ffurtado]

Thank you.
I did not think of it that way.
I'll try adding a few Id / Pw from my old server passwd file to the new server passwd file.

[Terra]

You need to take into account the 4096 perturbing via crypt salting...

The salt is the first two characters of the crypted string...

run this at the command line:

$ perl -e 'print crypt("1dpocket", "HN")'
HNgFSwZPeG.yo



You'll find that applying the right salt will lead to the desired crypted result of the original...

--
Terra
--Don't let a slug cross your path when working with crypt()--
FutureQuest

[ffurtado]

I just tested the suggestion in the earlier Reply. The User Id and PW entered via the Control Panel worked fine. But the three Id's I added from my *old* server file to the new .passwd file would not work when I tried to log-in to my protected folder.

I'm just a novice here.

1. I don't know how to run the command you suggested:

$ perl -e 'print crypt("1dpocket", "HN")'
HNgFSwZPeG.yo

I do not have Active Perl installed on my computer if that is what is needed.

2. Even if I could do that, I have 850 user id/pw from my *old* server file that I would need to convert before I upload the modified .passwd file to this new server.

I was hoping I could find a utility or web site that could do a batch conversion for me. Using the Control panel one by one is going to be tough going!

[Terra]

The passwords are the same, the only thing that is different is the 'salt'... The crypt() ability (or passwords) will still do the right thing...

The only thing you need to do is upload your password file to our server (in ASCII mode) and point your AuthUserFile directive (within the .htaccess file) correctly to that password file...

Start small, get it to work, then upload the whole thing...

Please view the following tutorial:
http://www.aota.net/htaccess/pwprotect.php4

And yes, your ActiveState perl should suffice, unless it doesn't handle (or emulate) crypt() on a Mac or Windows...

What you are trying to do is only the first step... 850 username/password combinations is quite a lot of linear scanning that Apache must do for each access into the secured area... If you have > 50 users, then you will want to use the capabilities of mod_auth_db... You would need to have your technical webmaster convert to a mod_auth_db compliant hash file...

More details on this can be found at:
http://httpd.apache.org/docs/mod/mod_auth_db.html

Our servers are capable of handling both mod_auth and mod_auth_db, however we only provide tutorials for the mod_auth methods... Webmasters with >50 username/passwords usually have special needs and configure their mod_auth_db to meet those needs...

--
Terra
sysAdmin
FutureQuest

[ffurtado]

Thank you for that information. I will need some time to digest this. Off the top of my head, I thought I could create a .htaccess file with statements and point it to the location of the .passwd file.

Something like this:
<Limit GET POST>
#order allow,deny
#allow from all
require valid-user
AuthName Members
AuthUserFile /www/protect/.passwd
AuthType Basic
</Limit>

But, I do not understand the mod_auth_db you mentioned.

But this still begs another question.
Even if I got this working, how am I going to manage the User Id's and Passwords via the Control Panel if it has a limit of 50 users per folder?

I did not have to worry about this with my old ISP provider because they set it all up for me. All I did was make a call to some URL, log-in and I had access to add, edit, delete users etc. I do not know how this was accomplished.

Regards,
Fred

[Deb]

Even if I got this working, how am I going to manage the User Id's and Passwords via the Control Panel if it has a limit of 50 users per folder? There are a couple of options for bypassing the limits within the control panel. One would be to manage the passwords manually as explained in the tutorial located at http://www.aota.net/htaccess/pwprotect.php4

Another option would be to select a password management system and install it within your account. There are many such scripts available at places such as
http://cgi.resourceindex.com/Programs_and_Scripts/Perl/Password_Protection/
and
http://www.hotscripts.com/Perl/Scripts_and_Programs/Password_Protection/

The reason the control panel is limited to 50 is because that's the recommended maximum for users within an htaccess file. Password protecting this way requires the server to work in a linear fashion...for each request it has to start at the top of the file and read down until it finds the correct user..it has to continue doing this for each page they select. Once over 50 users it is usually best to switch to a mod_auth_db solution, as Terra explained above.

Hopefully something from the above will help you to find a solution for managing the excess of 800 users via your current .htaccess setup.

Deb
- Growing inside the box.

[Terra]

with my old ISP provider because they set it all up for me.
Obviously they did not care much about the extra performance hit their server was going to take for all the linear string matching scans...

Even though it may be more work on your end to implement a more resource friendly solution, both the FutureQuest server and your neighbors will appreciate it...

The command you are looking for to manage mod_auth_db hashes is: dbmmanage

Please read the following:
http://httpd.apache.org/docs/howto/auth.html

and the man page for dbmmanage:
http://httpd.apache.org/docs-2.0/programs/dbmmanage.html

(disregard any notes in there pertaining to "@AnyDBM::ISA array ", our dbmmanage is hardwired to do the right thing)

Additional resources can be viewed at:
http://www.linuxplanet.com/linuxplanet/tutorials/1527/1/
http://www.oreilly.com/catalog/apache2/chapter/ch13.html
http://linux.com/newsitem.phtml?sid=12&aid=3549
http://linux.com/newsitem.phtml?sid=12&aid=3667

--
Terra
--Sometimes a Mag light helps to find this stuff--
FutureQuest

[ffurtado]

Ok, I think I'm beginning get the idea. What I need to do is delete the existing files I created with the Control Panel to password protect my folder. Then I need purchase some kind of management program to manage my users.

I will assume:

- This program will create the *correct* type AuthUserFile directive using mod_auth_db, point to my .passwd file, and put its files in the appropriate folders when installed.

- That I can just upload my old password file to replace any file it may have put there.

- Once installed, I would then call this program via my browser to manage my Users.

Have I forgotten anything? Please advise if I am on the right track.

Also, I would really appreciate any recommendation for a Password Management Program that works well and *will* install this mod_auth_db properly.

Thank you again for your assistance.
Fred

[ffurtado]

Hello,

Per your suggestion, I found a script called "LockedArea" to manage .htaccess User Id's and Passwords. It uses a DB vice a flat file as you suggested for a folders with more that 50 users.

I set up my /protect folder and /cgi-bin/lockedarea with the permissions needed but I can not run the setup.cgi script when I call it from my browser. I keep getting a 500 server error. I checked the logs and found this:

%% [Sat Sep 21 18:20:13 2002] GET /cgi-bin/lockedarea/setup.cgi HTTP/1.1
%% 500 /big/dom/xrefcom/cgi-bin/lockedarea/setup.cgi
%request
Accept: */*
Accept-Language: en-us
Connection: Keep-Alive
Host: www.refcom.org
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
XXXXXXXXXXXXXXX: XXXXXXXXXXXXX
%response
%% [Sat Sep 21 21:37:00 2002] GET /cgi-bin/lockedarea/setup.cgi HTTP/1.1

I ran the debugger and got this

Opening File: Passed
Checking for zero file size: Passed
Checking for ASCII Upload: Passed
Checking for Interpretor Path (/usr/bin/perl): Passed
Checking File Permissions: Passed

Checking for Perl Module "variables.pl": Failed: Not Found
Checking for Perl Module "variables.pl": Failed: Not Found
Checking for Perl Module "mails.pl": Failed: Not Found
Checking for Perl Module "variables.pl": Failed: Not Found
Checking for Perl Module "variables.pl": Failed: Not Found

Will you please advise if there is something that needs to be activated for me on the server. I have tried everything I can think of to get this to work.

Thank you.
Fred

[Bob]

Hello Fred,

I note this from the Install directions that accompany this program:
I get a Internal Server Error when loading install.cgi.
# Try setting the directory with install.cgi in it to 755 rather than 777
If the directory is set at 777 it will not work properly on the FutureQuest servers and does need to be set at 755.

I hope this helps;)
-Bob

- The Devil :* is in the details -

Pssst, Fred take a look at this when you have a chance :)http://www.FutureQuest.net/Community/SiteOwner/

[ffurtado]

Thank you Bob
That did the trick!!
I changed permissions on other directories while *trouble-shooting*.

What should my cgi-bin be?
I now have 755

What should my /www/protect be?
This is where my entrie web site will really be located.
I changed it from 777 to 755

Fred

[Bob]

Hi again Fred,

Your cgi-bin should be 755, as well as /www/protect

Good luck and Welcome to FutureQuest :QTFQuest:
-Bob

[ffurtado]

Thanks to all of your help, my password protected folder appears to be working well. One very odd problem I have remaining concerns images.

I created a directory /images to store 3 gif files needed by the script.
I uploaded the 3 files there.

When the Password Manager Admin script is called, everything works fine but the 3 images are not displayed. I just get red X. This does not happen on any other web pages I visit.

I looked at the source for the page and see this tag:

<img src="http://www.refcom.org/images/top.gif">

but that .gif is not displayed on the page!

So I tried calling:
http://www.refcom.org/images/top.gif and I get a file not found!

Odd, because the files are there!

Any ideas?

[sheila]

Your images directory must be below your /www directory.

Excepting for the cgi-bin, all other files that are to be accessible to your site's visitors via their web browser must be placed in a folder that is below the /www folder.

Create a new folder at
/big/dom/xrefcom/www/images

and put your images inside that folder. That should do the trick.

;)

[ffurtado]

Thank you again!
That /www/images was what I needed. <Grin