Just wanted to give a public "thank you" to everyone, especially Hank, for
the help provided to me.  You guys are terrific.  To let everyone know, the
problem turned out to be that the "sessionGo" function was never actually
being called.  In most cases, the session was initiated anyway so everything
worked, but in this case the Session was NOT initiated (not the school's
fault, but ultimately the fault of the script not forcing the session to be
initiated).

A simple call to the sessionGo() function, which is located in the
commonREV4.php file, corrected things.

Thanks again to everyone (special thanks to Hank's help offlist).

Thanks,
Keith D Sellars
WebGraffix
www.webgraffix.com

"Making database sites seem easy"

----- Original Message -----
From: "Keith Sellars" <Keith(at)webgraffix.com>
To: <hwg-languages(at)hwg.org>
Sent: Tuesday, September 17, 2002 12: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