allowing directory access for authorized users
rj2n...@hotmail.com
will be doing basic authentication, not ssl, although later I might do
that).
a) How do I ensure that users can't bypass the password page by
creating a link into another page in the protected directory?
b) Once users have successfully logged in, how does apache allow these
users to go through this directory without prompting them every time
they visit a new page that is in in a protected directory?
I guess my question is: is basic authentication valid only for that
single page, or is that authentication already valid for the protected
directory? How do you control the scope of the basic authorization?
Robert Nagle, rj2n...@hotmail.com
Austin TX
Sent via Deja.com http://www.deja.com/
Before you buy.
David Efflandt
>I want users to login and give a password before entering a website. (I
>will be doing basic authentication, not ssl, although later I might do
>that).
>
>a) How do I ensure that users can't bypass the password page by
>creating a link into another page in the protected directory?
Because anything they request in a protected area using server
authentication requires that the browser supply the username and password.
>b) Once users have successfully logged in, how does apache allow these
>users to go through this directory without prompting them every time
>they visit a new page that is in in a protected directory?
The browser remembers the AuthName, username and password for that browser
session. If they exit and restart their browser, they would have to log
in again (unless they told MSIE to save their password).
>I guess my question is: is basic authentication valid only for that
>single page, or is that authentication already valid for the protected
>directory? How do you control the scope of the basic authorization?
It is valid for the scope of the authentication. If within tags like
<Limit> or <Files>, etc. it would only apply to whatever meets that
criteria. That is why it is not wise to put it within <Limit GET> (what
about POST and PUT, etc.) If it is in .htaccess without any limiting tags
around it, it would apply to all files in that dir or subdirectories of
that dir for ANY access method.
>Robert Nagle, rj2n...@hotmail.com
>Austin TX
>
>
>
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.
--
David Efflandt effl...@xnet.com http://www.de-srv.com/
http://www.autox.chicago.il.us/ http://www.berniesfloral.net/
http://hammer.prohosting.com/~cgi-wiz/ http://cgi-help.virtualave.net/
Peter W
> On Wed, 15 Mar 2000, rj2n...@hotmail.com <rj2n...@hotmail.com> wrote:
> >b) Once users have successfully logged in, how does apache allow these
> >users to go through this directory without prompting them every time
> >they visit a new page that is in in a protected directory?
>
> The browser remembers the AuthName, username and password for that browser
> session. If they exit and restart their browser, they would have to log
> in again (unless they told MSIE to save their password).
I believe Mozilla 5 (to be released as Netscape 6) also has a password
"wallet" feature. Not sure about other vendors.
> >I guess my question is: is basic authentication valid only for that
> >single page, or is that authentication already valid for the protected
> >directory? How do you control the scope of the basic authorization?
>
> It is valid for the scope of the authentication.
Right.
> If within tags like
> <Limit> or <Files>, etc. it would only apply to whatever meets that
> criteria.
Not exactly. If the server name[0], server port[1], and Realm string are the
same, then the browser will attempt to reuse cached user/password
information.[2] So you can apply access control to different areas using
different <Files> stanzas, but if it's the same virtual host and they use the
same Realm string, then users can access all the content after a single
login.
We do that in some cases where partial Location[3] matches require different
group membership. E.G., "*/university-only/*" and "*/faculty-only/*" use the
same Realm and backend auth system, though one has a more restrictive group
requirement. If a faculty member logs in to either area, her browser will
cache her username/password; since the other area has the same
server/port/realm, the browser will automatically log her in to the other
area. If we used different Realm descriptions, she would be presented with a
second auth box when visiting the other area.
-Peter
[0] As presented by the client, not the ServerName known to the httpd (I
believe)
[1] MSIE does (did? is this fixed in newer builds?) not care about port
changes, even though it's a security problem and violation of the RFC.
[2] Some clients will un-cache the information if they request content and
get a 403 error, though I don't believe this behavior is specified in any
RFC.
[3] Well, it's Netscape, so actually it's a "ppath" match, but the same
idea...
--
http://www.bastille-linux.org/ : working towards more secure Linux systems
Kurt J. Lanza
>
> I want users to login and give a password before entering a website. (I
> will be doing basic authentication, not ssl, although later I might do
> that).
>
> a) How do I ensure that users can't bypass the password page by
> creating a link into another page in the protected directory?
The server enforces this -- if a directory requires
Basic Authentication for access to its contents, so do
all its subdirectories. Regardless of what the browser
does.
>
> b) Once users have successfully logged in, how does apache allow these
> users to go through this directory without prompting them every time
> they visit a new page that is in in a protected directory?
Apache has nothing to do with this -- the browser knows
the above answer and automatically remembers the user
name and password for use whenever a URL refers to the
protected path.
>
> I guess my question is: is basic authentication valid only for that
> single page, or is that authentication already valid for the protected
> directory? How do you control the scope of the basic authorization?
See the Apache documentation for the various scoping
directives -- Directory, Files, etc.
>