473,396 Members | 1,671 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,396 software developers and data experts.

problem accessing session variables across pages

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.
Jul 17 '05 #1
8 3950
nd******@gmail.com said the following on 25/06/2005 23:01:
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;
.
.


$_SESSION
--
Oli
Jul 17 '05 #2
Actually it's in uppercase in my code if that's what you meant.

Jul 17 '05 #3
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.

Jul 17 '05 #4
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.

Jul 17 '05 #5
Google Mike wrote:
<snip>
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.

<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

Jul 17 '05 #6
nd******@gmail.com wrote:
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.


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.
js*******@attglobal.net
==================
Jul 17 '05 #7
On 25 Jun 2005 17:02:24 -0700, "Google Mike"
<go********@hotpop.com> wrote:
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.


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.php
*
------------------------------------------------------------------------
* PHP4 MySQL Session Handler
* Version 1.00
* by Ying Zhang (yi**@zippydesign.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("session.gc_maxlifetime");

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($SESS_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($qry, $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('BEGIN', $SESS_DBHNDL);
$qry = "INSERT INTO session VALUES ('$key', $expiry,
'$value')";
$qid = mysql_query($qry, $SESS_DBHNDL);
if (! $qid){
mysql_query('ROLLBACK', $SESS_DBHNDL);
mysql_query('BEGIN', $SESS_DBHNDL);
$qry = "UPDATE session SET expiry=$expiry, value='$value'
WHERE sesskey='$key'";
$qid = mysql_query($qry, $SESS_DBHNDL);
}
mysql_query('COMMIT', $SESS_DBHNDL);
return $qid;
}
function sess_destroy($key){
global $SESS_DBHNDL;
mysql_query('BEGIN', $SESS_DBHNDL);
$qry = "DELETE FROM session WHERE sesskey = '$key'";
$qid = mysql_query($qry, $SESS_DBHNDL);
mysql_query('COMMIT', $SESS_DBHNDL);
return $qid;
}
function sess_gc($maxlifetime){
global $SESS_DBHNDL;
mysql_query('BEGIN', $SESS_DBHNDL);
$qry = "DELETE FROM session WHERE expiry < " . time();
$qid = mysql_query($qry, $SESS_DBHNDL);
$naff = mysql_affected_rows($SESS_DBHNDL);
mysql_query('COMMIT', $SESS_DBHNDL);
return $naff;
}

session_set_save_handler(
"sess_open",
"sess_close",
"sess_read",
"sess_write",
"sess_destroy",
"sess_gc");
session_start();
?>

--
) Kees Nuyt
(
c[_]
Jul 17 '05 #8
<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....
-n*******@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.

Jul 17 '05 #9

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
by: Kent Ogletree | last post by:
I have a solution the is composed of 2 projects. The first is the main web application itself and is written in VB.NET. The second is a web service written in C#. The main application launches a...
22
by: K. A. | last post by:
I have two servers at work, 'A' for testing and development, and server 'B' for production. On server A, I wrote a PHP test code to login users then direct them to a personalized page. This is...
5
by: gom | last post by:
I am an amatuer asp.net programmer so I hope this question isn't to dumb. I am having difficulty with my understanding of session state. I have an application that stores some values in the...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
0
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.