why a session-based program behaves different on different computers

[davidkoree@gmail.com]

I mean not about cookie.
Does it have something to do with operating system or browser plugin?
I appreciate any help.

[=?utf-8?B?6ZOB5omY?=]

Re: why a session-based program behaves different on different computers

On Apr 18, 3:36 pm, davidko...@gmai l.com wrote:

I mean not about cookie.
Does it have something to do with operating system or browser plugin?
I appreciate any help.

php.ini is different? or any other different? check the php.ini and
apache setting.

[davidkoree@gmail.com]

Re: why a session-based program behaves different on different computers

php.ini is different? or any other different? check the php.ini and

apache setting.

This session-based program is running on a single server, so the
php.ini is unique. Strangely it performs differently on different
(client) computers.

[Steve]

Re: why a session-based program behaves different on different computers


<davidkoree@gma il.comwrote in message
news:1176881792 .508187.177910@ l77g2000hsb.goo glegroups.com.. .
|I mean not about cookie.
| Does it have something to do with operating system or browser plugin?
| I appreciate any help.

if the browser doesn't have cookies enabled, then php will attempt to
rewrite your html output to include a PHP_SESSIONID variable. you can
configure the variable name used to indicate something other than
PHP_SESSION_ID. you can also tell php to *always* use html rewrites and
never use cookies, or simply leave it default - cookies, else html rewrite.

there's more to it than that but it gets complicated...w hich requires you to
state the behavior and the client's configuration. aol users have *very*
common problems maintaining sessions in php. other factors weigh in. again,
just need more info from you.

[davidkoree@gmail.com]

Re: why a session-based program behaves different on different computers

Thank you steve.

Generally the program has 5 steps, and the first 4 steps need user to
input some data, and the last one outputs the result. Every user must
starts with the 1st step, if not, the program will give user a message
like 'You should starts with the 1st step' or 'You could continue on
the n step'.

I use session to keeping user's inputs and status of steps. When user
finish he/she can go back to edit his/her inputs, but some computers
show that when user go back to check, the program give a random
message like 'You could continue on the n step'. It should not be
shown because the whole status have been set to 'done' in session
variable. like:

Array ( [step1_1] =done [step1_2] =done [step1_3] =done [step2]
=done [step3] =done [step4] =done )

The core codes of the program:

<?php
class F5S {
//current working page
public $_filename;
//status
public $_status = array();
//data
public $_data = array();
//dictionaries
public $_dict_page2ste p = array("b_lcwb_1 b.php"=>"step1_ ",
"b_lcwb_1c.php" =>"step1_", "b_lcwb_2.php"= >"step1_",
"b_lcwb_3.php"= >"step2_", "b_lcwb_4.php"= >"step3_",
"b_lcwb_5.php"= >"step4_");
public $_dict_page2sta tus = array("b_lcwb_1 b.php"=>"step1_ 1",
"b_lcwb_1c.php" =>"step1_2", "b_lcwb_2.php"= >"step1_3",
"b_lcwb_3.php"= >"step2", "b_lcwb_4.php"= >"step3",
"b_lcwb_5.php"= >"step4");
public $_dict_status2n extstep = array("step1_1" =>"Step 1,
2 ...","step1_2"= >"Step 1, 3 ...","step1_3"= >"Step
Two ...","step2"=>" Step 3 ...","step3"=>" Step 4 ...","step4"=>" Step
5 ...");

/**
* set current working page
*
* @param string $path
* @return string
*/
function setFileName($pa th) {
$pathinfo = pathinfo($path) ;
$this->_filename = $pathinfo["basename"];
}

/**
* move to the next step that needs to be finished
*
* @param string $nextstep
* @param string $filename
*/
function removeToStep($n extstep, $pagename) {
$format = "<script language='javas cript' type='text/
javascript'>ale rt('You could continue on the
%s.');location. href='%s';</script>";
echo sprintf($format , $nextstep, $pagename);
}

/**
* route steps workflow
*
*/
function routeWorkflow() {
if (count($this->_status) 0) {
$dict_status2pa ge = array_flip($thi s->_dict_page2sta tus);
$nextstep = $this->_dict_status2n extstep[array_pop(array _flip($this-

>_status))];

$pagename = $dict_status2pa ge[array_pop(array _flip($this-

>_status))];

$this->removeToStep($ nextstep, $pagename);
} else {
echo "<script language='javas cript' type='text/
javascript'>ale rt('You should starts with the 1st
step.');locatio n.href='b_lcwb_ 1a.php';</script>";
}
}

/**
* check steps workflow
*
* @param string $path
* @return boolean
*/
function checkWorkflow() {
$filename = $this->_filename;
if (in_array($this->_dict_page2sta tus[$filename], array_keys($thi s-

>_status))) {

return true;
} else {
return false;
}
}

/**
* collect user inputs
*
* @param filename $path
* @param array $postvar
*/
function collectData($po stvar) {
$filename = $this->_filename;
foreach (array_keys($po stvar) as $name) {
$this->_data[$this->_dict_page2ste p[$filename].$name] =
$postvar[$name];
}
}

/**
* update status of steps
*
* @param string $path
*/
function updateStatus() {
$filename = $this->_filename;
$this->_status[$this->_dict_page2sta tus[$filename]] = "done";
}
}
?>

And step page:

<?php
require_once("F 5S.php");
session_start() ;
print_r($_SESSI ON["f5s"]->_status);
if (isset($_SESSIO N["f5s"])) {
$_SESSION["f5s"]->setFileName(__ FILE__);
if (count($_POST) 0) {
$_SESSION["f5s"]->collectData($_ POST);
$_SESSION["f5s"]->updateStatus() ;
$_SESSION["f5s_data"] = $_SESSION["f5s"]->_data;
$_SESSION["f5s_status "] = $_SESSION["f5s"]->_status;
} elseif ($_SESSION["f5s"]->checkWorkflow( )) {
$_SESSION["f5s_data"] = $_SESSION["f5s"]->_data;
$_SESSION["f5s_status "] = $_SESSION["f5s"]->_status;
} else {
$_SESSION["f5s"]->routeWorkflow( );
}
} else {
$_SESSION["f5s"] = new F5S();
$_SESSION["f5s"]->setFileName(__ FILE__);
$_SESSION["f5s"]->routeWorkflow( );
}
?>

Strangely some computers run the program correctly (with IE6/FF2/
Maxthon) but others don't. I need help, really~

[Steve]

Re: why a session-based program behaves different on different computers


<davidkoree@gma il.comwrote in message
news:1176966448 .437636.163900@ n59g2000hsh.goo glegroups.com.. .
| Thank you steve.
|
| Generally the program has 5 steps, and the first 4 steps need user to
| input some data, and the last one outputs the result. Every user must
| starts with the 1st step, if not, the program will give user a message
| like 'You should starts with the 1st step' or 'You could continue on
| the n step'.

i gotcha. i've done this kind of thing before. what i'd recommend is NOT
using cookies/session vars to keep track of the steps. i would store your
inputs in a db. i'd use php to validate the data supplied to figure out
which step is next. that allows you to intermingle each step in a logical
order so that you can repeat steps if needed.

here's what i mean. i programmed a manufacturing line application where each
work area supplied build up information such as parts, their manufacturers,
etc. now some of those work stations (let's say station 3) had work routed
from station 2 (let's say), they did their job, sent it on to stations 4 and
5 at which time station 5 sent it back for completion. hard to imagine a
good, real-world example? pretend that station 3 is an inspection area. the
plant also had stations with conditional routing where work/parts rarely
followed the same station progression during build up. anyway...

i'm not sure if you're doing anything more complex that just a 'wizard' type
of data entry screen or what. either way, that's what i'd recommend. store
your inputs in a db, either use procedural php code or build a class to
handle the routing based on the rules of what you're doing.

btw, the workers at any station would pull up the part from a barcode and if
the data collected showed they could work it, data entry was allowed for
that part at that station. but i digress.

can you be more specific as to what you *really* wanna get done?

[davidkoree@gmail.com]

Re: why a session-based program behaves different on different computers

Thank you very much Steve.

I will consider your recommendations seriously, that must be more
stable than using cookie/session methods.

Yesterday I checked my program and I found that there're two problems
which made things bad.

Let me show them:

<?php
require_once("F 5S.php");
session_start() ;

print_r($_SESSI ON["f5s"]->_status); // -- bad one --
/* This is bad one.
* For example, if user has finished 3 steps, the $_SESSION["f5s"]-

>_status should be:

* { [step_1] =done, [step_2] =done, [step_3] =done }
* But on some client computers the $_SESSION["f5s"]->_status may look
like this:
* { [step_1] =done, [step_3] =done }
* or this:
* { }
* If we refresh the browser on or more times, the $_SESSION["f5s"]-

>_status would be complete (or uncomplete).

*/

if (isset($_SESSIO N["f5s"])) { // -- bad two --
/* This IF is bad two, it doesn't return TRUE on some client
computers.
* But if we refresh the browser one or more times, the
$_SESSION["f5s"] could be ok (or not ok).
* Just like bad one.
*/

$_SESSION["f5s"]->setFileName(__ FILE__);

if (count($_POST) 0) {
$_SESSION["f5s"]->collectData($_ POST);
$_SESSION["f5s"]->updateStatus() ;
$_SESSION["f5s_data"] = $_SESSION["f5s"]->_data;
$_SESSION["f5s_status "] = $_SESSION["f5s"]->_status;
} elseif ($_SESSION["f5s"]->checkWorkflow( )) {
$_SESSION["f5s_data"] = $_SESSION["f5s"]->_data;
$_SESSION["f5s_status "] = $_SESSION["f5s"]->_status;
} else {
$_SESSION["f5s"]->routeWorkflow( );
}

} else {

$_SESSION["f5s"] = new F5S();
$_SESSION["f5s"]->setFileName(__ FILE__);
$_SESSION["f5s"]->routeWorkflow( );

}
?>

The the server environment is PHP 5.1.4/Linux/Apache 2.0.

I just searched bugs on php.net, and my issue seems like 'sessions are
dropped randomly'.
See more details please go to http://bugs.php.net/bug.php?id=37382

And a bogus bug is inspiring me.
See more details please go to http://bugs.php.net/bug.php?id=37444

[Steve]

Re: why a session-based program behaves different on different computers


<davidkoree@gma il.comwrote in message
news:1177046111 .599072.93440@n 76g2000hsh.goog legroups.com...
| Thank you very much Steve.
|
| I will consider your recommendations seriously, that must be more
| stable than using cookie/session methods.
|
| Yesterday I checked my program and I found that there're two problems
| which made things bad.
|
| Let me show them:

i'd really think about setting a variable instead of calling methods
directly off the $_SESSION stack. that gives php more work to do than is
needed and is harder to type and read.

if you base the steps on data retrieved and what steps are required and met
by that data, it won't matter how many times you refresh the browser. you
will always show the correct action to take next.

i'm glad you found those things. let me know if you get stuck.

cheers.

[davidkoree@gmail.com]

Re: why a session-based program behaves different on different computers

Thank you Steve. :)

Sorry my English is not quite well~

Now could you tell me if it is possible that this issue have something
to do with operating system or browser plugin?

[Jerry Stuckle]

Re: why a session-based program behaves different on different computers

davidkoree@gmai l.com wrote:

Thank you very much Steve.
>
I will consider your recommendations seriously, that must be more
stable than using cookie/session methods.
>
Yesterday I checked my program and I found that there're two problems
which made things bad.
>
Let me show them:
>
<?php
require_once("F 5S.php");
session_start() ;
>
print_r($_SESSI ON["f5s"]->_status); // -- bad one --
/* This is bad one.
* For example, if user has finished 3 steps, the $_SESSION["f5s"]-

>_status should be:

* { [step_1] =done, [step_2] =done, [step_3] =done }
* But on some client computers the $_SESSION["f5s"]->_status may look
like this:
* { [step_1] =done, [step_3] =done }
* or this:
* { }
* If we refresh the browser on or more times, the $_SESSION["f5s"]-

>_status would be complete (or uncomplete).

*/
>
if (isset($_SESSIO N["f5s"])) { // -- bad two --
/* This IF is bad two, it doesn't return TRUE on some client
computers.
* But if we refresh the browser one or more times, the
$_SESSION["f5s"] could be ok (or not ok).
* Just like bad one.
*/
>
$_SESSION["f5s"]->setFileName(__ FILE__);
>
if (count($_POST) 0) {
$_SESSION["f5s"]->collectData($_ POST);
$_SESSION["f5s"]->updateStatus() ;
$_SESSION["f5s_data"] = $_SESSION["f5s"]->_data;
$_SESSION["f5s_status "] = $_SESSION["f5s"]->_status;
} elseif ($_SESSION["f5s"]->checkWorkflow( )) {
$_SESSION["f5s_data"] = $_SESSION["f5s"]->_data;
$_SESSION["f5s_status "] = $_SESSION["f5s"]->_status;
} else {
$_SESSION["f5s"]->routeWorkflow( );
}
>
} else {
>
$_SESSION["f5s"] = new F5S();
$_SESSION["f5s"]->setFileName(__ FILE__);
$_SESSION["f5s"]->routeWorkflow( );
>
}
?>
>
The the server environment is PHP 5.1.4/Linux/Apache 2.0.
>
I just searched bugs on php.net, and my issue seems like 'sessions are
dropped randomly'.
See more details please go to http://bugs.php.net/bug.php?id=37382
>
And a bogus bug is inspiring me.
See more details please go to http://bugs.php.net/bug.php?id=37444
>
>

Actually, David, going to a database won't work any better. You still
need to keep the key to the row in the session, and if you lose the
session you lose the database info.

If you force them to sign in, you could key the data to their user id;
then at least it would be saved when the session fails. But then
they'll have to log in.

The bogus bug you're referencing doesn't seem to apply because I don't
see anywhere you're doing $_SESSION=array (...) (unless it's someplace
else in the code).

One think I'm wondering - when you say "When user finish he/she can go
back to edit his/her inputs,..." do you mean by clicking on a review
button (or similar) on your page, or by clicking the "back" button on
their browser?

If the latter, the difference in behavior can be easily explained by
caching issues.


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

[davidkoree@gmail.com]

Re: why a session-based program behaves different on different computers

Thank you Jerry.

I'm keeping on the issue. Once I solve it I will come back.

[Steve]

Re: why a session-based program behaves different on different computers

| Actually, David, going to a database won't work any better. You still
| need to keep the key to the row in the session, and if you lose the
| session you lose the database info.

you'd only lose db info if the record is deleted or an update was made but
not committed. the chances of losing a session are present, however losing
data because of that are nil on the delete side and negligible on the update
side.

| If you force them to sign in, you could key the data to their user id;
| then at least it would be saved when the session fails. But then
| they'll have to log in.

and when the user logged in again, since the data is in a db rather than a
session, you could bring them to the last step they completed (whether there
is already some populated data they hadn't completed or if they're at the
beggining of that step).


just a thought.

[Jerry Stuckle]

Re: why a session-based program behaves different on different computers

Steve wrote:

| Actually, David, going to a database won't work any better. You still
| need to keep the key to the row in the session, and if you lose the
| session you lose the database info.
>
you'd only lose db info if the record is deleted or an update was made but
not committed. the chances of losing a session are present, however losing
data because of that are nil on the delete side and negligible on the update
side.
>

No, the data is still in the row. But if you lose the session you lose
the link to the data. It might as well be gone, even if it is committed.

| If you force them to sign in, you could key the data to their user id;
| then at least it would be saved when the session fails. But then
| they'll have to log in.
>
and when the user logged in again, since the data is in a db rather than a
session, you could bring them to the last step they completed (whether there
is already some populated data they hadn't completed or if they're at the
beggining of that step).
>

And you'll have another session id and another key, unless it is keyed
to the userid, as I mentioned above. But he still has to login because
the session disappeared.

And if the op isn't forcing the user to login, there is no way to sure
way to identify the data.

>
just a thought.
>
>

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

[Steve]

Re: why a session-based program behaves different on different computers


"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
news:dtudnXXVaO 9aV7HbnZ2dnUVZ_ uPinZ2d@comcast .com...
| Steve wrote:
| | Actually, David, going to a database won't work any better. You still
| | need to keep the key to the row in the session, and if you lose the
| | session you lose the database info.
| >
| you'd only lose db info if the record is deleted or an update was made
but
| not committed. the chances of losing a session are present, however
losing
| data because of that are nil on the delete side and negligible on the
update
| side.
| >
|
| No, the data is still in the row. But if you lose the session you lose
| the link to the data. It might as well be gone, even if it is committed.

'might as well be' and *is* are not ==.

note that as i've said. the chances of losing data due to deletion is nil.
what you've described is what i also noted. that an update can cause a
partial loss of data but this only involves the data related to the current
step, and is therefore negliable (with a few caveats).

| | If you force them to sign in, you could key the data to their user id;
| | then at least it would be saved when the session fails. But then
| | they'll have to log in.
| >
| and when the user logged in again, since the data is in a db rather than
a
| session, you could bring them to the last step they completed (whether
there
| is already some populated data they hadn't completed or if they're at
the
| beggining of that step).
| >
|
| And you'll have another session id and another key, unless it is keyed
| to the userid, as I mentioned above. But he still has to login because
| the session disappeared.

yes, the re-log in is a bitch. however i don't recall either you or i
addressing this problem. let's stick to the architecture for a moment then.

don't couple specific data to a user. we don't have to here. if you want to
detect the last thing a user was working on, so be it. however nothing says
that has to be that way. you may not even see that as desireable though.

let's say i work at station 4, take lunch but have left a component to be
finish by someone else at station 4. after my lunches i begin working at
station 5. station 5 is where the build up of astronautic rocketry is
performed, while station 4 is where legos are put together to keep all the
workers humorous and sane.

you don't want to tie the user data to a step here. what could be done is
allow a login with a selection of stations from which he can chose to work.
it would then be appropriate to begin the completion of the most current
work. that could be automatic, or if multiple components are built up there,
they could put in a job id, part id, or any other identifier. having THAT
identifier pull from already SAVED data will solve a bunch of problems.

and btw, NONE of these altertatives i just described are available WITHOUT A
DB. the ONLY thing one should ever need to session is the logon information
of the user. anything else is bad architecture.

| And if the op isn't forcing the user to login, there is no way to sure
| way to identify the data.

i think i just described a litany of ways in which your assertion here is
utterly foundless.

[Jerry Stuckle]

Re: why a session-based program behaves different on different computers

Steve wrote:

"Jerry Stuckle" <jstucklex@attg lobal.netwrote in message
news:dtudnXXVaO 9aV7HbnZ2dnUVZ_ uPinZ2d@comcast .com...
| Steve wrote:
| | Actually, David, going to a database won't work any better. You still
| | need to keep the key to the row in the session, and if you lose the
| | session you lose the database info.
| >
| you'd only lose db info if the record is deleted or an update was made
but
| not committed. the chances of losing a session are present, however
losing
| data because of that are nil on the delete side and negligible on the
update
| side.
| >
|
| No, the data is still in the row. But if you lose the session you lose
| the link to the data. It might as well be gone, even if it is committed.
>
'might as well be' and *is* are not ==.
>

The data is lost. It still exists, but there is no way to identify the
correct row.

note that as i've said. the chances of losing data due to deletion is nil.
what you've described is what i also noted. that an update can cause a
partial loss of data but this only involves the data related to the current
step, and is therefore negliable (with a few caveats).
>

No one ever said anything about deletion or update. I was specifically
talking about losing the id to the row which is stored in the session -
and the session is lost. Nothing more, nothing less.

| | If you force them to sign in, you could key the data to their user id;
| | then at least it would be saved when the session fails. But then
| | they'll have to log in.
| >
| and when the user logged in again, since the data is in a db rather than
a
| session, you could bring them to the last step they completed (whether
there
| is already some populated data they hadn't completed or if they're at
the
| beggining of that step).
| >
|
| And you'll have another session id and another key, unless it is keyed
| to the userid, as I mentioned above. But he still has to login because
| the session disappeared.
>
yes, the re-log in is a bitch. however i don't recall either you or i
addressing this problem. let's stick to the architecture for a moment then.
>

It's part of the architecture - and something the op wants to avoid.

don't couple specific data to a user. we don't have to here. if you want to
detect the last thing a user was working on, so be it. however nothing says
that has to be that way. you may not even see that as desireable though.
>
let's say i work at station 4, take lunch but have left a component to be
finish by someone else at station 4. after my lunches i begin working at
station 5. station 5 is where the build up of astronautic rocketry is
performed, while station 4 is where legos are put together to keep all the
workers humorous and sane.
>
you don't want to tie the user data to a step here. what could be done is
allow a login with a selection of stations from which he can chose to work.
it would then be appropriate to begin the completion of the most current
work. that could be automatic, or if multiple components are built up there,
they could put in a job id, part id, or any other identifier. having THAT
identifier pull from already SAVED data will solve a bunch of problems.
>

Let's stick to the architecture for a moment then. No one ever said
anything about changing stations, for instance.

and btw, NONE of these altertatives i just described are available WITHOUT A
DB. the ONLY thing one should ever need to session is the logon information
of the user. anything else is bad architecture.
>

If there even is a session login. That part is not clear.

| And if the op isn't forcing the user to login, there is no way to sure
| way to identify the data.
>
i think i just described a litany of ways in which your assertion here is
utterly foundless.
>
>

You have? I don't see it. All I see is a bunch of rambling about
completely unrelated possibilities.

The fact is, if you lose the key to your row, you can't access that row.

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