Sessions, authentication and $_SERVER

[Stephen Poley]

I'm trying to understand sessions and authentication.

I gathered that the only way of preserving data across script
invocations was to use a session. However I note that
$_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] are also preserved
across invocations and even from one script to another. How does this
work? (Are they repeatedly sent from the browser every time? If so, what
stops a site author from collecting a user name and password originally
entered for another site?) And how does one log off a user after
x minutes of inactivity?

If this is an RTFM question, I'd be happy with a pointer to the
appropriate bit of the M - I haven't managed to track it down so far.

I also note that $_SERVER contains entries which seem to have nothing to
do with the server, such as HTTP_USER_AGENT . Is there some logic here,
or is this just one of the historical accidents to which the IT world
seems so prone?

--
Stephen Poley
Barendrecht, Holland

[Kevin Thorpe]

Stephen Poley wrote:

I'm trying to understand sessions and authentication. I gathered that the only way of preserving data across script
invocations was to use a session. However I note that
$_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] are also preserved
across invocations and even from one script to another. How does this
work? (Are they repeatedly sent from the browser every time? If so, what
stops a site author from collecting a user name and password originally
entered for another site?) And how does one log off a user after
x minutes of inactivity? Those two variables are copies of the username and password passed to
the web server. If you request a password protected document from the
webserver without passing those the server will respond with an error
message. The browser will then pop up a window to ask for userid and
password and request the document again passing those parameters to the
server. Every request for that document or documents in subdirectories
will automatically have the userid and password appended by the browser
to avoid you having to reenter them. This is all site specific so you
don't need to worry about that. This simple authentication cannot handle
logging people off (at least from php), you have to use a different
method for that.
If this is an RTFM question, I'd be happy with a pointer to the
appropriate bit of the M - I haven't managed to track it down so far. I also note that $_SERVER contains entries which seem to have nothing to
do with the server, such as HTTP_USER_AGENT . Is there some logic here,
or is this just one of the historical accidents to which the IT world
seems so prone?

A web browser often sends extra information with a request. The user
agent string is one of those headers. It's sometimes useful to adjust
your output depending on the capabilities of the browser. I particularly
use this to present a different front page to search engines to make
their crawling work better.

Read RFC2616 for the full specification (if you don't mind a severe
headache).

[Stephen Poley]

On Thu, 21 Aug 2003 12:38:04 +0100, Kevin Thorpe <ke***@pricetra k.com>
wrote:

Stephen Poley wrote:

I gathered that the only way of preserving data across script
invocations was to use a session. However I note that
$_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] are also preserved
across invocations and even from one script to another. How does this
work?
<snip>

Every request for that document or documents in subdirectories
will automatically have the userid and password appended by the browser
to avoid you having to reenter them.
Thanks for the swift answer - that clarifies it. I've checked with a
script in a 'sister' directory, and then the username/password are
indeed not available.
This is all site specific so you
don't need to worry about that. This simple authentication cannot handle
logging people off (at least from php), you have to use a different
method for that.
So I gather the user-name/password could sit indefinitely in the
browser, but when a request is made after a timeout (managed via session
data) one can reissue the "401 Unauthorized" header and that forces the
user to re-enter them - is that right?

I also note that $_SERVER contains entries which seem to have nothing to
do with the server, such as HTTP_USER_AGENT . Is there some logic here,
or is this just one of the historical accidents to which the IT world
seems so prone?

A web browser often sends extra information with a request. The user
agent string is one of those headers. It's sometimes useful to adjust
your output depending on the capabilities of the browser.
My question wasn't quite clear - I was wondering why that data was in
$_SERVER specifically, and not $_GLOBALS or $_CLIENT or something. The
manual is rather vague.
Read RFC2616 for the full specification (if you don't mind a severe
headache).

I had indeed tried to, but I had failed to extract from it that the
browser would resend the credentials for further requests in the same
directory.

Thanks for your help.

--
Stephen Poley
Barendrecht, Holland

[Kevin Thorpe]

Stephen Poley wrote:

On Thu, 21 Aug 2003 12:38:04 +0100, Kevin Thorpe <ke***@pricetra k.com>
wrote:

Stephen Poley wrote:

I gathered that the only way of preserving data across script
invocation s was to use a session. However I note that
$_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] are also preserved
across invocations and even from one script to another. How does this
work?
Every request for that document or documents in subdirectories

will automatically have the userid and password appended by the browser
to avoid you having to reenter them.

Thanks for the swift answer - that clarifies it. I've checked with a
script in a 'sister' directory, and then the username/password are
indeed not available.

As indeed they should not. The way cookies work is somewhat similar
except you can specify an expiry date to keep them even after the
browser closes. Cookies give you somewhat more control over access and
you can write your own page to input the userid and password instead of
relying on the browser built-in.

This is all site specific so you
don't need to worry about that. This simple authentication cannot handle
logging people off (at least from php), you have to use a different
method for that.

So I gather the user-name/password could sit indefinitely in the
browser, but when a request is made after a timeout (managed via session
data) one can reissue the "401 Unauthorized" header and that forces the
user to re-enter them - is that right?

Yup, they're available until the browser is closed. You can reissue the
401 if you like to force re-entry. You can still do this even if the web
server isn't configured to ask for a userid and password. You would have
to check them yourself though to see if they were valid. There's a short
tutorial on performing HTTP authentication entirely in php at:
http://uk.php.net/manual/en/features.http-auth.php
If you only want your php docs protected then this is a perfectly
acceptable solution. Personally I use a perl module for authentication
as I have other documents (pdf,html,xls) which need protecting. It also
stops other people from getting it wrong and leaving unprotected docs on
the system (we use DAV as a shared document store).

Read RFC2616 for the full specification (if you don't mind a severe
headache).

I had indeed tried to, but I had failed to extract from it that the
browser would resend the credentials for further requests in the same
directory.

I'm not surprised, it's a huge document. It might not even be in there
at all. It could be a convention to assist users which isn't part of the
original RFC. I really can't be bothered to re-read the RFC though.

Thanks for your help.

[Jim Dabell]

Stephen Poley wrote:

On Thu, 21 Aug 2003 12:38:04 +0100, Kevin Thorpe <ke***@pricetra k.com>
wrote:

[snip]

This is all site specific so you
don't need to worry about that. This simple authentication cannot handle
logging people off (at least from php), you have to use a different
method for that.

So I gather the user-name/password could sit indefinitely in the
browser, but when a request is made after a timeout (managed via session
data) one can reissue the "401 Unauthorized" header and that forces the
user to re-enter them - is that right?

Yes, but bear in mind that under some circumstances the fields will appear
already filled in.

I also note that $_SERVER contains entries which seem to have nothing to
do with the server, such as HTTP_USER_AGENT . Is there some logic here,
or is this just one of the historical accidents to which the IT world
seems so prone?

A web browser often sends extra information with a request. The user
agent string is one of those headers. It's sometimes useful to adjust
your output depending on the capabilities of the browser.

My question wasn't quite clear - I was wondering why that data was in
$_SERVER specifically, and not $_GLOBALS or $_CLIENT or something. The
manual is rather vague.

The server variables are more than just information supplied by the client.
They are the environment variables passed down by the server, which can
include pretty much anything. Headers supplied by the client are usually
prefixed with 'HTTP_'. I guess nobody thought that it would be worth going
to the trouble of separating out the client headers from the rest of the
environment variables (it might not even be possible to do correctly).

Read RFC2616 for the full specification (if you don't mind a severe
headache).

I had indeed tried to, but I had failed to extract from it that the
browser would resend the credentials for further requests in the same
directory.

RFC 2616 is HTTP. You want RFC 2617, specifically:

"A client SHOULD assume that all paths at or deeper than the depth of the
last symbolic element in the path field of the Request-URI also are within
the protection space specified by the Basic realm value of the current
challenge. A client MAY preemptively send the corresponding Authorization
header with requests for resources in that space without receipt of another
challenge from the server."

-- <URL:http://www.ietf.org/rfc/rfc2617.txt>
--
Jim Dabell

[Kevin Thorpe]

>>>Read RFC2616 for the full specification (if you don't mind a severe

headache).

I had indeed tried to, but I had failed to extract from it that the
browser would resend the credentials for further requests in the same
directory.

RFC 2616 is HTTP. You want RFC 2617, specifically:

"A client SHOULD assume that all paths at or deeper than the depth of the
last symbolic element in the path field of the Request-URI also are within
the protection space specified by the Basic realm value of the current
challenge. A client MAY preemptively send the corresponding Authorization
header with requests for resources in that space without receipt of another
challenge from the server."

-- <URL:http://www.ietf.org/rfc/rfc2617.txt>

A very large bottle of aspirin to that man!