At the top of every page ...

<? session_start();session_register( "origin" );$origin=$PHP_SELF; if( 
"PHP_AUTH_PW" ] !="grail" ) { if( !session_is_registered( "member_id" ) ) { 
header("Location: user_logon2.php\n"); } }?>

The "lancelot" and "grail" were used only so that ht:dig could index the 
site, so they can be chopped out. The "member_id" flag was set in 

User_logon2.php was a little more complex.  The goal was to allow only one 
user in from one browser on one machine, thus a series of checks was 
followed ...

1. If there was no cookie, then a regular login was displayed
2. If there was a cookie, its value was checked against the database, and 
if everything was OK (user wasn't blocked, etc.) then member_id was set. 
Member_id was only a semaphore and contained no value.
3. If there was a cookie, but it didn't validate correctly, access was 
denied and the user was asked to contact the office.
4. If there was no cookie, but the login values (user/pass) showed that one 
had been set from another machine or browser, access was denied and a 
message displayed to that effect, again with an invitation to contact the 

If I remember correctly, the "origin" var was set so that after the login 
check a valid user was returned to that page.

All this complexity was an attempt to solve a bad pass-around problem for a 
daily business newsletter. Yes it was very restrictive, but that one line, 
at the top, protected every page so no one could blast in from Google, etc. 
In the same way, it let the owners of the site do their editing in Front 
Page, and everything was OK, so long as they didn't touch it.

How did we use it? An email was sent each day to subscribers with an 
embedded link to the current day's news page. If the above check passed, 
then the newsletter, a PDF file, began downloading to their browser. Yes, 
IE 5.5 gave us a BUNCH of trouble, but that's another issue. When it 
worked, it was seamless - all the subscriber got was the news, which if 
they then wanted to pass around they had to save, write up an email and 
attach the pdf. A little more bother than simply forwarding a pdf sent to 
them directly.

Regards - Miles Thompson

At 10:22 AM 9/23/2002 -0500, Bryan McLemore wrote:
>you could make them log in once per session and just have every page check
>and see if they already have logged in and if they have not then trigger the
>login mechanism.
>Not sure exactly how to implement but I've read on the practice before.
>----- Original Message -----
>Sent: Monday, September 23, 2002 10:14 AM
>Subject: [PHP-DB] advise needed for 'authorized only' site
> > I have set up a section of my company site for use by authorized dealers
> > only. I am currently using
> > mysql authorization, which works for the first page, but if someone were
> > type in the url of an
> > underlying page they would be able to get in without authorization. I know
> > I could use .htaccess
> > for handling this but with a minimum of 350 -400 users to keep track of
> > that would be unwieldly to
> > say the least, especially for my boss who doesn't have a clue about *nix
> > and has never even heard
> > of .htaccess.
> >
> > What other options do I have to keep the underlying pages from being
> > accessed without the user
> > being forced to go through the logon screen?
> >
> > Thanks,
> >
> > --
> > Chip Wiegand
> > Computer Services
> > Simrad, Inc
> >
> >
> > "There is no reason anyone would want a computer in their home."
> >      --Ken Olson, president, chairman and founder of Digital Equipment
> > Corporation, 1977
> >  (They why do I have 9? Somebody help me!)
> >
> >
> > --
> > PHP Database Mailing List (
> > To unsubscribe, visit:
> >
>PHP Database Mailing List (
>To unsubscribe, visit:

PHP Database Mailing List (
To unsubscribe, visit:

Reply via email to