I mean not about cookie.
Does it have something to do with operating system or browser plugin?
I appreciate any help.
43  3378 
On Apr 18, 3:36Â*pm, davidko...@gmail.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.
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.
<da********@gmail.comwrote in message
news:11**********************@l77g2000hsb.googlegr oups.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...which 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.
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_page2step = array("b_lcwb_1b.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_page2status = array("b_lcwb_1b.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_status2nextstep = 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($path) {
$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($nextstep, $pagename) {
$format = "<script language='javascript' type='text/
javascript'>alert('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_status2page = array_flip($this->_dict_page2status);
$nextstep = $this->_dict_status2nextstep[array_pop(array_flip($this-
>_status))];
$pagename = $dict_status2page[array_pop(array_flip($this-
>_status))];
$this->removeToStep($nextstep, $pagename);
} else {
echo "<script language='javascript' type='text/
javascript'>alert('You should starts with the 1st
step.');location.href='b_lcwb_1a.php';</script>";
}
}
/**
* check steps workflow
*
* @param string $path
* @return boolean
*/
function checkWorkflow() {
$filename = $this->_filename;
if (in_array($this->_dict_page2status[$filename], array_keys($this-
>_status))) {
return true;
} else {
return false;
}
}
/**
* collect user inputs
*
* @param filename $path
* @param array $postvar
*/
function collectData($postvar) {
$filename = $this->_filename;
foreach (array_keys($postvar) as $name) {
$this->_data[$this->_dict_page2step[$filename].$name] =
$postvar[$name];
}
}
/**
* update status of steps
*
* @param string $path
*/
function updateStatus() {
$filename = $this->_filename;
$this->_status[$this->_dict_page2status[$filename]] = "done";
}
}
?>
And step page:
<?php
require_once("F5S.php");
session_start();
print_r($_SESSION["f5s"]->_status);
if (isset($_SESSION["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~
<da********@gmail.comwrote in message
news:11**********************@n59g2000hsh.googlegr oups.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?
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("F5S.php");
session_start();
print_r($_SESSION["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($_SESSION["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
<da********@gmail.comwrote in message
news:11*********************@n76g2000hsh.googlegro ups.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.
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?
da********@gmail.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("F5S.php");
session_start();
print_r($_SESSION["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($_SESSION["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. js*******@attglobal.net
==================
Thank you Jerry.
I'm keeping on the issue. Once I solve it I will come back.
| 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.
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. js*******@attglobal.net
==================
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:dt******************************@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.
Steve wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:dt******************************@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. js*******@attglobal.net
==================
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:l8******************************@comcast.com. ..
| Steve wrote:
| "Jerry Stuckle" <js*******@attglobal.netwrote in message
| news:dt******************************@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.
data is in the db. a query will return the correct step that is next in the
ladder of steps to get to the top. user logs back in, that step is
displayed. now, pray-tell, HOW IS THE DATA LOST?
| 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.
data is in the db. a query will return the correct step that is next in the
ladder of steps to get to the top. user logs back in, that step is
displayed. now, pray-tell, HOW IS THE DATA LOST?
| | | 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.
then wtf don't you just address how he can solve the session problem instead
of giving BAD architectual advice...like, 'a db won't get you any closer to
solving the problem'. as i've pointed out, it DOES allow for a way to
recover. you just have no idea how to implement a fail-safe.
get over it.
| 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.
in the architecture *i've* described, NO LOGIN NEED BE PRESENT. as i said,
if you simply select what work you'd like to begin, having a DB will allow
you to query DATA for what is left to do for the task. even without a login,
identifying WHERE the user is performing his job (answering questions/giving
input), you'd be able to give them a LIST of incomplete tasks from which
they could pick.
sessions WON'T allow you to do that. a DB will...with great flexibility in
ANY context however you implement your access to a process per user. if you
remember, you said a db essentially does shit for the op's problem. you
clearly see i beg to differ.
| | 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.
then you're mind is wholly inable to imagine the TYPE of general
functionality the op wants AND can't draw from you previous EXPERIENCE to
correlate different solutions that are applicable to the TYPE.
intellect is measure by inference and association. are you saying you truly
see NO similarities between my 'ramblings' and what the op is doing? if not,
i feel for you, bro.
| The fact is, if you lose the key to your row, you can't access that row.
data is in the db. a query will return the correct step that is next in the
ladder of steps to get to the top. user logs back in, that step is
displayed. now, pray-tell, HOW IS THE DATA LOST?
Steve wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:l8******************************@comcast.com. ..
| Steve wrote:
| "Jerry Stuckle" <js*******@attglobal.netwrote in message
| news:dt******************************@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.
data is in the db. a query will return the correct step that is next in the
ladder of steps to get to the top. user logs back in, that step is
displayed. now, pray-tell, HOW IS THE DATA LOST?
WHAT HAPPENS IF THIS DOES NOT REQUIRE A LOGIN????? NOTHING WAS EVER SAID
ABOUT THE USER LOGGING IN!
| 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.
data is in the db. a query will return the correct step that is next in the
ladder of steps to get to the top. user logs back in, that step is
displayed. now, pray-tell, HOW IS THE DATA LOST?
ONLY IF YOU HAVE THE PRIMARY KEY TO THE COLUMN!!! IF THERE IS NO LOGIN,
HOW DO YOU DETERMINE WHICH ROW IT IS?
| | | 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.
then wtf don't you just address how he can solve the session problem instead
of giving BAD architectual advice...like, 'a db won't get you any closer to
solving the problem'. as i've pointed out, it DOES allow for a way to
recover. you just have no idea how to implement a fail-safe.
get over it.
THEN GET OVER IT! THE ARCHITECTURAL ADVICE IS SOLID! AND YOU HAVEN'T
POINTED OUT ANYTHING EXCEPT "IF THE USER LOGS IN...".
And that does solve the problem of the user having to log in.
| 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.
in the architecture *i've* described, NO LOGIN NEED BE PRESENT. as i said,
if you simply select what work you'd like to begin, having a DB will allow
you to query DATA for what is left to do for the task. even without a login,
identifying WHERE the user is performing his job (answering questions/giving
input), you'd be able to give them a LIST of incomplete tasks from which
they could pick.
THEN HOW DO YOU DETERMINE WHICH ROW IS ASSOCIATED WITH THAT USER? HOW
DO YOU KNOW WHICH TASKS ARE COMPLETE AND WHICH ARE INCOMPLETE?
sessions WON'T allow you to do that. a DB will...with great flexibility in
ANY context however you implement your access to a process per user. if you
remember, you said a db essentially does shit for the op's problem. you
clearly see i beg to differ.
SESSIONS KEEP TRACK OF WHICH ROW IN THE DATABASE IS BEING REFERENCED.
| | 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.
then you're mind is wholly inable to imagine the TYPE of general
functionality the op wants AND can't draw from you previous EXPERIENCE to
correlate different solutions that are applicable to the TYPE.
intellect is measure by inference and association. are you saying you truly
see NO similarities between my 'ramblings' and what the op is doing? if not,
i feel for you, bro.
| The fact is, if you lose the key to your row, you can't access that row.
data is in the db. a query will return the correct step that is next in the
ladder of steps to get to the top. user logs back in, that step is
displayed. now, pray-tell, HOW IS THE DATA LOST?
And your mind is completely unable to grasp a simple concept. If the
session is lost and there is no user login, there is no way to reference
the row in the table related to this user.
You have 500 users currently active. Suddenly one of them loses a
session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
USER? THERE IS NOT LOGIN!
And YES I'M YELLING. You don't seem to grasp even a simple concept.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
| WHAT HAPPENS IF THIS DOES NOT REQUIRE A LOGIN????? NOTHING WAS EVER SAID
| ABOUT THE USER LOGGING IN!
imagine if you will/can, that the form carries a tag perhaps identifying
say, an ip address - i know it's a stretch for you. that would certainly be
ONE way to marry an instance of data with a browser. input is stored in a db
with each post/get. when that ip (in this instance) and its data was
analized, we could then still tell where the user left off - or what the
next step would be.
i can come up with several other matching methods. care for more
embarrassment?
| | 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.
| >
| data is in the db. a query will return the correct step that is next in
the
| ladder of steps to get to the top. user logs back in, that step is
| displayed. now, pray-tell, HOW IS THE DATA LOST?
| >
|
| ONLY IF YOU HAVE THE PRIMARY KEY TO THE COLUMN!!! IF THERE IS NO LOGIN,
| HOW DO YOU DETERMINE WHICH ROW IT IS?
yelling is not compensating for your lack of imagination. you keep talking
about rows. you realize that in a stepped operation, you are not talking
about just one row of data. each step is probably its own row. i've pointed
out one way to link a browser instance with data...no reason why it can't be
tied to all the related rows. as each row is validated as 'complete', we
simply provide the next set of prompts for input...ad nausium until the
ladder has been summited.
| | | | 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.
| >
| then wtf don't you just address how he can solve the session problem
instead
| of giving BAD architectual advice...like, 'a db won't get you any closer
to
| solving the problem'. as i've pointed out, it DOES allow for a way to
| recover. you just have no idea how to implement a fail-safe.
| >
| get over it.
| >
|
| THEN GET OVER IT! THE ARCHITECTURAL ADVICE IS SOLID! AND YOU HAVEN'T
| POINTED OUT ANYTHING EXCEPT "IF THE USER LOGS IN...".
yes, MY design is solid. saying db storage leaves you no better off than
just sessioning the user input is LUDICROUS. btw, that was YOUR advice.
and, i've pointed out MANY ways to do all of this. i can pseudo code a whole
example WITHOUT using logins if that's the only way your pea sized brain can
conceptualize...solidified as concrete!
| And that does solve the problem of the user having to log in.
hmmm...'that' would be what? sessioning data from a browser where the op is
KNOWN to have sessions dropped? i don't see how that does anything BUT drop
the data collected for that user. if you validate and save collected
information with each steps posted info, you won't even lose a NEW
record...nor a modified on.
| | 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.
| >
| in the architecture *i've* described, NO LOGIN NEED BE PRESENT. as i
said,
| if you simply select what work you'd like to begin, having a DB will
allow
| you to query DATA for what is left to do for the task. even without a
login,
| identifying WHERE the user is performing his job (answering
questions/giving
| input), you'd be able to give them a LIST of incomplete tasks from which
| they could pick.
| >
|
| THEN HOW DO YOU DETERMINE WHICH ROW IS ASSOCIATED WITH THAT USER? HOW
| DO YOU KNOW WHICH TASKS ARE COMPLETE AND WHICH ARE INCOMPLETE?
ROWS!!! i've made one suggestion already. i'm sure you've built logical code
before that validates data, right? nothing changes in answering your second
question.
| sessions WON'T allow you to do that. a DB will...with great flexibility
in
| ANY context however you implement your access to a process per user. if
you
| remember, you said a db essentially does shit for the op's problem. you
| clearly see i beg to differ.
| >
|
| SESSIONS KEEP TRACK OF WHICH ROW IN THE DATABASE IS BEING REFERENCED.
you're not solving anything by using sessions. only complicating minor
problems like dropped sessions.
| | | 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.
| >
| then you're mind is wholly inable to imagine the TYPE of general
| functionality the op wants AND can't draw from you previous EXPERIENCE
to
| correlate different solutions that are applicable to the TYPE.
| >
| intellect is measure by inference and association. are you saying you
truly
| see NO similarities between my 'ramblings' and what the op is doing? if
not,
| i feel for you, bro.
| >
| | The fact is, if you lose the key to your row, you can't access that
row.
| >
| data is in the db. a query will return the correct step that is next in
the
| ladder of steps to get to the top. user logs back in, that step is
| displayed. now, pray-tell, HOW IS THE DATA LOST?
| >
| >
|
| And your mind is completely unable to grasp a simple concept. If the
| session is lost and there is no user login, there is no way to reference
| the row in the table related to this user.
sure there is...use your imagination.
| You have 500 users currently active. Suddenly one of them loses a
| session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
| USER? THERE IS NOT LOGIN!
not a problem.
| And YES I'M YELLING. You don't seem to grasp even a simple concept.
sure i do. in fact, i've got 6 manufacturing plants with over 400
workstations total that all have multi-stepped, conditional routing. in 3
years of it being in service, i've only ever had to go back to add new
reports. everything else, as i high-leveled here, is sound. AND, the only
thing i ever session is the user name and password and a security key.
if you can't grasp that this is NOT dependant on logins, you are only fit to
program in a paper bag from which you cannot break out of.
>data is in the db. a query will return the correct step that is next in the
>ladder of steps to get to the top. user logs back in, that step is
displayed. now, pray-tell, HOW IS THE DATA LOST?
Your database will gradually collect abandoned sessions. Users
tend not to use "logout" buttons. You might ask a hard question
that requires research. People get called into meetings. Users
click on an ad and don't come back. Browsers crash. OSs crash.
Your user returns. You didn't get him to log in, so there's no
such thing as a "user name". The session key is lost. How do
identify which session is his? There are 87 sessions abandoned at
step 1, 37 sessions abandoned at step 2, 55 sessions abandoned at
step 3, 14 sessions abandoned at step 4, and 5 abandoned at step
5. Which step do you restart at, and using which set of data?
>| note that as i've said. the chances of losing data due to deletion is
nil.
Losing data due to hiding it like a needle in a needlestack is
losing it even if you can still prove it's in there somewhere.
>| 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.
data is in the db. a query will return the correct step that is next in the
ladder of steps to get to the top.
When you have 198 abandoned sessions, what does the WHERE clause of that
query look like to find the correct one? Oh, yes, there may be severe
privacy implications of showing them all the sessions and letting them
pick one.
Also, if you've got that many abandoned sessions, it's probably easier
for the user to just start over rather than read all of them. That's
"buried in bullshit" lost.
>user logs back in, that step is
displayed. now, pray-tell, HOW IS THE DATA LOST?
>
| | | 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.
then wtf don't you just address how he can solve the session problem instead
of giving BAD architectual advice...like, 'a db won't get you any closer to
solving the problem'. as i've pointed out, it DOES allow for a way to
recover. you just have no idea how to implement a fail-safe.
get over it.
| 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.
in the architecture *i've* described, NO LOGIN NEED BE PRESENT. as i said,
if you simply select what work you'd like to begin, having a DB will allow
you to query DATA for what is left to do for the task. even without a login,
identifying WHERE the user is performing his job (answering questions/giving
input), you'd be able to give them a LIST of incomplete tasks from which
they could pick.
sessions WON'T allow you to do that. a DB will...with great flexibility in
ANY context however you implement your access to a process per user. if you
remember, you said a db essentially does shit for the op's problem. you
clearly see i beg to differ.
| | 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.
then you're mind is wholly inable to imagine the TYPE of general
functionality the op wants AND can't draw from you previous EXPERIENCE to
correlate different solutions that are applicable to the TYPE.
intellect is measure by inference and association. are you saying you truly
see NO similarities between my 'ramblings' and what the op is doing? if not,
i feel for you, bro.
| The fact is, if you lose the key to your row, you can't access that row.
data is in the db. a query will return the correct step that is next in the
ladder of steps to get to the top. user logs back in, that step is
displayed. now, pray-tell, HOW IS THE DATA LOST?
>data is in the db. a query will return the correct step that is next in the
>ladder of steps to get to the top. user logs back in, that step is
displayed. now, pray-tell, HOW IS THE DATA LOST?
And your mind is completely unable to grasp a simple concept. If the
session is lost and there is no user login, there is no way to reference
the row in the table related to this user.
You have 500 users currently active. Suddenly one of them loses a
session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
USER? THERE IS NOT LOGIN!
His solution to that is to display 500 credit card numbers and names
and addresses, mostly of other people, and let the user choose his.
Even without privacy and security issues, it sounds a lot easier
to just start over, or better, go to a different web site run by a
different company entirely.
>| WHAT HAPPENS IF THIS DOES NOT REQUIRE A LOGIN????? NOTHING WAS EVER SAID
>| ABOUT THE USER LOGGING IN!
imagine if you will/can, that the form carries a tag perhaps identifying
say, an ip address - i know it's a stretch for you. that would certainly be
ONE way to marry an instance of data with a browser. input is stored in a db
with each post/get. when that ip (in this instance) and its data was
analized, we could then still tell where the user left off - or what the
next step would be.
Imagine that you subscribe to AOL, where consecutive web hits from
your browser appear to come from different IP addresses. Imagine
that you subscribe to a dialup ISP, where getting back the same IP
address after the modem disconnects can take days of tries. Imagine
that you sometimes access the Internet from different places, like
home, work, and your cell phone, all of which have different IP
addresses.
"Gordon Burditt" <go***********@burditt.orgwrote in message
news:13*************@corp.supernews.com...
| >data is in the db. a query will return the correct step that is next in
the
| >ladder of steps to get to the top. user logs back in, that step is
| >displayed. now, pray-tell, HOW IS THE DATA LOST?
|
| Your database will gradually collect abandoned sessions. Users
| tend not to use "logout" buttons. You might ask a hard question
| that requires research. People get called into meetings. Users
| click on an ad and don't come back. Browsers crash. OSs crash.
you state logout, so i assume login is required in your dismal scenario
here. the tie-in here of course would be answered with $userName.
| Your user returns. You didn't get him to log in, so there's no
| such thing as a "user name". The session key is lost. How do
| identify which session is his? There are 87 sessions abandoned at
| step 1, 37 sessions abandoned at step 2, 55 sessions abandoned at
| step 3, 14 sessions abandoned at step 4, and 5 abandoned at step
| 5. Which step do you restart at, and using which set of data?
so now there is no $userName. either consider it abandoned if the session
key is lost, or if it is important enough, make a log in required script.
even so, there are many a means to generate a unique id without a log on
that comes pretty close be assuring the client returning is in fact, the
client.
fact of the matter is, you still are NOT showing one set of architecture as
being better than any other. all of these issues STILL EXIST if you keep all
data sessioned and lose the sesssion. if there is a login, that's no big
deal...you know what data belongs to whom. if it's shared data (i.e. a part
being built up at a station) then identifying the station at which work
would be done will give you a list of things currently being built that you
can state you're working on. otherwise i'll relent, you're in the same boat
as sessioning...however there is far more flexibility in db driven steps
than sessioned steps...such as being able to work a part with multiple
employees (which is often the case).
| >| note that as i've said. the chances of losing data due to deletion is
| >nil.
|
| Losing data due to hiding it like a needle in a needlestack is
| losing it even if you can still prove it's in there somewhere.
and how does sessioned data prevent any of this. how does this go to show
that db driven steps are equal in architectural flexibility. it simply does
not.
|
| >| 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.
| >
| >data is in the db. a query will return the correct step that is next in
the
| >ladder of steps to get to the top.
|
| When you have 198 abandoned sessions, what does the WHERE clause of that
| query look like to find the correct one? Oh, yes, there may be severe
| privacy implications of showing them all the sessions and letting them
| pick one.
|
| Also, if you've got that many abandoned sessions, it's probably easier
| for the user to just start over rather than read all of them. That's
| "buried in bullshit" lost.
same as i've just said above. there are ways to identify and reclaim the
appropriate records that need editing. it really depends on the business
requirements. i can tell you that i can scale db driven steps whereas you
cannot say the same for sessioned data. you'd also have a hell of a time
sharing the data between multiple clients sessioning data.
both of you still have NOT answered the op's direct question about how to
SOLVE DROPPED SESSIONS. i point him to what to look for. further, that it is
a better fallback to db the inputs rather than session them. again, you two
still have NOT shown that both methods are equal. either of you still have
not layed out a solid, concrete real world scenario that demonstrates
sessions as superior.
i'll wait for that.
"Gordon Burditt" <go***********@burditt.orgwrote in message
news:13*************@corp.supernews.com...
|>| WHAT HAPPENS IF THIS DOES NOT REQUIRE A LOGIN????? NOTHING WAS EVER SAID
| >| ABOUT THE USER LOGGING IN!
| >
| >imagine if you will/can, that the form carries a tag perhaps identifying
| >say, an ip address - i know it's a stretch for you. that would certainly
be
| >ONE way to marry an instance of data with a browser. input is stored in a
db
| >with each post/get. when that ip (in this instance) and its data was
| >analized, we could then still tell where the user left off - or what the
| >next step would be.
|
| Imagine that you subscribe to AOL, where consecutive web hits from
| your browser appear to come from different IP addresses. Imagine
| that you subscribe to a dialup ISP, where getting back the same IP
| address after the modem disconnects can take days of tries. Imagine
| that you sometimes access the Internet from different places, like
| home, work, and your cell phone, all of which have different IP
| addresses.
gee, imagine that each time you connect, you get a different session_id
regarless of ANY of these factors. imagine you actually go on now to explain
to me the architectual advantage OVER my suggestion(s) to db data rather
than session it.
as it is, the only time any of this becomes an issue with my suggested
architecture is when there is no login...but i guess that's why yall have
picked at that. under that scenario, AT BEST sessions are equal to db driven
steps...however you'll not be able to reuse your sessioning code in more
secure sencarios that i did layout where a login is required; nor will you
be able to scale sessioning data even if you were to port it to said
environment.
make a case that shows sessioning data is BETTER than db driven steps...then
you'll impress me. until then, you're just bitching trying to catch up.
"Gordon Burditt" <go***********@burditt.orgwrote in message
news:13*************@corp.supernews.com...
| >data is in the db. a query will return the correct step that is next in
the
| >ladder of steps to get to the top. user logs back in, that step is
| >displayed. now, pray-tell, HOW IS THE DATA LOST?
| >>
| >>
| >
| >And your mind is completely unable to grasp a simple concept. If the
| >session is lost and there is no user login, there is no way to reference
| >the row in the table related to this user.
| >
| >You have 500 users currently active. Suddenly one of them loses a
| >session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
| >USER? THERE IS NOT LOGIN!
|
| His solution to that is to display 500 credit card numbers and names
| and addresses, mostly of other people, and let the user choose his.
you can't make a good argument when you mix context scenarios. you know my
architecture holds more merit than sessioning ESPECIALLY IN THIS CASE. first
THERE WILL BE A LOGIN. second, I CAN HIJACK SESSIONS. you wanna continue
arguing your case now?!!!
| Even without privacy and security issues, it sounds a lot easier
| to just start over, or better, go to a different web site run by a
| different company entirely.
you've lost credibility with me now, as you cannot state a case much less
back it up.
ROFLMAO.
>| >data is in the db. a query will return the correct step that is next in
>the
| >ladder of steps to get to the top. user logs back in, that step is
| >displayed. now, pray-tell, HOW IS THE DATA LOST?
| >>
| >>
| >
| >And your mind is completely unable to grasp a simple concept. If the
| >session is lost and there is no user login, there is no way to reference
| >the row in the table related to this user.
| >
| >You have 500 users currently active. Suddenly one of them loses a
| >session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
| >USER? THERE IS NOT LOGIN!
|
| His solution to that is to display 500 credit card numbers and names
| and addresses, mostly of other people, and let the user choose his.
you can't make a good argument when you mix context scenarios. you know my
architecture holds more merit than sessioning ESPECIALLY IN THIS CASE. first
THERE WILL BE A LOGIN.
I've seen plenty of stores where no login is required to enter an
order. (but generally multiple screens are involved in entering
the order). Stores that absolutely require a login for physical
goods delivered by USPS, UPS, or FedEx seem to be pretty rare. If
you enter lots of orders, a login is convenient. If it's a one-shot,
maybe not.
Each order stands on its own. Either the site does not provide
order tracking, or it gives you an order number once the order is
finally submitted (and a site will typically suggest you print it)
which can be used later for tracking (and at that point, you can
call the order number a login if you like). Now, it's POSSIBLE for
a store to give an order number to an order at the time you start
composing it. I've never seen a store actually DO that, though.
>second, I CAN HIJACK SESSIONS. you wanna continue
Hijacking sessions is not all that easy without access to the user's
computer. Guessing valid credit card numbers is probably easier
(and is more profitable) than hijacking sessions. And sessions
often last for only a short period of time.
>arguing your case now?!!!
>| Even without privacy and security issues, it sounds a lot easier
| to just start over, or better, go to a different web site run by a
| different company entirely.
you've lost credibility with me now, as you cannot state a case much less
back it up.
I'm absolutely serious here: if you're going to show me 500
incomplete entries and ask me to pick mine, and I have to proofread
the one I select carefully to make sure it has no errors in it,
it's easier to enter it all over again. The amount of data entry
for an order of several items isn't that large, and it's much, much
easier than reading 500 incomplete entries to find mine.
My point here is: IF YOU LOSE THE KEY REFERENCING THE DATA, YOU
HAVE NO PRACTICAL WAY TO RECOVER. I don't care where you keep the
data referenced by the key. Put it in $_SESSION. Put it in a
database. Carve it in stone tablets if you like. The important
issue is what you use for a key. You can use a session key stored
as a cookie or as part of a URL, like PHP does. You can use something
fairly permanent you make the user remember (often called a "login").
You can use something temporary you make the user remember (like
giving the user an order number while the order is in process of
being entered). You cannot get away with making up something on
the fly when the user tries to come back to recover an abandoned
session.
Steve wrote:
| WHAT HAPPENS IF THIS DOES NOT REQUIRE A LOGIN????? NOTHING WAS EVER SAID
| ABOUT THE USER LOGGING IN!
imagine if you will/can, that the form carries a tag perhaps identifying
say, an ip address - i know it's a stretch for you. that would certainly be
ONE way to marry an instance of data with a browser. input is stored in a db
with each post/get. when that ip (in this instance) and its data was
analized, we could then still tell where the user left off - or what the
next step would be.
Gee, and what do you do with corporate firewalls - where all users
inside the firewall have the same IP address? Or users like AOL - where
every request may come from a different proxy - and therefore a
different IP?
I know such an idea is a stretch for you - the fact that IP addresses
are not unique - and not necessarily consistent.
i can come up with several other matching methods. care for more
embarrassment?
Sure, fire away. You've already made an ass of yourself several times.
Keep it up!
| | 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.
| >
| data is in the db. a query will return the correct step that is next in
the
| ladder of steps to get to the top. user logs back in, that step is
| displayed. now, pray-tell, HOW IS THE DATA LOST?
| >
|
| ONLY IF YOU HAVE THE PRIMARY KEY TO THE COLUMN!!! IF THERE IS NO LOGIN,
| HOW DO YOU DETERMINE WHICH ROW IT IS?
yelling is not compensating for your lack of imagination. you keep talking
about rows. you realize that in a stepped operation, you are not talking
about just one row of data. each step is probably its own row. i've pointed
out one way to link a browser instance with data...no reason why it can't be
tied to all the related rows. as each row is validated as 'complete', we
simply provide the next set of prompts for input...ad nausium until the
ladder has been summited.
No, but it seems to be the only way you can understand what anyone else
is saying.
I'm still waiting for you to come up with a way to indicate how to
recognize the appropriate row(s). So far you haven't.
| | | | 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.
| >
| then wtf don't you just address how he can solve the session problem
instead
| of giving BAD architectual advice...like, 'a db won't get you any closer
to
| solving the problem'. as i've pointed out, it DOES allow for a way to
| recover. you just have no idea how to implement a fail-safe.
| >
| get over it.
| >
|
| THEN GET OVER IT! THE ARCHITECTURAL ADVICE IS SOLID! AND YOU HAVEN'T
| POINTED OUT ANYTHING EXCEPT "IF THE USER LOGS IN...".
yes, MY design is solid. saying db storage leaves you no better off than
just sessioning the user input is LUDICROUS. btw, that was YOUR advice.
As solid as swiss cheese. Glad you aren't working for me.
and, i've pointed out MANY ways to do all of this. i can pseudo code a whole
example WITHOUT using logins if that's the only way your pea sized brain can
conceptualize...solidified as concrete!
You've pointed out NO WAY to do this - other than to require a logon, an
ip address or similar.
>
| And that does solve the problem of the user having to log in.
No, you haven't shown any way to do it.
hmmm...'that' would be what? sessioning data from a browser where the op is
KNOWN to have sessions dropped? i don't see how that does anything BUT drop
the data collected for that user. if you validate and save collected
information with each steps posted info, you won't even lose a NEW
record...nor a modified on.
And how do you point to the appropriate record?
| | 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.
| >
| in the architecture *i've* described, NO LOGIN NEED BE PRESENT. as i
said,
| if you simply select what work you'd like to begin, having a DB will
allow
| you to query DATA for what is left to do for the task. even without a
login,
| identifying WHERE the user is performing his job (answering
questions/giving
| input), you'd be able to give them a LIST of incomplete tasks from which
| they could pick.
| >
|
| THEN HOW DO YOU DETERMINE WHICH ROW IS ASSOCIATED WITH THAT USER? HOW
| DO YOU KNOW WHICH TASKS ARE COMPLETE AND WHICH ARE INCOMPLETE?
ROWS!!! i've made one suggestion already. i'm sure you've built logical code
before that validates data, right? nothing changes in answering your second
question.
You mean one asinine suggestion which works only if you can guarantee
there is concurrent access - or you require a user to login.
| sessions WON'T allow you to do that. a DB will...with great flexibility
in
| ANY context however you implement your access to a process per user. if
you
| remember, you said a db essentially does shit for the op's problem. you
| clearly see i beg to differ.
| >
|
| SESSIONS KEEP TRACK OF WHICH ROW IN THE DATABASE IS BEING REFERENCED.
you're not solving anything by using sessions. only complicating minor
problems like dropped sessions.
| | | 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.
| >
| then you're mind is wholly inable to imagine the TYPE of general
| functionality the op wants AND can't draw from you previous EXPERIENCE
to
| correlate different solutions that are applicable to the TYPE.
| >
| intellect is measure by inference and association. are you saying you
truly
| see NO similarities between my 'ramblings' and what the op is doing? if
not,
| i feel for you, bro.
| >
| | The fact is, if you lose the key to your row, you can't access that
row.
| >
| data is in the db. a query will return the correct step that is next in
the
| ladder of steps to get to the top. user logs back in, that step is
| displayed. now, pray-tell, HOW IS THE DATA LOST?
| >
| >
|
| And your mind is completely unable to grasp a simple concept. If the
| session is lost and there is no user login, there is no way to reference
| the row in the table related to this user.
sure there is...use your imagination.
| You have 500 users currently active. Suddenly one of them loses a
| session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
| USER? THERE IS NOT LOGIN!
not a problem.
| And YES I'M YELLING. You don't seem to grasp even a simple concept.
sure i do. in fact, i've got 6 manufacturing plants with over 400
workstations total that all have multi-stepped, conditional routing. in 3
years of it being in service, i've only ever had to go back to add new
reports. everything else, as i high-leveled here, is sound. AND, the only
thing i ever session is the user name and password and a security key.
if you can't grasp that this is NOT dependant on logins, you are only fit to
program in a paper bag from which you cannot break out of.
Steve,
It's pretty obvious you're a "wanna-be" with no real understanding of
how the internet works, nor do you have any idea how to develop a secure
application.
As I said before - I'm glad you aren't working for me. If you were, you
wouldn't be for long.
But you're a typical troll - all the answers and refuse to see the
weakness of any of them.
What do you have - three months of experience in programming? Maybe less?
As for the "clients" you mentioned in previous posts. Now you've also
proven you're a liar. I HAVE worked for some of these clients. And
none of them would hire anyone with your "credentials".
Get lost, loser.
<PLONK>!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Gordon Burditt wrote:
>| WHAT HAPPENS IF THIS DOES NOT REQUIRE A LOGIN????? NOTHING WAS EVER SAID
| ABOUT THE USER LOGGING IN!
imagine if you will/can, that the form carries a tag perhaps identifying
say, an ip address - i know it's a stretch for you. that would certainly be
ONE way to marry an instance of data with a browser. input is stored in a db
with each post/get. when that ip (in this instance) and its data was
analized, we could then still tell where the user left off - or what the
next step would be.
Imagine that you subscribe to AOL, where consecutive web hits from
your browser appear to come from different IP addresses. Imagine
that you subscribe to a dialup ISP, where getting back the same IP
address after the modem disconnects can take days of tries. Imagine
that you sometimes access the Internet from different places, like
home, work, and your cell phone, all of which have different IP
addresses.
Gordon,
Forget it. He doesn't want to understand how things really work. He's
got this idea on how the internet works "According to Steve". Never
mind it's so far from real life it isn't even funny.
He'll argue with you that his way is right until the end of the universe
- and NEVER even come close to agreeing that someone else may have a
valid point.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
Gordon Burditt wrote:
>>data is in the db. a query will return the correct step that is next in the
ladder of steps to get to the top. user logs back in, that step is
displayed. now, pray-tell, HOW IS THE DATA LOST?
And your mind is completely unable to grasp a simple concept. If the
session is lost and there is no user login, there is no way to reference
the row in the table related to this user.
You have 500 users currently active. Suddenly one of them loses a
session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
USER? THERE IS NOT LOGIN!
His solution to that is to display 500 credit card numbers and names
and addresses, mostly of other people, and let the user choose his.
Even without privacy and security issues, it sounds a lot easier
to just start over, or better, go to a different web site run by a
different company entirely.
That sounds about right!
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:1t******************************@comcast.com. ..
| Gordon Burditt wrote:
| >| WHAT HAPPENS IF THIS DOES NOT REQUIRE A LOGIN????? NOTHING WAS EVER
SAID
| >| ABOUT THE USER LOGGING IN!
| >>
| >imagine if you will/can, that the form carries a tag perhaps
identifying
| >say, an ip address - i know it's a stretch for you. that would
certainly be
| >ONE way to marry an instance of data with a browser. input is stored in
a db
| >with each post/get. when that ip (in this instance) and its data was
| >analized, we could then still tell where the user left off - or what
the
| >next step would be.
| >
| Imagine that you subscribe to AOL, where consecutive web hits from
| your browser appear to come from different IP addresses. Imagine
| that you subscribe to a dialup ISP, where getting back the same IP
| address after the modem disconnects can take days of tries. Imagine
| that you sometimes access the Internet from different places, like
| home, work, and your cell phone, all of which have different IP
| addresses.
| >
|
| Gordon,
|
| Forget it. He doesn't want to understand how things really work. He's
| got this idea on how the internet works "According to Steve". Never
| mind it's so far from real life it isn't even funny.
|
| He'll argue with you that his way is right until the end of the universe
| - and NEVER even come close to agreeing that someone else may have a
| valid point.
when you get a valid point, i'll listen. as for the real world...i've got
this architecture set up in manufacturing plants. were it to be improperly
put together, it could cost a life. i've got calibration machinery drawing
their specs from the assembled parts from the build up. while you may be
comfortable in half measures, i couldn't have been a .5 psi off or things
explode. route the wrong parts to the wrong station and things crack and
otherwise fail. someone doesn't go home.
i know what i'm talking about. as for you, you try to argue a theoretical
position that you can even supply meat for. and instead of giving ONE REAL
WORLD EXAMPLE of how YOU are right, you just say, 'awe...we know we're
right, this guy just don't see it our way'...well, there's not room enough
in your ass for three heads to fit simultaneously...so, NO, i don't and
can't see it your way...i can fit my head in there.
make a point, back it up, and give an example in real terms. as i've done
all that, i don't think you have room to talk about how *I* am not
listening...you're 'according to' applies moreso to yourself.
but whatever.
| Sure, fire away. You've already made an ass of yourself several times.
| Keep it up!
and when was this exactly?
| yelling is not compensating for your lack of imagination. you keep
talking
| about rows. you realize that in a stepped operation, you are not talking
| about just one row of data. each step is probably its own row. i've
pointed
| out one way to link a browser instance with data...no reason why it
can't be
| tied to all the related rows. as each row is validated as 'complete', we
| simply provide the next set of prompts for input...ad nausium until the
| ladder has been summited.
| >
|
| No, but it seems to be the only way you can understand what anyone else
| is saying.
you still have yet to make a point. whether you yell or not doesn't get you
there.
| I'm still waiting for you to come up with a way to indicate how to
| recognize the appropriate row(s). So far you haven't.
i'm still waiting for you to unveil AN example of where sessioning data is >
db data. i suspect you haven't because it is not and you cannot because of
that.
| yes, MY design is solid. saying db storage leaves you no better off than
| just sessioning the user input is LUDICROUS. btw, that was YOUR advice.
| >
|
| As solid as swiss cheese. Glad you aren't working for me.
i'm suprised you are working at all. now, show sessioning data is better
than storing it in a db. the best you can do is say they are equal when
there is no unique identifier.
| and, i've pointed out MANY ways to do all of this. i can pseudo code a
whole
| example WITHOUT using logins if that's the only way your pea sized brain
can
| conceptualize...solidified as concrete!
|
| You've pointed out NO WAY to do this - other than to require a logon, an
| ip address or similar.
there are several...the best would be a login. even without all that, if a
session is lost then so is the data - in THAT case if there is not unique
identifier, then all that is shown is that in that aspect, the two
approaches are equal. yet, i've given several options available that apply
to data sharing, recovery, etc. where db storage is the only way to acheive
those basic tasks. you cannot provide even one that shows how sessioning
data would scale...even in different circumstances.
| >
| | And that does solve the problem of the user having to log in.
| >
|
| No, you haven't shown any way to do it.
|
| hmmm...'that' would be what? sessioning data from a browser where the op
is
| KNOWN to have sessions dropped? i don't see how that does anything BUT
drop
| the data collected for that user. if you validate and save collected
| information with each steps posted info, you won't even lose a NEW
| record...nor a modified on.
| >
|
| And how do you point to the appropriate record?
via a login in the most common of situations. but, since that's the only
requirement, you go ahead and pick at it..failing to realize that not
utilizing a unique identifier AT BEST only makes sessioning data == db
storage...you still have yet to show it being BETTER than db storage. give
it a try. oh yeah, you can't because it is not. try anyway. a real-world
example. i'll wait.
| ROWS!!! i've made one suggestion already. i'm sure you've built logical
code
| before that validates data, right? nothing changes in answering your
second
| question.
| >
|
| You mean one asinine suggestion which works only if you can guarantee
| there is concurrent access - or you require a user to login.
clearly you don't get it. worst case scenario is i have no login and am
sessioning a unique id among the collected ROWS, the session is dropped.
that leaves both db and sessioning data in the crapper. the two methods are
equal in that light. however, there are a bunch of ways to grow/scale what
you can do if the data is not restricted just to sessioned data (which
cannot be stored indefinitely or shared simultaneously among other clients).
your claim was that db storage was no better than sessioning data. the OP
never mentioned whether there was/not a login involved. i made several cases
of the benefits of db storage...proving you wrong. and at best, you are only
right in one limited context. however, in that context, even when equal
effects ripple, the db storage architecture can be scaled. sessioning data
is very limited in functionality.
but you just keep plugg'n away. you're not making any heads turn.
| Steve,
|
| It's pretty obvious you're a "wanna-be" with no real understanding of
| how the internet works, nor do you have any idea how to develop a secure
| application.
funny how this is your standard retort when i call you on the carpet when
your advice is bad. you offer no valid support to your original claims nor
counters that make mine seem less than valid. and, when all else fails, you
make even more broad claims of what you 'feel' my experience level is.
i'd say either a valid point that you can maintain or some debate classes
would serve you well.
| As I said before - I'm glad you aren't working for me. If you were, you
| wouldn't be for long.
again, you're employed?
| But you're a typical troll - all the answers and refuse to see the
| weakness of any of them.
at least i state my case, give examples of them, and logically defend them.
you just babble bullshit and hope it sticks.
whatever
| What do you have - three months of experience in programming? Maybe less?
more like 20+ ... but that's ok. console yourself to whatever helps you
sleep better at night.
| As for the "clients" you mentioned in previous posts. Now you've also
| proven you're a liar. I HAVE worked for some of these clients. And
| none of them would hire anyone with your "credentials".
really? and what 'credentials' would those be? have i stated them? no, just
for whom i've worked. and, which clients would those be? i'll be happy to
throw some names of those with whom you would have had to work with. you
tell me their titles and i'll believe you. btw, they won't be easy to
google.
and, as out-of-touch as you are with reality, it's not hard for me to
believe that your mistakes would not be limited to programming, but to
personnel as well.
"Gordon Burditt" <go***********@burditt.orgwrote in message
news:13*************@corp.supernews.com...
|>| >data is in the db. a query will return the correct step that is next
in
| >the
| >| >ladder of steps to get to the top. user logs back in, that step is
| >| >displayed. now, pray-tell, HOW IS THE DATA LOST?
| >| >>
| >| >>
| >| >
| >| >And your mind is completely unable to grasp a simple concept. If the
| >| >session is lost and there is no user login, there is no way to
reference
| >| >the row in the table related to this user.
| >| >
| >| >You have 500 users currently active. Suddenly one of them loses a
| >| >session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
| >| >USER? THERE IS NOT LOGIN!
| >|
| >| His solution to that is to display 500 credit card numbers and names
| >| and addresses, mostly of other people, and let the user choose his.
| >
| >you can't make a good argument when you mix context scenarios. you know
my
| >architecture holds more merit than sessioning ESPECIALLY IN THIS CASE.
first
| >THERE WILL BE A LOGIN.
|
| I've seen plenty of stores where no login is required to enter an
| order. (but generally multiple screens are involved in entering
| the order). Stores that absolutely require a login for physical
| goods delivered by USPS, UPS, or FedEx seem to be pretty rare. If
| you enter lots of orders, a login is convenient. If it's a one-shot,
| maybe not.
|
| Each order stands on its own. Either the site does not provide
| order tracking, or it gives you an order number once the order is
| finally submitted (and a site will typically suggest you print it)
| which can be used later for tracking (and at that point, you can
| call the order number a login if you like). Now, it's POSSIBLE for
| a store to give an order number to an order at the time you start
| composing it. I've never seen a store actually DO that, though.
well, on a smaller scale, pizza stores most often give 'order numbers' at
the beggining of an order. yes, i've worked as a contractor for a pizza
company (dominos - helped develop their stores' pos...it's called pulse in
case you don't believe me...that began in early 2000).
what we're talking about here is theory. the op didn't put any requirements
on his context. i made several points to counter stucco - he has a thing for
me you know. jerry just said that there was no advantage to db storage as
compared to sessioning data. this is clearly false and i gave examples of
where it was superior...and at worst, only == sessioning data. with no
unique id, db storage is equal to sessioning but clearly not what jerry
wants to concede.
it's interesting to me that the op asked how he could get sessions to not
drop. i gave suggestions directly to that and mentioned db storage as a
fail-safe. all jerry can do is bash that suggestion (not very well though),
and still hasn't answered the op's direct problem.
so why are you jumping into this fray?
anyway,
| >second, I CAN HIJACK SESSIONS. you wanna continue
|
| Hijacking sessions is not all that easy without access to the user's
| computer. Guessing valid credit card numbers is probably easier
| (and is more profitable) than hijacking sessions. And sessions
| often last for only a short period of time.
depends on server's config now don't it. give me the ability to upload files
to a site, and i'll echo out every session id there is on the server. if you
think hijacking a session is difficult, you need to school yourself a bit
more. the moral of that story is to only session the essentials...like a
user name and password and some kind of security code that is only valid in
a limited context. all three give you better security as all can be checked,
data is isolated to a secured/seperate location, and all can be recalled on
demand. each of these layers of seperation are what give better
security...not just thinking that it is easier to do x or y instead of what
i said...hijack your sessions. if i knew that's where you stored your
financials, fuck yeah...that's the first place i'd go. and, i'd get there
to.
| >arguing your case now?!!!
|
| >| Even without privacy and security issues, it sounds a lot easier
| >| to just start over, or better, go to a different web site run by a
| >| different company entirely.
| >
| >you've lost credibility with me now, as you cannot state a case much less
| >back it up.
|
| I'm absolutely serious here: if you're going to show me 500
| incomplete entries and ask me to pick mine, and I have to proofread
| the one I select carefully to make sure it has no errors in it,
| it's easier to enter it all over again. The amount of data entry
| for an order of several items isn't that large, and it's much, much
| easier than reading 500 incomplete entries to find mine.
you painted that picture, not me. i don't claim that's the best solution
either. what i am saying is that that's the worst case scenario you can
paint, and it still only makes db storage == to sessioning data. the
security issues, scalability, data sharing, and fail-safe mechanisms just
aren't going to show data for sessioning data. that was my point to jerry.
that he cannot say sessioning data and db storage are ==. they only can be
in select instances.
| My point here is: IF YOU LOSE THE KEY REFERENCING THE DATA, YOU
| HAVE NO PRACTICAL WAY TO RECOVER. I don't care where you keep the
| data referenced by the key. Put it in $_SESSION. Put it in a
| database. Carve it in stone tablets if you like. The important
| issue is what you use for a key. You can use a session key stored
| as a cookie or as part of a URL, like PHP does. You can use something
| fairly permanent you make the user remember (often called a "login").
| You can use something temporary you make the user remember (like
| giving the user an order number while the order is in process of
| being entered). You cannot get away with making up something on
| the fly when the user tries to come back to recover an abandoned
| session.
nor did i disagree with you. nor did i ever state anything to the contrary.
i said you're not always shit out of luck if you use db storage. if you
session your input, you are sol even IF you enable logins or ANY unique id.
if the session is lost, the data is ALWAYS gone. however with a unique id
and db storage, you just pick up where you left off.
architectually (and theoretically), what would it take to scale sessioning
data if someone over the project said, 'we need to secure this site more
thouroughly. let's say after x minutes of inactivity, we log a user out'? a
common practice during a logout is to erase a session's data and call
session destroy. what happened to your user's work? are you going to try and
store the data somewhere for that user? or, is he sol because of the new
policy. i happen to think the policy shouldn't cause a loss of work.
now, what impact would that have on a db stored architecture? what would you
have to do differently here? nothing...save, the user has to log back in
again and pick up where he left off.
why is this hard to see?
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:1t******************************@comcast.com. ..
| Gordon Burditt wrote:
| >>data is in the db. a query will return the correct step that is next
in the
| >>ladder of steps to get to the top. user logs back in, that step is
| >>displayed. now, pray-tell, HOW IS THE DATA LOST?
| >>>
| >>>
| >And your mind is completely unable to grasp a simple concept. If the
| >session is lost and there is no user login, there is no way to
reference
| >the row in the table related to this user.
| >>
| >You have 500 users currently active. Suddenly one of them loses a
| >session. Now - WHICH OF THOSE FIVE HUNDRED ROWS IS RELATED TO THAT
| >USER? THERE IS NOT LOGIN!
| >
| His solution to that is to display 500 credit card numbers and names
| and addresses, mostly of other people, and let the user choose his.
| >
| Even without privacy and security issues, it sounds a lot easier
| to just start over, or better, go to a different web site run by a
| different company entirely.
| >
|
| That sounds about right!
lol...and that's about the quality of any argument i've ever seen you
defend. lots of bark with no bites to show for the noise.
|| What do you have - three months of experience in programming? Maybe
less?
|
| more like 20+ ... but that's ok. console yourself to whatever helps you
| sleep better at night.
i'll let the other typos go, i figure i'll need to be preemptive here for
the jr. high schooler:
that's 20+ YEARS, not months.
Steve wrote:
|| What do you have - three months of experience in programming? Maybe
less?
|
| more like 20+ ... but that's ok. console yourself to whatever helps you
| sleep better at night.
i'll let the other typos go, i figure i'll need to be preemptive here for
the jr. high schooler:
that's 20+ YEARS, not months.
About 1/2 the amount of experience I have.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:ad******************************@comcast.com. ..
| Steve wrote:
| || What do you have - three months of experience in programming? Maybe
| less?
| |
| | more like 20+ ... but that's ok. console yourself to whatever helps
you
| | sleep better at night.
| >
| i'll let the other typos go, i figure i'll need to be preemptive here
for
| the jr. high schooler:
| >
| that's 20+ YEARS, not months.
| >
| >
|
| About 1/2 the amount of experience I have.
you have the logic of a turnip. years == length...not experience. you could
spend your life at westpoint and not have 1/2 the experience of an officer
who spent one year in combat. get the picture?
<da********@gmail.comwrote in message
news:11**********************@l77g2000hsb.googlegr oups.com...
I mean not about cookie.
Does it have something to do with operating system or browser plugin?
I appreciate any help.
Entering into this is perhaps the bravest thing I might ever had done in my
life.
What if one were to export the session data at intervals into files, or
overwrite a particular file at each step. The file/files being named in a
fashion that identifies their place in a hierachy, say a combination of
session id & time.
At the beginning of a new step, or say when there is a refresh perhaps, or
another appropriate time, the file data is compared against the contents the
$_session array.
If it's found that a step has been lost, or data is lost that can only be
explained by some failure, assume lost data, and reload the file back into
the session. This would effectively take the session back to a recently
saved state.
If these files were then deleted at a valid end of a session, or deleted
after a given period of time they should not become excessive.
If the session id and time were combined in the naming of the file then the
files should never be able to be retrieved accidently, thereby exposing
sensitive data.
Of course I am new to php, and internet programming in general and likely
have missed something in the scenario. However, it's something that
appears, to me, to offer a possible solution the the problem as it was
described by the OP.
Just a thought.
Vince
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46***********************@news.optusnet.com.a u...
<da********@gmail.comwrote in message
I forgot to offer any real context.
print_r($_SESSION["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 }
At this point the previously saved state of the session data could be
reloaded. The session id would still be the same at this point, so the
correct file to load can easily be idendified.
* or this:
* { }
* If we refresh the browser on or more times, the $_SESSION["f5s"]-
>_status would be complete (or uncomplete).
If after reresh, and data is missing, samo. I'm not sure that JS would be
required for this, though I beleive it would.
Vince
| What if one were to export the session data at intervals into files, or
| overwrite a particular file at each step. The file/files being named in a
| fashion that identifies their place in a hierachy, say a combination of
| session id & time.
i think you're leaning towards 'magic' here using files with names packed
with meaning. i don't think this would do anything for you. 1) because you
can do all of this in sessions without the additional work. 2) if there is a
loss of a session, you're in the same boat as the rest of the alternatives
presented. 3) except you're using files to store the data, is that
significantly different than using another external storage
facility...like...a db?
| At the beginning of a new step, or say when there is a refresh perhaps, or
| another appropriate time, the file data is compared against the contents
the
| $_session array.
ok.
| If it's found that a step has been lost, or data is lost that can only be
| explained by some failure, assume lost data, and reload the file back into
| the session. This would effectively take the session back to a recently
| saved state.
which file goes with what client? what does the file store (i.e. social
security numbers, credit card information, a list of addresses for those
under witness protection). making the wrong decision about whose data
belongs to whom is a big deal.
| If these files were then deleted at a valid end of a session, or deleted
| after a given period of time they should not become excessive.
| If the session id and time were combined in the naming of the file then
the
| files should never be able to be retrieved accidently, thereby exposing
| sensitive data.
however, this only adds a level of complexity that needn't be there. both
proposals (sessioning data and db storing data) work just fine when sessions
are in place. jerry sees this as an equality...really, he just wanted to
take a dig at my original response to the op (whom he never even addresses
in this thread for all his ranting). the distinction i've made is that if
there is a means to accurately associate data with a client (say a user id,
questionaire id, part number, workstation id, etc.), then db storage is the
best alternative, as it can scale, you can recover from dropped sessions
with zero additional programming, you can share data concurrently with
others (viewing, editing, etc.)...none of these are options with just
sessioning data.
argument over, point made, jerry can kiss my ass.
| Of course I am new to php, and internet programming in general and likely
| have missed something in the scenario. However, it's something that
| appears, to me, to offer a possible solution the the problem as it was
| described by the OP.
| Just a thought.
i know, huh! i gave a couple of suggestions. i've seen many posts about this
before and had hoped someone would respond - as i haven't run into this
problem. jerry just wanted a venue to make a point, however he never really
made it. he don't like me much which is why that's all he addressed.
oh well.
cheers, vinnie.
"Steve" <no****@example.comwrote in message
news:64*****************@newsfe12.lga...
| What if one were to export the session data at intervals into files, or
| overwrite a particular file at each step. The file/files being named in
a
| fashion that identifies their place in a hierachy, say a combination of
| session id & time.
i think you're leaning towards 'magic' here using files with names packed
with meaning. i don't think this would do anything for you. 1) because you
can do all of this in sessions without the additional work. 2)
It seemed that the OP was loosing data within the session array, but I don't
see that he ever mentioned loosing the session id?
Did I miss something there?
The file dump idea occured to me when the OP first described the problem.
>if there is a
loss of a session, you're in the same boat as the rest of the alternatives
presented. 3) except you're using files to store the data, is that
significantly different than using another external storage
facility...like...a db?
Nope, not at all, it's that I considered it easier to simply reload
exported data directly from a file rather than reqeery it on such a failure.
Though I realize it's worthless if the session id is also lost.
I hadn't considered using a db in my planning, at least not in this context,
until I had read these posts. I've been designing classes to hold the data
in the session var, then I read the post and wack!!
It freaked me out actualy, as I am currently in the process of redesigning a
site that involves ecommerce, and can involve various steps, going back and
forth. Yes, I am well aware of the fact that I am not at all experienced
enough in this technology to be doing this, but I've got the job due to
previous work, and I have warned them, without effect ;) I'm also
detirmined to do it correctly, whatever lack of sleep that may involve. And
I do have a few months to get my act together.
The db solution is certainly a viable alternative, and if a session var can
loose data then it is certainly superior to my original direction.
Vince
| i think you're leaning towards 'magic' here using files with names
packed
| with meaning. i don't think this would do anything for you. 1) because
you
| can do all of this in sessions without the additional work. 2)
|
| It seemed that the OP was loosing data within the session array, but I
don't
| see that he ever mentioned loosing the session id?
| Did I miss something there?
| The file dump idea occured to me when the OP first described the problem.
i think it's a bit more than that. a session has an id. that id points to a
file on the server's hd. that file contains the data in question. dropping a
session, to me obviously, means that the data may/not be in the session_data
dir in a file, however the browser and the server act as if they've never
spoken before. the 'drop' is simply not being able to associate a client
with it's session file.
i don't think he was actually describing that he still had the correct
session and some of his code was unsetting his values...it's more that the
session is lost. at least how i read it.
| >if there is a
| loss of a session, you're in the same boat as the rest of the
alternatives
| presented. 3) except you're using files to store the data, is that
| significantly different than using another external storage
| facility...like...a db?
| >
| Nope, not at all, it's that I considered it easier to simply reload
| exported data directly from a file rather than reqeery it on such a
failure.
| Though I realize it's worthless if the session id is also lost.
a file works just fine...my point was what you just said, 'worthless if the
session id is also lost'.
| I hadn't considered using a db in my planning, at least not in this
context,
| until I had read these posts. I've been designing classes to hold the data
| in the session var, then I read the post and wack!!
| It freaked me out actualy, as I am currently in the process of redesigning
a
| site that involves ecommerce, and can involve various steps, going back
and
| forth. Yes, I am well aware of the fact that I am not at all experienced
| enough in this technology to be doing this, but I've got the job due to
| previous work, and I have warned them, without effect ;) I'm also
| detirmined to do it correctly, whatever lack of sleep that may involve.
And
| I do have a few months to get my act together.
| The db solution is certainly a viable alternative, and if a session var
can
| loose data then it is certainly superior to my original direction.
vinnie, you're more than capable of doing them proud. i'm sure you approach
the problem in a similarly logical break-down of requirements and solution
strategy as when you're programming c++.
hope that goes well for you.
Vince Morgan wrote:
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46***********************@news.optusnet.com.a u...
><da********@gmail.comwrote in message
I forgot to offer any real context.
print_r($_SESSION["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 }
At this point the previously saved state of the session data could be
reloaded. The session id would still be the same at this point, so the
correct file to load can easily be idendified.
* or this:
* { }
* If we refresh the browser on or more times, the $_SESSION["f5s"]-
>_status would be complete (or uncomplete).
If after reresh, and data is missing, samo. I'm not sure that JS would be
required for this, though I beleive it would.
Vince
Vince,
Since the session data is stored on the server and not the user's
computer, any access to the session data with that ID would show the
same thing. No browser refresh, and no way for it to get out of sync.
And no JS is required.
You may be thinking of cookies, where the data may be out of date on a
computer until the browser is refreshed.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
==================
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:kL******************************@comcast.com. ..
Since the session data is stored on the server and not the user's
computer, any access to the session data with that ID would show the
same thing. No browser refresh, and no way for it to get out of sync.
And no JS is required.
You may be thinking of cookies, where the data may be out of date on a
computer until the browser is refreshed.
I was thinking of onRefresh, but have to admit I've not a clue what I
would/could do with it as I haven't yet looked at this event. Something I
should have thought more about before writing ;)
"Vince Morgan" <vi****@REMOVEoptusnet.com.auwrote in message
news:46***********************@news.optusnet.com.a u...
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:kL******************************@comcast.com. ..
Since the session data is stored on the server and not the user's
computer, any access to the session data with that ID would show the
same thing. No browser refresh, and no way for it to get out of sync.
And no JS is required.
You may be thinking of cookies, where the data may be out of date on a
computer until the browser is refreshed.
I was thinking of onRefresh, but have to admit I've not a clue what I
would/could do with it as I haven't yet looked at this event. Something I
should have thought more about before writing ;)
Actualy I had a vague notion of using JS to re-request the page via
onReresh. But having looked at it this morning can see I was barking up the
wrong tree ;)
Vince Morgan wrote:
"Jerry Stuckle" <js*******@attglobal.netwrote in message
news:kL******************************@comcast.com. ..
>Since the session data is stored on the server and not the user's
computer, any access to the session data with that ID would show the
same thing. No browser refresh, and no way for it to get out of sync.
And no JS is required.
You may be thinking of cookies, where the data may be out of date on a
computer until the browser is refreshed.
I was thinking of onRefresh, but have to admit I've not a clue what I
would/could do with it as I haven't yet looked at this event. Something I
should have thought more about before writing ;)
That's javascript, which is client-side. We're talking PHP - server side.
Yes, javascript can get out of sync, especially if you're running
multiple windows.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp. js*******@attglobal.net
================== This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Damien |
last post by:
Hi to all,
I'm currently re-designing our intranet : nice and lean CSS2, cleaned-up
PHP 4.3.7, better-normalized MySQL ;o). So I've started using the
$_SESSION variable instead of register_globals...
|
by: Al Jones |
last post by:
This is a repost form the vbscript newgroup - if this isn't the appropriate
group would you point me toward one that is.
Basically, I seem to be losing session data part way though preparing an...
|
by: Abhilash.k.m |
last post by:
This is regarding the session management using Out of
proc session management(SQL SERVER). Among the samples
below which one is better to set the session?
1. There are 20 session...
|
by: joseph conrad |
last post by:
Hi,
I tried to implement my own session handler in order to keep control on
the process
the drawback I foun it is not creating and storing in my cookie the
PHPSESSID variable anymore.
reading te...
|
by: aroraamit81 |
last post by:
Hi,
I am facing a trouble. I have some Session variables in my code and
somehow my session variables are getting mixed up with other users.
For example User A has access to 10 companies and...
| | |
by: aroraamit81 |
last post by:
Well Guys, Here is a very strange trouble. When more than one users
request tto same page at the same time then our session gets
conflicted.
Moreover I printed my SessionID, strangely but true I...
|
by: Santosh |
last post by:
Dear All
i am writting a code sending mail with attachement.
i am writting code for sending mail in one page and code for attaching
a file in the next page.
aftet attaching a file i am taking...
|
by: lyealain |
last post by:
<%
If Session("username") = "" Then
Response.Redirect("/CLS/Login.asp")
End If
Dim conn
Dim connectstr
Dim db_name, db_username, db_userpassword
Dim db_server
Dim res
|
by: mikeboston |
last post by:
Hi,
I am attempting to use php session variables on a server which is running Red Hat Linux, but the variables don't seem to be getting passed between pages. I have tried the same exact test...
|
by: KidQuin |
last post by:
I am having problems with session value between pages. Happening in both firefox and IE7. I go between page by links so I know it's not header changes.
I use session_start as the first line on the...
|
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,...
| | |
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,...
|
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...
|
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...
|
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: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence...
| |
