Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > PHP/MySQL > Pro PHP
Password Reminder
Register
Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
Pro PHP Advanced PHP coding discussions. Beginning-level questions will be redirected to the Beginning PHP forum.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Pro PHP section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developersí questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Reply
 
Thread Tools Display Modes
  #1 (permalink)  
Old July 21st, 2003, 02:42 PM
Friend of Wrox
Points: 2,570, Level: 21
Points: 2,570, Level: 21 Points: 2,570, Level: 21 Points: 2,570, Level: 21
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: San Diego, CA, USA
Posts: 836
Thanks: 0
Thanked 0 Times in 0 Posts
Default Why session_register() is bad.

Quote:
quote:Originally posted by quesadilla5 at http://p2p.wrox.com/topic.asp?TOPIC_ID=1881

BTW: On an non-related topic I happened to run across your register_globals FAQ... very helpful... answered alot of questions. I had always wondered why there were security issues with it... now I know : ). Not to get off topic, but why are there issues with the session_register() function? (I noticed that you didn't care much for it!) I have used this to register session variables, but I access them through the $_SESSION superglobal... is that still secure?
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
Reply With Quote
  #2 (permalink)  
Old July 28th, 2003, 09:21 AM
gkb gkb is offline
Registered User
 
Join Date: Jul 2003
Location: yong peng, johor, Malaysia.
Posts: 2
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via ICQ to gkb
Default

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

Reply With Quote
  #3 (permalink)  
Old July 31st, 2003, 02:02 PM
Friend of Wrox
Points: 2,570, Level: 21
Points: 2,570, Level: 21 Points: 2,570, Level: 21 Points: 2,570, Level: 21
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: San Diego, CA, USA
Posts: 836
Thanks: 0
Thanked 0 Times in 0 Posts
Default

$_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/
Reply With Quote
  #4 (permalink)  
Old August 7th, 2003, 06:46 PM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 101
Thanks: 0
Thanked 1 Time in 1 Post
Send a message via AIM to Moharo
Default

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
Reply With Quote
  #5 (permalink)  
Old August 18th, 2003, 11:54 AM
Friend of Wrox
Points: 2,570, Level: 21
Points: 2,570, Level: 21 Points: 2,570, Level: 21 Points: 2,570, Level: 21
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: San Diego, CA, USA
Posts: 836
Thanks: 0
Thanked 0 Times in 0 Posts
Default

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/
Reply With Quote
  #6 (permalink)  
Old September 13th, 2003, 01:28 AM
Registered User
 
Join Date: Sep 2003
Location: New Braunfels, TX, USA.
Posts: 3
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via Yahoo to roycehart
Default

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

Reply With Quote
  #7 (permalink)  
Old September 13th, 2003, 02:01 AM
richard.york's Avatar
Wrox Author
Points: 5,506, Level: 31
Points: 5,506, Level: 31 Points: 5,506, Level: 31 Points: 5,506, Level: 31
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Camby, IN, USA.
Posts: 1,706
Thanks: 0
Thanked 6 Times in 6 Posts
Default

Quote:
quote:
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
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:
Code:
if (!stristr($_SERVER["SERVER_URL"], "https://"))
{

    header("Location: https://my.secure.site");

}
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
:::::::::::::::::::::::::::::::::
Reply With Quote
  #8 (permalink)  
Old September 13th, 2003, 02:14 AM
richard.york's Avatar
Wrox Author
Points: 5,506, Level: 31
Points: 5,506, Level: 31 Points: 5,506, Level: 31 Points: 5,506, Level: 31
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Camby, IN, USA.
Posts: 1,706
Thanks: 0
Thanked 6 Times in 6 Posts
Default

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
:::::::::::::::::::::::::::::::::
Reply With Quote
  #9 (permalink)  
Old September 14th, 2003, 02:02 AM
Friend of Wrox
Points: 2,570, Level: 21
Points: 2,570, Level: 21 Points: 2,570, Level: 21 Points: 2,570, Level: 21
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: San Diego, CA, USA
Posts: 836
Thanks: 0
Thanked 0 Times in 0 Posts
Default

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/
Reply With Quote
  #10 (permalink)  
Old September 14th, 2003, 02:12 AM
richard.york's Avatar
Wrox Author
Points: 5,506, Level: 31
Points: 5,506, Level: 31 Points: 5,506, Level: 31 Points: 5,506, Level: 31
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Jun 2003
Location: Camby, IN, USA.
Posts: 1,706
Thanks: 0
Thanked 6 Times in 6 Posts
Default

Quote:
quote:
Good Evening Rich,

First of all, thanks for your thoughtful - and speedy! - responses to my
question in the Wrox forum.

The Wrox forum appears to be down tonight, so I took the liberty of checking
out your URL from your sigfile and am sending this email to you directly.
Please let me know if you would rather I had not.

I am still struggling with this cart design. To address your suggestions
quoted below:

1) I don't want to do SSL throughout the site;

2) I tried the hidden field approach to pass the session ID value, and it
did not work; a new session was created anyway, believe it or not;

3) after the nightmares I've had just trying to preserve this single
session, the thought of authoring a custom session handler sounds too
daunting.

I am beginning to believe that I need to rethink my entire design. Is there
a better way? I am completely open to suggestions.

Thanks again,

Royce Hart
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
:::::::::::::::::::::::::::::::::
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Bad Connection String paulcbyrum Access VBA 3 May 9th, 2008 09:19 PM
Very slow and almost no replies...BAD..!!! zach007 Forum and Wrox.com Feedback 4 December 23rd, 2006 05:48 PM
Bad SQL in Try It Out in chapter 3 punch BOOK: Beginning SQL 1 August 18th, 2006 06:39 PM
Bad Data Error chiefg General .NET 1 March 4th, 2006 02:09 AM



All times are GMT -4. The time now is 05:49 PM.


Powered by vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.