Re: Session ID

by "Keith Sellars" <Keith(at)webgraffix.com>

 Date:  Tue, 17 Sep 2002 17:15:34 -0400
 To:  <hwg-languages(at)hwg.org>
 References:  S0026260871 yerpso S00262608712 yerpso2 S00262608713
  todo: View Thread, Original
http://www.schoolpad.net/lauri_phpinfo.php

Paul and everyone,

Above is the phpinfo link if this will help at all.

Thanks,
Keith D Sellars
WebGraffix
www.webgraffix.com

"Making database sites seem easy"

----- Original Message -----
From: "Paul Roberts" <mail(at)paul-roberts.com>
To: "Keith Sellars" <Keith(at)webgraffix.com>
Cc: <hwg-languages(at)hwg.org>
Sent: Tuesday, September 17, 2002 4:00 PM
Subject: Re: Session ID


Hi Keith just tried the url's and
http://www.schoolpad.net/webadmin/indexTEST4.php
did not set a cookie it just prints the session id to the screen, and I'm on
accept all cookies, medium made no difference.

Paul Roberts
http://www.paul-roberts.com
mail(at)paul-roberts.com
++++++++++++++++++++++++
----- Original Message -----
From: "Keith Sellars" <Keith(at)webgraffix.com>
To: <hwg-languages(at)hwg.org>
Sent: Tuesday, September 17, 2002 5:25 PM
Subject: Re: Session ID


Hank and everyone,

Here is the situation so far regarding this problem:

I have run several scripts to check things (gotten them to run them from
their location):

1)
http://www.schoolpad.net/webadmin/cookie1.php followed by
http://www.schoolpad.net/webadmin/cookie2.php.  This told me that their
system was indeed setting cookies.

2)
http://www.schoolpad.net/webadmin/indexTEST4.php.  This told me that
session_start and session_register were indeed working properly.

NOW, here's the dilemma.  When a user logs in to the system, session_start
and session_register are invoked to assign the user a PHPSESSID, which is
then stored in the database.  Doing the above (test4.php) DOES indeed show
that it is possible to assign a Session ID to the user and that cookies can
be set (cookie1.php and cookie2.php).  However, when our program is run from
their server through a normal login means, for some reason, a PHPSESSID
appears to NOT be assigned.  Since the script kicks the user out to an
"error" page if a PHPSESSID is equal to "" (no value), this becomes a
problem.  This is what I cannot figure out - if I can run the indexTEST4.php
script and see that it is indeed setting the PHPSESSID, then why on earth
would it NOT be working when the program is run from our servers?

Here is the basic sequence of events when a user logs in:
The user goes to login.php.
The user types in their password/username.
The login.php script runs several checks to determine what level of admin
the user is, and then inserts several values into one of the database
tables, one value which is $PHPSESSID.
Upon a successful match of password and username, the user is then
redirected to webadmin/index.php.
The webadmin/index.php file calls the following function:
getLogin($PHPSESSID, $REMOTE_ADDR, $DBName, 1)
...from a central PHP file (file that contains most of the common
functions).
This central PHP file then runs the getLogin function which runs a database
query that contains:
Sessions WHERE SessionID = '$PHPSESSID'" (thus calling the value that has
just been written to the database and returning this value to the
webadmin/index.php page).
The webadmin/index.php script then checks for the existence of a $PHPSESSID
value. Upon finding a value present, it present the appropriate content to
the user. Upon finding that no $PHPSESSID value exists, the user is
presented with text that reflects a log in error.

Based on the test scripts I've posted above, and the sequence of events that
I describe directly above, what could be the cause of this?  Could it be
related to the version of browser they are running?  I've asked them to
upgrade to IE 6.0 (they are running 5.5 right now).

ANY HELP AT ALL would be greatly appreciated.  I've determined WHAT is
happening to a large degree, just not WHY!!!

Thanks,
Keith D Sellars
WebGraffix
www.webgraffix.com

"Making database sites seem easy"

HWG: hwg-languages mailing list archives, maintained by Webmasters @ IWA

This page is part of a preserved archive of archives.hwg.org. The site is no longer active and its content is not maintained. For enquiries about this archive, write to archive(at)iwanet.org.