For new readers, the FAQ is at http://p2p.wrox.com/archive/beginnin...2002-11/17.asp

Well, session_register() tells PHP that a certain global variable should be considered a session variable. That means that at the end of the script's execution (which is when session data writes usually occur), the resulting value of that global variable will be written using the current enabled session handlers.

I don't like using plain global variables for special purposes like this because it obfuscates the meaning and context of a session variable. It's much easier and more readable, imho, to reference all session variables via $_SESSION.

In addition, using session_register() makes using $_SESSION screwy -- things don't seem to work right. The value of $_SESSION['foo'] is NOT guaranteed to be the same value as a global $foo that has been registered with session_register().

In fact, my test scrips suggest that if you register ANY session variables with session_register, the $_SESSION array is destroyed and/or emptied; that is, ALL your session variables must be explicitly registered.

Furthermore, if register_globals is on, then session variables are copied to the global scope as regular variables. You must reregister those variables as session variables or else they will be lost when the user moves to the next page in your site. You also have to worry about the order in which ECGPS variables are copied into global scope because of possible naming conflicts (which I think I described in the FAQ).

Make sense?


Take care,

Nik
http://www.bigaction.org/

__________________
Take care,

Nik

sorry for my innocence, i would like to know is it what you mean is with the use of $_SESSION[''] then we can ignore the use of session_register() and the session variable will be still exist in the following pages (or exist during the session)?
Thanks:D

$_SESSION is an array, so all your session variables exist as indexes in that array.

The old way, you'd use

session_register("my_var");
$my_var = "Hello, world.";

The new way, you'd simply access the my_var variable as an index into the $_SESSION array, not a standalone global variable:

$_SESSION['my_var'] = "Hello, world.";


Take care,

Nik
http://www.bigaction.org/

well i gotta question. i have php installed on my local computer and on the internet web server (with mysql and apache). the thing is that when i work on my computer, using $HTTP_SESSION_VARS array instead of calling session_register() works just fine.. but when i upload these files to a web server, things go wrong... session variables exist within one page but when they are being sent to another page, it is lost (isset($HTTP_SESSION_VARS[]) says it is not there)... then i have to add some lines to code where i use session_regiser() to create session variables... why is it so?

the genuine genius

Well, this doesn't make sense:

  isset($HTTP_SESSION_VARS[])

Using the empty brackets appends to the HTTP_SESSION_VARS array, so you're asking if a brand new array item exists.

Also, you should be using $_SESSION, not $HTTP_SESSION_VARS. All the old $HTTP_xxx_VARS arrays have been deprecated for almost two years!


With that said, the reason your code doesn't work on one server is probably due to PHP's setup, not your code... well, not entirely. If your home machine uses cookies to store the session ID, then sessions will just transparently work. If your deployment server doesn't use cookies, then PHP will need to have the session ID passed in all forms and links within the site.

Look at the values under the "Session" heading in a phpinfo() page.


Take care,

Nik
http://www.bigaction.org/

I am having trouble with sessions. I have coded a shopping cart that uses a session ID to identify each customer's cart. The problem surfaces when the customer attempts to check out. When the customer goes to the HTTPS link to check out, a new session ID is created for them and their cart is no longer referenced. I suspect that it pertains to going from the HTTP connection (http://www.somesite.com/shop/view_cart.php) to the SSL connection (https://secure.somesite.com/shop/check_out.php); either that, or it has to do with the different IP for the SSL connection. How can I ensure that the session ID is preserved? Thanks in advance - Royce

It sounds to me that it is in fact creating a new SID when you transition from the non-secure connection to the secure connection. Its treating that like a whole new HTTP request and therefore won't associate the session id for the new request with the old one, its as though there are two completely different sites.

I might suggest a couple of alternatives:
Before the transition to the secure server create a verification page with all of the cart items, then set up in the background a form with hidden fields which will post to the secure connection whereas the session variables may be re-created.

Which *scratching my head* sounds like the easiest and laziest solution.

Another possible solution is make sure that the entire order is created and used on the SSL connection.

Example:
And lastly, at least as far as my contribution goes, is you could set-up a custom session handler... which would probably take the most effort out of the three. I'm not really sure though because I've never gone to the bother of creating custom session handlers.

See the manual for more information on how to do that:
http://www.php.net/manual/en/ref.session.php

: )
Rich

:::::::::::::::::::::::::::::::::
Smiling Souls
http://www.smilingsouls.net
:::::::::::::::::::::::::::::::::

This .ini value may also be of interest, on a shared virtual server this is likely to be the cause of your ills.

Quoted from the PHP manual:
session.referer_check
session.referer_check contains the substring you want to check each HTTP Referer for. If the Referer was sent by the client and the substring was not found, the embedded session id will be marked as invalid. Defaults to the empty string.

Maybe not wise to disengage that, I'm not sure of the security ramifications that may cause.

You could experiment with setting this value to something which is consistent between the secure and non-secure URLS, I believe that php.ini values can be set either at runtime with ini_set(), or within .htaccess files. The latter I have no idea of how to set up.

http://www.php.net/manual/en/function.ini-set.php

That's at least some clue to your problem and hopefully is enough to point you in the right direction!

: )
Rich


:::::::::::::::::::::::::::::::::
Smiling Souls
http://www.smilingsouls.net
:::::::::::::::::::::::::::::::::

The problem is due to the way sessions work. You can persist data on a server for a single connection. When you change servers, or even "virtual" servers (i.e. www.something.com to secure.something.com), PHP creates a new session for the new server you're connecting to. You even said that you're there's a different IP for the secure server, which leads me to believe that they're two different machines.

By default, PHP stores a user's session data in files. If you have two different servers, session data stored on server, the other server is totally unaware of what those temporary session files are.

If you're trying to persist a single user session across multiple servers, I suggest writing your own custom session handlers and having a more specific (or general, as the case may be) method of selecting how a new session is started.

If both servers use the same database back-end, you should write custom session handlers so all your servers pull session data from the same source. You'll have to be careful how you generate session IDs, though. You can't count on an IP address because anyone behind a NAT firewall will share the same session for your site.

If I'm off the mark, or you're still confused, let us know and we'll see what we can't figure out.

For now, I'm friggin tired. Nighty night! =)



Take care,

Nik
http://www.bigaction.org/

Hi Royce,

No problem at all, my door is always open. Did you have any luck experimenting with the .ini directive, session.referer_check?

When you experimented with hidden fields how did you go about it? Post data should show up regardless of the site, at least one would think.

#test.php

<html>
<head>
    <title>Test post data</title>
</head>
<body>
<?php

    if (isset($_POST["test1"])) echo $_POST["test1"]."<br /><br />";

?>
<form method="post" action="http://www.smilingsouls.net/test.php">
<input type="text" name="test1" value="" />
<input type="submit" name="do_action" value="Post" />
</form>
</body>
</html>

I just did this little test here to prove my theory about the post method. Granted, different ISP's may or may not work identically -- yours may have stricter security settings in place.

I created the script above and saved one copy to my local server and uploaded another to my remote ISP. The test script was executed on my local development machine, and its contents echoed at the remote host. It worked. I also changed the action to my secure server, https://www.smilingsouls.net and it also worked.

Try this test out on your machine and see if this works, changing the action to your SSL url. If it does then you can design a solution to dump your session data into hidden fields and then redirect to the secure server via the post method, whereas you would be able to reinitiate your session. The session ID is going to be changed no matter what with this approach. Reason being is PHP sees this as two different sites requesting session initiation and thus handles them separately.

According to the PHP manual the directive, session.referer_check, may be set at run time with ini_set(). Probably would need to be set before calling on session_start(). This directive is going to check the $_SERVER["HTTP_REFERER"] variable if it finds the specified substring in that refering site's url then it will allow the session to persist between different sites hosted on the same server.

Here is a bit of code to test the theory...

<?php

# See if this is a secure request
if (stristr($_SERVER["SERVER_URL"]), "https://")
{

    # $non_secure will be the refering substring to check for
    # plug in the base url of the non secure site
    # or actually just the domain name and suffix

    $non_secure = (string) "nonsecure.site";

    if (!ini_set("session.referer_check", $non_secure))
    {

        echo "Unable to alter ini value.<br />";

        # If you are unable to alter the ini value, your ISP's security may be
        # set too tight. Check with tech support at this point.

    }

} else {

    # if you want to be able to transfer session back to the original site
    # do so here

}

# Now start the session
session_start();

?>

http://www.php.net/manual/en/ref.session.php
http://www.php.net/ini_set

Let me know how that goes.

: )
Rich


:::::::::::::::::::::::::::::::::
Smiling Souls
http://www.smilingsouls.net
:::::::::::::::::::::::::::::::::