Re: [PHP4BETA] Basic Authentication And HTTPS
| From: | Paul McGarry | Date: | Wed, 02 Feb 2000 06:57:58 +0000 |
| Subject: | Re: [PHP4BETA] Basic Authentication And HTTPS | ||
| References: | 1 | Groups: | php.version4 |
| Request: | Send a blank email to php-version4+get-9657@lists.php.net to get a copy of this message | ||
Mark Kirkwood wrote:
> 1 access the login page ( say login.php) via https and use header() to get $PHP_AUTH_USER etc (
> more or less as in the php3 documentation) .
> 2 use header() again to redirect to the start page ( say start.php ) but use http.
> The problem is that as soon as the switch from https to http occurs $PHP_AUTH_USER etc are
> unset. Is there any way for http to see these variables set using https ? - or would this mean that
> they are passed in plain text after the switch to http ?
It has to be this way, once you've done a basic auth for a particular
server, the browser sends the username/password with every page request
to that server. This is why auth and cookies aren't shared between https
and non-https servers, there would be no point in getting people to log
in securely initially, if the browser is going to send the login info in
the clear in every subsequent page view.
> I wondered about using cookies to save $PHP_AUTH_USER and PW...?
What you can do is
get them to login to
https://server/slogin.php
slogin.php then
a)Validates their auth info to a user
b)grabs loads of info to 'uniquely' identify the browser (IP
address/browser info and whatever else).
c)stores that data in a database with a server generated uid of some
sort ($UID) (a time is probably good too for periodically cleaning up)
d)redirects browser to http://login.php?UID=$UID
login.php then
a)Looks up $UID in the DB
b)Checks assorted info for validity
c)Sets a cookie to identify the user for the rest of the session 'as
per normal'.
d)Clears the record stored above from the database
There's slightly more to it than that as you have to consider several
things that can trip you up:
Eg browsers configured to use proxies for http and not https (and
therefore will have different IP addresses) etc etc.
For this reason it is probably better just to create a big-ass 'random'
UID that no-one would ever guess (or big enough so it would make more
sense for them to attempt to guess the username and password in the
first place), even if you are going to use the IP for cookie validation
from there on in.
I hope that helps, I was kind of making it up as I go along.