problem accessing session variables across pages

[ndsoumah@gmail.com]

hello guys

I'm trying to get access to variables I put in a session variable from
another page and it fails...

here's the exact situation

main file

page1.php
session_start() ; // I create the new session here.

[Oli Filth]

Re: problem accessing session variables across pages

ndsoumah@gmail. com said the following on 25/06/2005 23:01:[color=blue]
> hello guys
>
> I'm trying to get access to variables I put in a session variable from
> another page and it fails...
>
> here's the exact situation
>
> main file
>
> page1.php
> session_start() ; // I create the new session here.
> .
> .
> .
> $_session["f"]= $somevariable1;
> $_session["t"]= $somevariable2;
> .
> .[/color]

$_SESSION


--
Oli

[ndsoumah@gmail.com]

Re: problem accessing session variables across pages

Actually it's in uppercase in my code if that's what you meant.

[Google Mike]

Re: problem accessing session variables across pages

This might be the first time you will hear this, so here goes. My
caution is that session vars, no matter whether it's ASP, PHP, or
whatever, are not a good idea beyond anything but simple apps. They're
useful for simple apps where you only have one web server. But if that
simple app becomes popular, grows up, and is hosted in a web server
"farm", the servers will get confused and not consistently maintained
the state of the session var. In my history of web development,
everything I did that started off as simple was then ultimately
converted into something for hundreds of users via a web farm. That's
just the way it is, I guess. For more powerful apps that use web farms,
you really only have 4 practical choices:

A. Store a "locker" in a centrally used database by all the web
servers. Then, push that "locker key" to the browser in the form of a
cookie or hidden var. In that locker, read/write all kinds of settings
per each user. If hidden var, then you'll have quite a lot of work to
do to pass that hidden browser var (<input type=hidden>) from page to
page. (Cookies work better.) Then, you also have to think about keeping
the locker room clean and not store stuff for users who never decide to
return to your website after a year. Another downside is that this
technique doesn't scale very well because you have to handle all that
I/O and storage space. Imagine if Google did this -- they'd lose
millions of dollars, annually. But for a corporate app of perhaps 1,000
users, this might actually be practical.

B. Next in line as an option, you have the technique of lightly (or not
so lightly) encrypting and heavily compressing the data at the server,
then storing it in a hidden browser var that gets passed from page to
page. This is great for simple persistence from page to page, but not
for persistence that lasts even when the user leaves the browser and
comes back. The reason is because when the user logs out of the web
app, you have to store that persistence somewhere, such as a persistent
cookie or in a database that all the web servers use. If you're using
option B, you're probably one of these web developers who fears that
their users might turn off cookies, so you probably will end up storing
this information in a central database. Then, when the user leaves the
website and comes back, you retrieve it from the central database and
then push it from page to page again via hidden vars. Oh, and another
thing to think about is encryption -- if you do it too heavily, then
you might slow the app too much.

C. MOST POPULAR OPTION. Now, if you're like me, you trust that the
browser has turned on cookies because otherwise half the web would not
be functional for them. Cookies are a good thing, in my book. So, for
this technique, you maintain persistent and session state in encrypted,
compressed cookies that are read/written to from page to page. This is
how I do all my apps.

D. Now, if you're a huge company like Amazon, and you want to ensure
that if someone erases their cookies, they will always come back to a
customized site that caters to their needs once they login, then you'll
need to use a centralized database that all the web servers in the farm
use, but then use persistent and session cookie vars (encrypted and
compressed, of course) as the user goes from page to page. If the user
has the persistent cookie, then you may not need to retrieve from the
database, thereby lowering your I/O requirements.

In my book, here's how this breaks out:

- If you're a newbie, then live in the world of session vars.
- If you're either a novice or a pro, then live in the world of option
C with cookies. Most of you will live here.
- If you're a grand funk dojo master, then you're probably smart and
wealthy enough to implement option D.
- I'm not a fan of option B. This is how .NET works and, frankly, I'm
not impressed.
- Option A is for .NET fans too, but for those who have implemented a
central database for their web farm.

[ndsoumah@gmail.com]

Re: problem accessing session variables across pages

Hello Mike

thanks for your very detailled and informative reply. Unfortunatly
most of the subjets you discussed are way too advanced for me! This is
my fist php application ever and it's a school assignment! So I guess
I don't even qualify as a newbie! Anyhow I know -from your post- what
lies ahead if I decide to pursuit web programming....


Thanks a lot.

[R. Rajesh Jeba Anbiah]

Re: problem accessing session variables across pages

Google Mike wrote:
<snip>[color=blue]
> A. Store a "locker" in a centrally used database by all the web
> servers. Then, push that "locker key" to the browser in the form of a
> cookie or hidden var. In that locker, read/write all kinds of settings
> per each user. If hidden var, then you'll have quite a lot of work to
> do to pass that hidden browser var (<input type=hidden>) from page to
> page. (Cookies work better.) Then, you also have to think about keeping
> the locker room clean and not store stuff for users who never decide to
> return to your website after a year. Another downside is that this
> technique doesn't scale very well because you have to handle all that
> I/O and storage space. Imagine if Google did this -- they'd lose
> millions of dollars, annually. But for a corporate app of perhaps 1,000
> users, this might actually be practical.[/color]
<snip>

The idea that cookies or compressed cookies are the cheap way for
the heavy traffic sites is really a good one. But, nowadays, as far as
I understand, even such heavy traffic sites (eg, Google, Amazon, Yahoo)
start using session with DB/files to remember user details.

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com

[Jerry Stuckle]

Re: problem accessing session variables across pages

ndsoumah@gmail. com wrote:[color=blue]
> Hello Mike
>
> thanks for your very detailled and informative reply. Unfortunatly
> most of the subjets you discussed are way too advanced for me! This is
> my fist php application ever and it's a school assignment! So I guess
> I don't even qualify as a newbie! Anyhow I know -from your post- what
> lies ahead if I decide to pursuit web programming....
>
>
> Thanks a lot.
>[/color]

Don't worry too much about what Mike had to say. I've designed hundreds
of web sites using sessions. The smaller sites I just use the default
handling; larger ones I'll use a database. But they all work fine.

Where you will run into problems is when you go to very large sites
split across multiple servers. You need a different approach there.
The largest I worked on had around 30 "front end" servers with load
balancing; data was pulled from over 100 other systems. But this job
was much more than PHP could handle well. We used Java and EJB
(Enterprise Java Beans) for a seamless connection between the web server
and the data.

You can do it like Mike indicates - but when you get this complicated
there are better technologies than PHP.

--
=============== ===
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attgl obal.net
=============== ===

[Kees Nuyt]

Re: problem accessing session variables across pages

On 25 Jun 2005 17:02:24 -0700, "Google Mike"
<googlemike@hot pop.com> wrote:
[color=blue]
>This might be the first time you will hear this, so here goes. My
>caution is that session vars, no matter whether it's ASP, PHP, or
>whatever, are not a good idea beyond anything but simple apps. They're
>useful for simple apps where you only have one web server. But if that
>simple app becomes popular, grows up, and is hosted in a web server
>"farm", the servers will get confused and not consistently maintained
>the state of the session var. In my history of web development,
>everything I did that started off as simple was then ultimately
>converted into something for hundreds of users via a web farm. That's
>just the way it is, I guess. For more powerful apps that use web farms,
>you really only have 4 practical choices:
>
>
>A.
>B.
>C.
>D.
>[/color]

I think you should add :

E. Use custom session handlers to store session variables in a
central database. Just needs a little bit of code. It is very
easy to replace file based sessions in an existing application
by database based sessions.
Which IMHO makes sessions not such a bad idea at all.

Example code:

<?php
/*
------------------------------------------------------------------------
* session_mysql.p hp
*
------------------------------------------------------------------------
* PHP4 MySQL Session Handler
* Version 1.00
* by Ying Zhang (ying@zippydesi gn.com)
* Last Modified: May 21 2000
* Slightly edited by Kees Nuyt, 2003, 2004
*/

$SESS_DBHOST = "localhost" ; // database server hostname for
sessions
$SESS_DBUSER = "someuid"; // database user
$SESS_DBPASS = "somepsw"; // database password
$SESS_DBNAME = "somedbnm"; // database name
$SESS_DBHNDL = ""; // database handle
$SESS_LIFE = get_cfg_var("se ssion.gc_maxlif etime");

function sess_open($save _path, $session_name){
global $SESS_DBHOST, $SESS_DBNAME, $SESS_DBUSER,
$SESS_DBPASS, $SESS_DBHNDL;
$SESS_DBHNDL = mysql_connect($ SESS_DBHOST, $SESS_DBUSER,
$SESS_DBPASS);
if (!$SESS_DBHNDL) {
echo "<li>Can't connect to $SESS_DBHOST as $SESS_DBUSER";
echo "<li>MySQL Error: ", mysql_error();
return false;
}
if (!mysql_select_ db($SESS_DBNAME , $SESS_DBHNDL)) {
echo "<li>Unable to select database $SESS_DBNAME";
return false;
}
return true;
}
function sess_close(){
global $SESS_DBHNDL;
if ($SESS_DBHNDL != ""){
mysql_close($SE SS_DBHNDL);
}
return true;
}
function sess_read($key) {
global $SESS_DBHNDL, $SESS_LIFE;
$qry = "SELECT `value` FROM `session` WHERE `sesskey` =
'$key' AND `expiry` > UNIX_TIMESTAMP( )";
$qid = mysql_query($qr y, $SESS_DBHNDL) or die("error on
sess_read");
if (list($value) = mysql_fetch_row ($qid)){
return $value;
} else {
return (string)"";
}
}
function sess_write($key , $val){
global $SESS_DBHNDL, $SESS_LIFE;
$expiry = time() + $SESS_LIFE;
$value = addslashes($val );
mysql_query('BE GIN', $SESS_DBHNDL);
$qry = "INSERT INTO session VALUES ('$key', $expiry,
'$value')";
$qid = mysql_query($qr y, $SESS_DBHNDL);
if (! $qid){
mysql_query('RO LLBACK', $SESS_DBHNDL);
mysql_query('BE GIN', $SESS_DBHNDL);
$qry = "UPDATE session SET expiry=$expiry, value='$value'
WHERE sesskey='$key'" ;
$qid = mysql_query($qr y, $SESS_DBHNDL);
}
mysql_query('CO MMIT', $SESS_DBHNDL);
return $qid;
}
function sess_destroy($k ey){
global $SESS_DBHNDL;
mysql_query('BE GIN', $SESS_DBHNDL);
$qry = "DELETE FROM session WHERE sesskey = '$key'";
$qid = mysql_query($qr y, $SESS_DBHNDL);
mysql_query('CO MMIT', $SESS_DBHNDL);
return $qid;
}
function sess_gc($maxlif etime){
global $SESS_DBHNDL;
mysql_query('BE GIN', $SESS_DBHNDL);
$qry = "DELETE FROM session WHERE expiry < " . time();
$qid = mysql_query($qr y, $SESS_DBHNDL);
$naff = mysql_affected_ rows($SESS_DBHN DL);
mysql_query('CO MMIT', $SESS_DBHNDL);
return $naff;
}

session_set_sav e_handler(
"sess_open" ,
"sess_close ",
"sess_read" ,
"sess_write ",
"sess_destr oy",
"sess_gc");
session_start() ;
?>

--
) Kees Nuyt
(
c[_]

[Google Mike]

Re: problem accessing session variables across pages

<snip>
Unfortunatly most of the subjets you discussed are way too advanced for
me! This is my fist php application ever and it's a school assignment!
So I guess
I don't even qualify as a newbie! Anyhow I know -from your post- what
lies ahead if I decide to pursuit web programming....
-ndsoumah@gmail. com
</snip>

Oh. I didn't realize I was over-evangelizing. Okay, my suggestion is to
make your teacher happy with session vars, but when you get out in the
real world, stick with cookies and, early on, start getting used to
working with Apache web farms. Look up the PHP cookie API, as well as
how to compress and encrypt text in fast but significantly effective
ways, even if you have to use something from a third-party vendor to
get the kind of speed you need. I stick with cookies because they work
just as well for me as session vars, and I don't have to switch gears
with a different API -- using session vars for smaller apps makes no
sense to me. I use cookies now for medium, massive, and small projects.
One consistent API.