|
Home > Archive > Apache Server configuration support > October 2005 > .htaccess and 'require user'
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
.htaccess and 'require user'
|
|
| Stan Brown 2005-10-24, 6:18 pm |
| I posted this query a couple of weeks ago, and got no replies. I'm
hoping this time someone will be able and willing to answer.
I'm doing basic authorization, but after I type in the user and
password my browser simply repeats the prompt.(**) This happens in
both MSIE 6 and Mozilla 1.7, so I don't think it's a browser problem.
(See lynx output below.)
The identical problem occurs with my ISP's Apache 2.0 and with the
Apache 1.3 that I run on my own computer under Windows XP. Thus I
don't think it's anything flaky my SP did.
The URL in question is
http://oakroadsystems.com/zz/
which (for test purposes) should pop up a cartoon about the Greek
"periodic table". When I remove the .htaccess file, that page does
display.
My .htaccess file, in the same directory, is
AuthUserFile ../.htpasswd
AuthName Bookmarks
AuthType Basic
require user bite
The associated password in ../.htpasswd(*) is "me" (lower case, no
quotes), created with the htpasswd program. I used only the -c option
in htpasswd, no special encryptions.
Both .htaccess and ../.htpasswd have a permission mask 644, rw/r/r.
There's also an .htaccess file in the root directory. I don't think
it's relevant, but I'll post it if requested.
(*) I also tried specifying the password file with an absolute path:
no difference in result.
(**) The tutorial at
<http://httpd.apache.org/docs/1.3/howto/auth.html> says you can get
double prompts if there's redirection going on. I'm sure there isn't,
but just in case I went through re-entered the user and password a
second and a third time when requested by my browser. Authentication
definitely isn't working for me.
(***) Lynx output:
F:\> lynx -dump -head -auth bite:me http://oakroadsystems.com/zz/
Looking up oakroadsystems.com
Making HTTP connection to oakroadsystems.com
Sending HTTP request.
HTTP request sent; waiting for response.
Alert!: Access without authorization denied -- retrying
Retrying with access authorization information.
Looking up oakroadsystems.com
Making HTTP connection to oakroadsystems.com
Sending HTTP request.
HTTP request sent; waiting for response.
Alert!: Can't retry with authorization! Contact the server's
WebMaster.
Can't Access `http://oakroadsystems.com/zz/'
Alert!: Unable to access document.
lynx: Can't access startfile
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com
Modern cyberspace is a deadly festering swamp, teeming with
dangerous programs such as "viruses," "worms," "Trojan horses,"
and "licensed Microsoft software" that can take over your
computer and render it useless. --Dave Barry
| |
| Purl Gurl 2005-10-24, 6:18 pm |
| Stan Brown wrote:
(snipped)
> I'm doing basic authorization, but after I type in the user and
> password my browser simply repeats the prompt.(**)
> The URL in question is
> http://oakroadsystems.com/zz/
Your .htaccess should be located in your zz directory.
> My .htaccess file, in the same directory, is
> AuthUserFile ../.htpasswd
> AuthName Bookmarks
> AuthType Basic
> require user bite
AuthType Basic
AuthName "Bookmarks"
AuthUserFile c:/apache/path/to/password.dat
require user bite
Use a full path to your password data file.
Use a password file name other than .htpasswd
Delete your current password file.
Rewrite your .htaccess in your zz directory as shown in my syntax.
Run from a command prompt in your htpasswd executable directory:
htpasswd -c c:/apache/path/to/ password.dat
Note a space before password.dat and plugin your own path.
enter your password twice as prompted.
--
Your logon is failing because Apache cannot find your password file
or read permission is off, which you might have overlooked although
it appears you checked. Double check your permission for www group
which is often thought of as "anyone" for simple context; rw r r
Another possibility is your password file is corrupt, or you did
not enter data correctly when your password file was created.
Sometimes, but very rarely, UseCanonicalName on will cause a problem.
Doubtful this is a problem, but you can test by turning that off in
your httpd.conf file and restarting Apache. This is a very rare problem.
You will do better to delete your password file, create a new one,
then write your .htaccess as per my example. Double check your
path, double check your read permissions. If this fails, delete
again, start over.
Be sure to close your browser to destroy your user / password cache
during testing. You MUST close your browser to destroy that cache.
Purl Gurl
| |
| Purl Gurl 2005-10-24, 6:18 pm |
| Purl Gurl wrote:
> Stan Brown wrote:
(snipped)
[vbcol=seagreen]
> Your logon is failing because Apache cannot find your password file
> or read permission is off, which you might have overlooked although
> it appears you checked. Double check your permission for www group
> which is often thought of as "anyone" for simple context; rw r r
Following up on this in a different context, you may not need to enable
read for www (anyone) depending on your server configuration. There are
issues of "ownership" or more common whose name is the server running
under. Usually this is Apache. Once you have all "things" working, you
should turn off read permission for www, perhaps even local group, for
the directory containing your password file, and discover if your
logon / password continues to work correctly; rw - -
Windows XP is somewhat different but a simple matter of configuration
of your file security, "not share" versus "share" for others. Turn off
file sharing and test. Should work fine on XP with no file sharing with
Apache running in the same Windows user account as your password file.
If your server configuration requires read permissions for everyone,
create a special directory for your password file. Do not allow read
permission for root directories.
Is is a good practice to restrict access as much as possible. Turn off
permissions whenever possible, server wide.
Chances are very good you do not need to enable read permissions. Test this.
Purl Gurl
| |
| Stan Brown 2005-10-24, 6:18 pm |
| Mon, 24 Oct 2005 11:19:45 -0700 from Purl Gurl
<purlgurl@purlgurl.net>:
> Stan Brown wrote:
>
>
> Your .htaccess should be located in your zz directory.
As indeed it is. :-)
> AuthType Basic
> AuthName "Bookmarks"
> AuthUserFile c:/apache/path/to/password.dat
> require user bite
>
> Use a full path to your password data file.
As I mentioned, I tried that and it made no difference.
> Use a password file name other than .htpasswd
Why? If you're giving general security advice, okay, but I hope
you're not saying that there is some reason why the filename
".htpasswd" won't work.
> Delete your current password file.
>
> Rewrite your .htaccess in your zz directory as shown in my syntax.
Already done, as I said.
> Your logon is failing because Apache cannot find your password file
> or read permission is off, which you might have overlooked although
> it appears you checked. Double check your permission for www group
> which is often thought of as "anyone" for simple context; rw r r
As I said, that is _exactly_ what permissions I've got.
> Another possibility is your password file is corrupt, or you did
> not enter data correctly when your password file was created.
Created it fresh, and the problem didn't go away.
> Be sure to close your browser to destroy your user / password cache
> during testing. You MUST close your browser to destroy that cache.
Yes, already done.
No disrespect meant, but most of the things you suggest are already
covered in the article I posted. None of them explain why
authentication isn't working.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
"You find yourself amusing, Blackadder."
"I try not to fly in the face of public opinion."
| |
| Purl Gurl 2005-10-24, 6:18 pm |
| Stan Brown wrote:
> Purl Gurl wrote:
(snipped)
[vbcol=seagreen]
[vbcol=seagreen]
[vbcol=seagreen]
> As I mentioned, I tried that and it made no difference.
Your syntax displays a relative path and your syntax
is ordered differently and written differently than
that suggested by Apache porters.
[vbcol=seagreen]
> Why? If you're giving general security advice, okay, but I hope
> you're not saying that there is some reason why the filename
> ".htpasswd" won't work.
A period in front, otherwords no filename but a file extension,
"might" prove problematic on your system. This should be tested.
You are using the name of an Apache executable for your file. Doing
so could lead to a mistake when dealing with files, like deleting
your excutable instead of your password file.
[vbcol=seagreen]
[vbcol=seagreen]
> Already done, as I said.
Your syntax is not standard issue.
[vbcol=seagreen]
> As I said, that is _exactly_ what permissions I've got.
Double check and be sure.
[vbcol=seagreen]
> Created it fresh, and the problem didn't go away.
Delete it and try again.
[vbcol=seagreen]
> Yes, already done.
You must do this before testing a new password file and before testing
a new .htaccess file. There are those who are unaware your browser
has a cache for this purpose, which is static and cannot be changed.
> No disrespect meant, but most of the things you suggest are already
> covered in the article I posted. None of them explain why
> authentication isn't working.
One or more of those items do explain what is wrong. You have yet
to discover which. Engaging in argument with those who afford advice
for free, will not resolve your problem.
However, methodical step-by-step testing will. It is best, under failure
circumstances with no discernable reason for failure, to simply delete
everything and begin again, in a very careful methodical step-by-step
fashion, closely following Apache documentation. My advice is simply
a reflection of documentation in different words.
Good luck.
Purl Gurl
| |
|
| "Purl Gurl" <purlgurl@purlgurl.net> schreef in bericht
news:435D5FA2.6080202@purlgurl.net...
> Stan Brown wrote:
What's in the error_log ?!
[vbcol=seagreen]
A relative -not starting '/'- path is allowed, BUT it starts at server_root,
RATHER than document_root; the two are likely not the same. A full path to a
file outside the tree of folders holding the published documents is highly
recommended.
[vbcol=seagreen]
> Your syntax displays a relative path and your syntax
> is ordered differently and written differently than
> that suggested by Apache porters.
http://httpd.apache.org/docs/2.0/howto/auth.html indeed shows
AuthType Basic
AuthName "By Invitation Only"
AuthUserFile /usr/local/apache/passwd/passwords
AuthGroupFile /usr/local/apache/passwd/groups
Require group GroupName
Note the order of directives and the use of capitals.
> A period in front, otherwords no filename but a file extension,
> "might" prove problematic on your system. This should be tested.
Very small change that applies to Apache/2.0.46 (Red Hat)
> You are using the name of an Apache executable for your file. Doing
> so could lead to a mistake when dealing with files, like deleting
> your excutable instead of your password file.
The executable neiter has a leading dot, nor resides in the same folder.
HansH
| |
| Purl Gurl 2005-10-24, 8:49 pm |
| HansH wrote:
> Purl Gurl wrote:
(snipped)
A bit off topic
[vbcol=seagreen]
[vbcol=seagreen]
> The executable neiter has a leading dot, nor resides in the same folder.
You do not need to wear reading glasses, yes? A bit of reality humor.
Recently I bought a new 19 inch flat panel monitor for myself so I can
better see what I am doing. I still need to wear reading glasses, however.
Last week a severe lightning storm came across our hilltop, lightning struck
all about, including within five yards of our house. During this storm, we
had arcs of electricity dancing around our television rabbit ears. If are
you are unfamiliar with rabbit ears, you are way young!
I did have sense enough to unplug everything, except I forgot to disconnect
the broadband cable to our server's modem. Deserved what I got, which is a
modem which literally went up in smoke, even caught fire.
Next day, I need to read the MAC address off a new modem, recite it over
the phone to a tech at our backbone server. I use a magnifying glass
to read that MAC address; it is critical to not make a single mistake.
Use of filenames, the same filenames with only a difference of a period,
is not a good practice, especially if you see as well as I do.
You comment Apache's htpasswd executable is in a different directory.
Mine isn't. I moved it from "bin" to the directory where I keep my
password data files. That is where I create password data files, that
is where the executable should be; no need to type in a full path to
a different directory, which increases chances of a mistake.
As a programmer, this caution of not using the same filename twice,
or very similar filenames, relates to care given to not use the same
variable name, twice, nor very similar variable names. Programmers
know to use unique variable names to minimize risk of mistake.
Working with networks, you are running your program editor on your test bed
machine, fine tuning a program on your localhost, once complete, then to be
moved to your public Apache server. You are working with two files, same name,
but on different machines, through a LAN and opening, editing, saving, with
only a single program editor. I frequently make mistakes by opening or saving
the wrong file by not noticing I am accessing the wrong machine. One program
contains URL addresses of localhost, the other, www.purlgurl.net for a host.
Same file, same program, different server names. I make mistakes because of
that. These mistakes I make are contributed to not paying attention and
poor eyesight, more so to not paying attention.
Use of the same filename or almost the same filename, combined with not paying
close attention, will bite your big butt every time.
Good work habits dictate you minimize "mistake risk" in every way possible.
Using the same filename multiple times, or using very similar filenames,
simply is not a good work habit.
On "mistake risk," almost always problems with Apache, with programming,
with just about anything, is related to high mistake risk, which is a
reflection of not being careful, not paying attention, making assumptions
without testing, not following documentation, or simply being a typical
arrogant know-it-all. Otherwords, a high mistake risk is your own fault.
Purl Gurl
| |
|
| "Purl Gurl" <purlgurl@purlgurl.net> schreef in bericht
news:435D89F2.9090101@purlgurl.net...
> HansH wrote:
> A bit off topic
Over 24kb that was ...
folder.
[vbcol=seagreen]
> You comment Apache's htpasswd executable is in a different directory.
> Mine isn't. I moved it from "bin" to the directory where I keep my
> password data files. That is where I create password data files, that
> is where the executable should be; no need to type in a full path to
> a different directory, which increases chances of a mistake.
Diverting from the documentation may serve _your_ needs better, but should
not lead you in guiding _others_. On the other hand I should more often
refer to a default installation -and the variation per (re)distribution-
Although the issues you raise are true in general, the multitude may confuse
the troubled user even more. For instance stating both 'follow the manual'
AND 'don't use the filename there advised', may at first sight feel
contradictive.
HansH
| |
| Stan Brown 2005-10-25, 5:56 pm |
| Hans, thanks for taking the trouble to help me. I've tried the
things you suggest.
I apologize for the length of this article, but I hope I have all
relevant information here plus some questions based on what you said.
Details are below, but first an overview:
I've changed directives as you suggest, I'm no longer using
".htpasswd" as file name, and I've changed the path to an absolute
one. The public server (Apache 2.0.46) still is unable to find the
password file; the private server (1.3) on my PC now finds the
password file but says authentication failed.
My new .htaccess file:
AuthType Basic
AuthName "Bookmarks"
AuthUserFile /home/oakroadsystems/password
AuthGroupFile /dev/null
Require user bite
Just to review: public "oakroadsystems.com" server (hosted by
net1plus.com) runs Apache 2.0.36; local Apache 1.3 server on my own
Windows PC, responds only to 127.0.0.1.
Tue, 25 Oct 2005 01:39:06 +0200 from HansH <hans@niet.op.het.net>:
> What's in the error_log ?!
D'oh! I feel embarrassed to admit that I didn't think to look at the
error log. THANK YOU for pointing out this important debugging step.
========================================
=======================
Local machine (Windows XP, Apache 1.3 server answers 127.0.0.1 only)
========================================
=======================
On my local machine, I copied the above file but changed to the
correct Windows path for the password file. Now Apache 1.3 finds the
password file, but can't authenticate. The error log shows
user bite: authentication failure for "/zz": password mismatch
Question: has htpasswd (the program) changed? Does it now create
passwords that Apache 1.3 can't read? I know there are additional
options, but I didn't use any of them: just -c to create the password
file. I tried two things:
(a) Just to be certain the changed filename wasn't an issue, I
repeated
htpasswd -c password bite
and downloaded the result (once in binary, once in ascii).
(b) I tried editing the password file locally, putting "me" in clear
text. Now Apache 1.3 does authenticate; that's why I think there may
be an issue of the modern htpasswd program creating a password that
old Apache 1.3 can't read.
I'll talk about the error log of the public machine below.
> A relative -not starting '/'- path is allowed, BUT it starts at server_root,
> RATHER than document_root; the two are likely not the same.
Thanks -- I assumed (wrongly) that relative paths were relative to
the directory containing .htaccess. This is clear to me now, and as
you see above I've changed the path to an absolute.
> http://httpd.apache.org/docs/2.0/howto/auth.html indeed shows
> AuthType Basic
> AuthName "By Invitation Only"
> AuthUserFile /usr/local/apache/passwd/passwords
> AuthGroupFile /usr/local/apache/passwd/groups
> Require group GroupName
>
> Note the order of directives and the use of capitals.
Question: Are you saying the directives are case sensitive? I didn't
think they were, but I have changed require to Require as shown
above.
Question: Do I need an AuthGroupFile directive since I'm not actually
doing any authentication by group? I didn't think so, but I added one
to match your sample.
> Very small change that applies to Apache/2.0.46 (Red Hat)
Question: Are you saying that Apache 2.0.46 _does_ have a problem
with a leading period on a filename? I've changed the filename to
"password" as you see, but am I understanding you right?
========================================
=======================
Public machine (UNIX, Apache 2.0.46 server for oakroadsystems.com)
(In case it's relevant: This is one of several sites hosted at
net1plus.com, so I don't have access to httpd.conf, but I can read
the error log and access log. In the filesystem, my home page for
shell is /home/oakroadsystems and I use FTP to upload Web page files
to /var/www/html and subdirectories.)
========================================
=======================
Log file says
> (2)No such file or directory: Could not open password file: /home/oakroadsystems/password"
whether the AuthGroupFile directive is present or absent.
I don't understand this: I've tried
cat /home/oakroadsystems/password
and it displays the contents of the file. I've tried
ls /home/oakroadsystems/password
and I get
> -rw-r--r-- 1 oakroadsystems oakroadsystems 19 Oct 24 12:57 /home/oakroadsystems/password
So the file is there, and the permissions are fine, but Apache's not
finding it for some reason. What am I missing? Is this some sort of
file system issue that I ought to take up with my ISP? (Tech support
isn't very good, or I would have gone to them first. They want
everyone to use their shiny Control Panel, but I really want to do
this myself so that I can mirror my site on my home machine and test
everything before uploading.)
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
"You find yourself amusing, Blackadder."
"I try not to fly in the face of public opinion."
| |
|
| "Stan Brown" <the_stan_brown@fastmail.fm> schreef in bericht
news:MPG.1dc835e2fdeb57cf989ad0@news.individual.net...
> Just to review: public "oakroadsystems.com" server (hosted by
> net1plus.com) runs Apache 2.0.36; local Apache 1.3 server on my own
> Windows PC, responds only to 127.0.0.1.
WHY are your public and testing machines running different _major_ version
!? This is bound to back-fire on you !!
Note: a typo ... 2.0.46.
> On my local machine, I copied the above file but changed to the
> correct Windows path for the password file. Now Apache 1.3
> finds the password file, but can't authenticate. The error log shows
> user bite: authentication failure for "/zz": password mismatch
>
> Question: has htpasswd (the program) changed? Does it now create
> passwords that Apache 1.3 can't read?
> (b) I tried editing the password file locally, putting "me" in clear
> text. Now Apache 1.3 does authenticate.
The default encryption on Windows and Linux aka RedHat differs...
.... Linux default encryption is unavailable on Windows.
See under 'RESTRICTIONS' at
httpd.apache.org/docs/1.3/programs/htpasswd.html
and in between the lines at
http://httpd.apache.org/docs/2.0/programs/htpasswd.html
>I know there are additional options, but I didn't use any of them
The links above reveil your current plaintext paswords are not supported on
Limux. Newly create a password file on Redhat having the -m option added to
the commandline for htpasswd and download it again -no (apache
cros-versioning) warranty-
> Question: Are you saying the directives are case sensitive? I didn't
> think they were, but I have changed require to Require as shown
> above.
No, I supported the idea to stick with the manual while things are not
opperating at all.
> Question: Do I need an AuthGroupFile directive since I'm not
> actually doing any authentication by group?
No, as most directive this one is optional, just delete the line.
> Question: Are you saying that Apache 2.0.46 _does_ have a problem
> with a leading period on a filename?
I think it highly unlikely, but I'm not on RedHat and not using 2.0.46 so
cann't tell for sure.
> Public machine (UNIX, Apache 2.0.46 server for oakroadsystems.com)
> (In case it's relevant: This is one of several sites hosted at
> net1plus.com, so I don't have access to httpd.conf, but I can read
> the error log and access log. In the filesystem, my home page for
> shell is /home/oakroadsystems
This is your user folder ...
> and I use FTP to upload Web page files to /var/www/html and
subdirectories.)
.... your home page -the initial page shown at www.oakroadsystems.com- is at
some folder below /var/www/html
> Log file says
/home/oakroadsystems/password"[vbcol=seagreen]
>
> I don't understand this: I've tried
> cat /home/oakroadsystems/password
> and it displays the contents of the file. I've tried
> ls /home/oakroadsystems/password
> and I get
/home/oakroadsystems/password[vbcol=seagreen]
>
> So the file is there, and the permissions are fine, but Apache's not
> finding it for some reason. What am I missing?
The same clue I lack... let's try somthing:
Find your home page below /var/www/html and move your htaccess to its parent
folder and change your .htaccess accordingly.
In example: If your home page is
/var/www/html/oakroadsystems/docs/index.html move your file 'password' to
/var/www/html/oakroadsystems/.
> tech support isn't very good, or I would have gone to
> them first. They want everyone to use their shiny Control Panel,
This CP is there to keep you from making the most common user faults -and to
restrain you to their rules ;-) -
If the clue-less experiment does not solve the issue, use this CP (shortly
after midnight -EST or GMT-) to create or change a password file for you.
Than 'find /var/www/html/. -daystart - mtime 0 ' should list any file [you]
created or modified after last midnight ;-)
HansH
| |
| Stan Brown 2005-10-25, 8:50 pm |
| Tue, 25 Oct 2005 22:27:31 +0200 from HansH <hans@niet.op.het.net>:
> "Stan Brown" <the_stan_brown@fastmail.fm> schreef in bericht
> news:MPG.1dc835e2fdeb57cf989ad0@news.individual.net...
> WHY are your public and testing machines running different _major_ version
> !? This is bound to back-fire on you !!
> Note: a typo ... 2.0.46.
On the first point, the public server was running 1.3 until recently,
and I haven't got round to upgrading on my home PC. But you're right,
I should make them the same.
You're also right about the typo.
> The default encryption on Windows and Linux aka RedHat differs...
> ... Linux default encryption is unavailable on Windows.
> See under 'RESTRICTIONS' at
> httpd.apache.org/docs/1.3/programs/htpasswd.html
> and in between the lines at
> http://httpd.apache.org/docs/2.0/programs/htpasswd.html
Thanks.
Interestingly, the Apache 1.3 port for Windows comes with a htpasswd
program, with MD5 encryption as the default.
> No, I supported the idea to stick with the manual while things are not
> opperating at all.
Okay, fair enough.
> No, as most directive this one is optional, just delete the line.
Thanks. That's what I thought too. On the other hand, it's there and
not doing any harm. :-)
> I think it highly unlikely, but I'm not on RedHat and not using 2.0.46 so
> cann't tell for sure.
Sorry, I guess I didn't understand your original comment, "very small
change that applies to Apache/2.0.46 (Red Hat)".
> This is your user folder ...
> subdirectories.)
> ... your home page -the initial page shown at www.oakroadsystems.com- is at
> some folder below /var/www/html
That makes sense, but I've been unable to find out (on my own) where.
I tried
find /var -name winxptip.htm
because I know I have that file at oakroadsystems.com/tech, and my
output was
/var/www/html/tech/winxptip.htm
Adding the -follow option on find (dereference symbolic links) gave
me a bunch of error messages followed by the same single line of
output.
> /home/oakroadsystems/password"
> Find your home page below /var/www/html and move your htaccess to its parent
> folder and change your .htaccess accordingly.
> In example: If your home page is
> /var/www/html/oakroadsystems/docs/index.html move your file 'password' to
> /var/www/html/oakroadsystems/.
This is my problem -- the only Web home page I can see is
"/var/www/html". That can't be the actual directory, because then
everybody would have the same home page directory; but I don't know
enough to penetrate through whatever symbolic links (or something)
have been set up. But it's what get when I type 'pwd'.
> This CP is there to keep you from making the most common user faults -and to
> restrain you to their rules ;-) -
>
> If the clue-less experiment does not solve the issue, use this CP (shortly
> after midnight -EST or GMT-) to create or change a password file for you.
> Than 'find /var/www/html/. -daystart - mtime 0 ' should list any file [you]
> created or modified after last midnight ;-)
I think what I'll do is just break down and do what they want, use
the Control Panel. Then I can look at the .htaccess it creates and
see where it puts the password file. I'll report back.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
"That was a stupid lie, easy to expose, not worthy of you."
George Sanders as "Addison Dewitt" in /All About Eve/ (1950)
| |
| Stan Brown 2005-10-25, 8:50 pm |
| Tue, 25 Oct 2005 22:27:31 +0200 from HansH <hans@niet.op.het.net>:
> If the clue-less experiment does not solve the issue, use this CP (shortly
> after midnight -EST or GMT-) to create or change a password file for you.
> Than 'find /var/www/html/. -daystart - mtime 0 ' should list any file [you]
> created or modified after last midnight ;-)
I used Control Panel to add authentication for the directory in
question. Authentication now works, and the the .htaccess file in
that directory is
AuthUserFile /home/virtual/site7/fst/var/www/.htpasswd
AuthGroupFile /home/virtual/site7/fst/var/www/.htgroup
AuthName "Bookmarks"
AuthType Basic
<Limit GET>
require group TheChosen
</Limit>
When I try to 'cat' either of those two files, I get
> cat: /home/virtual/site7/fst/var/www/.htpasswd: No such file or directory
but I poked around and found them in the parent directory of my Web
home page directory. So through this back door I've now learned what
Apache expects by way of a path on the AuthUserFile or AuthGroupFile
directive.
Hans, thanks for your patience and especially for your gentle
reminder to check the error logs. Before then I was just spinning my
wheels looking for errors in my files; as soon as I looked in the log
I saw it was a path problem.
--
Stan Brown, Oak Road Systems, Tompkins County, New York, USA
http://OakRoadSystems.com/
"That was a stupid lie, easy to expose, not worthy of you."
George Sanders as "Addison Dewitt" in /All About Eve/ (1950)
|
|
|
|
|