on 10/09/02 1:01 PM, Jiaqing Wang ([EMAIL PROTECTED]) wrote:

> Hello, Everyone,
> I'm having some problem with the session handling in my code, it's kind of
> hard to explain the whole problem but let me try.
> I currently have a login page login.php which will take user input for
> userid and passwd and check them against my backend PostgreSQL database,
> after the password is verified I then open a session with
> 
> session_name($_POST['userid']);
> session_start();  <--  presumebly this will set a cookie with session_name
> as the cookie name and session_id as the cookie value

usually PHPSESSID is the name of the cookie, and I tend to leave it like
that.  I'd name it something else other than $_POST['userid'] though... the
whole point of sessions is to store a session id on the client side (usually
a long number), and store all the sensitive data (usernames, passwords, etc)
on the SERVER SIDE, associating them with the session ID.

at this point you haven't assigned any values to the session.  If you want
the userid to be available on other pages (a session!!!), you shouldn't name
the session after the userid.

assuming you have PHP > 4.1:

<?
// login page
// validate $_POST['userid'] first

if($validuser)
    {
    session_start();
    $_SESSION['userid'] = $_POST['userid'];
    }
?>


> then I redirect user to his/her own custome page (like my place or my site)
> using "header("Location: https://www.domain.com/cgi/mysite?userid=$userid";)"
> function call. in "mysite.php" script I will then open the session with the
> session_name with
> 
> session_name($_GET['userid']);
> session_start();  <--presumebaly this will get the session opened previously
> by login page.

No.  The whole point of sessions is that you don't have to carry the userid
around in the URL.  You just redirect to wherever you want:

<?
// login page
// validate $_POST['userid'] first

if($validuser)
    {
    session_start();
    $_SESSION['userid'] = $_POST['userid'];
    header("Location: https://www.domain.com/cgi/mysite.php";);  // added
    }
?>

Then on subsequent pages (the rest of your site), you check to see who your
user is with this code:

<?
session_start();
echo $_SESSION['userid'];
?>

Make sense?

I've been trying tog et enough time together to write an article about this
stuff, but for the moment, you need to do some more research and get a grip
on what sessions are really used for.

Just as an example, you could assign more variables (user preferences for
example) to the session at login time (or at any time during the session):

$_SESSION['favcolor'] = 'blue';
$_SESSION['shoesize'] = '14';
$_SESSION['language'] = 'en';
$_SESSION['pageviews'] = $_SESSION['pageviews']++;
$_SESSION['blah'] = 'foo';
$_SESSION['blahblah'] = 'foo foo';


There's a nice article on webmasterbase.com in the PHP section by Kevin
Yank.  The code is a little out-dated (pre $_SESSION and all the superglobal
arrays, so you'll need register_globals on in your php.ini for it all to
work), however, it's clean, and he does a great job of explaining it all.
You should read it, twice :)

It was the basis of my session code a while back.


In theory, any pages you call on your site which have
<? session_start(); ?> as the first line will maintain a COOKIE based
session.  If you do not call session_start(), you *may* loose the session,
even under cookies.

If users don't have cookies, your sessions won't work at this stage... the
sid needs to be passed around in the URL.


> This arrangement works correctly in the regular IE v5 and Netscape v4.72
> without a problem, I can tell the session is being opened by login.pho page
> and passed onto mysite.php page. However, it doesn't work in frameset/frame
> setup at all, for example, if I put the whole login.php page which is
> login.php under a frame within a frameset
> 
> <frame src="cgi/login.php" target="body">

The concept of having framed content is fine if you are using cookie based
sessions, as long as each framed page (the frameset and all pages within it)
call session_start()... otherwise (again) you need to pass the sid to the
framed page through the URL.


> The problem is that I can't get the same session previously opened in
> login.php in mysite.php, mysite.php will start a different session if it
> can't find previous opened session with session_name as "userid" as this is
> the default behavior of session_start() function. So I assume that login.php
> either didn't set the cookie or the cookie can't be read by mysite.php.

see above :)  I think your session setting code aint working the way you
intended, and certain not the way PHP developers intended.


> If it helps the situation, I also noticed that my SSL cerificate warning
> page being prompt twice, the first time is when opening page login.php(it's
> also under https), the second time is when opening mysite.php, I'm currently
> using self-signed certificate so every time the https page opens up in a new
> browser it will prompt you for whether or not accept the ceritificate).

Sure, there may be some issues with SSL.  A great way to make sure would be
to develop the code WITHOUT SSL, get it working (at the moment I don't think
your code is working), and THEN try to get it working with SSL... that way
you can eliminate SSL as the immediate problem.


> I'm currently runing php v4.2.0 on a solaris 2.7 box with apache
> v1.3.26/mod_ssl-2.8.10-1.3.26. If you need any more info to help me with it,
> let me know.



Justin French


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to