Re: [PHP] Good books on sessions
Well, the first thing I recommended was to use $_SESSION rather than
session_register(), since it's the way of the future, and also the only
method i've put any serious time into.
With register globals off, you'll then be able to clearly tell the
difference between the form variable ($_POST['project_id']) and the session
variable ($_SESSION['program_id']) a LOT easier.
Then to change the session var to the value of the posted form, it's dead
easy.
$_SESSION['program_id'] = $_POST['project_id'];
session_register is NOT a simple way of using sessions, and can make it
harder for people to get the results they want, IMHO.
Justin French
on 31/07/02 3:15 AM, Petre ([EMAIL PROTECTED]) wrote:
> Yes , I agree,But that is exactly where my problem comes in, when I link
> the person forward, it DOES NOT take the new value for the project_id,
> as it is a form element and it only becomes variable on the action page.
> This is where I'm unsure about how to "initialize" the variable. As
> mentioned earlier in my posts, I simply do a
> session_register("project_id"); on the action page, I DO NOT say
> anything like
>
> $_SESSION['project_id'] = "45"; or any other form of assignment whatsoever, as
> I leave the work to register_globals=on and it's normal expected behaviour.
> And I think this is where the problem lies.
> It seems I MUST actually do that for things to work??? Unfortunately I cannot
> test this yet, as I'm busy with something else, and just trying to get the
> basic academics right. I understand the way you are explaining sessions 100%,
> but when I put that knowledge to practise, things doesn't seem to work... :( .
> I am still to test yours and Rasmus' sugestions and will come back shortly.
>
> Thanks for the help so far.
>
>
>
>
> Justin French wrote:
>
>> *shakes head a bit*
>>
>> I'm not REALLY sure what the problem is here, but let's take a step back.
>>
>> A session ID is a unique, random number assigned to a user as they kick
>> around your site.
>>
>> To maintain state (a session) across multiple pages, you pass the session id
>> around. This can be done with the URL or cookies. Yes, trans_sid is in
>> there as well, but all it does is re-write URLs.
>>
>> No surprises so far.
>>
>>
>> You then assign variables to the session. If you're using PHP >= 4.1, I'd
>> use $_SESSION['varname'] = "value"; rather than session_register(), because
>> it's a lot more logical, and clearer to think through.
>>
>> Furthermore, the manual tells us NOT to mix use of session_register('var')
>> and $_SESSION['var'] = 'value'... so, pick a method, and stick to it...
>> since the $_SESSION array is the new way, I'd be going with it.
>>
>>
>> So, the first two session vars YOU assign after the user logs in is the
>> username and password (I wouldn't register the password).
>>
>> $_SESSION['username'] = "justin";
>> $_SESSION['password'] = "secret";
>>
>>
>> Then a few pages later, they pick an option from a pull-down list, and you
>> assign another variable to the session:
>>
>> $_SESSION['project_id'] = "45";
>>
>> The user clicks through a few more pages, and later wants to work on a
>> different project, so you link them through (forward) to the options page.
>>
>> They select a new project from the pull down, so you need to overwrite the
>> old project_id session var with a new one:
>>
>> $_SESSION['project_id'] = "74";
>>
>>
>> Now, when they kick around through pages, they will be doing it under
>> project_id 74.
>>
>> If you wanted to delete the project_id all together (no project), you could
>> use unset().
>>
>>
>> Now, go back, and have a look at your code, check out the logic, and I'm
>> sure you'll see the mistake(s).
>>
>>
>> As far as the "maintaining session forever" thing, I'd highly recommend
>> it... it's highly insecure (walk away from your computer, someone else has
>> access to everything)... besides, sessions are a temporary thing by nature,
>> with garbage cleanouts, etc etc.
>>
>> If you really wanted to maintain state 'forever', you would have to set a
>> cookie with the username and password to that person's computer, hence your
>> website would 'remember them' all the time.
>>
>> Of course there are plenty of reasons why your shouldn't do this. I guess
>> the client should be informed of the options here:
>>
>> 1. log in every so-often as needed (if there is lots of activity, the
>> session probably won't die all day anyway), and have heaps more security
>>
>> 2. log in once only, and have the whole system wide-open forever
>>
>>
>> I'd pick 1 over 2 anytime.
>>
>> I'd also provide a logout button with either system, so that people CHOOSE
>> TO DESTROY THEIR SESSION. Personally, I log-out when I leave my desk, just
>> in case.
>>
>> Imagine if you left a session open which disclosed everyone's pay rates in
>> an office... not good for your career at all :)
>>
>>
>> Hope this all helps,
>>
>> Justin French
>>
>>
>>
>>
>> on 30/07/02 6:
Re: [PHP] Good books on sessions
Hi Rasmus
Thanks, I think I got it now.
Seems my problem with understanding was with the actual setting of the
variables.
The logic dictated that the session variables should stay the same
throughout the session unless "changed" via a form selection, so I
simply added a
session_register("session_var");
if ($_POST["my_var"]) {
$session_var = $_POST["my_var"];
}
to my code and it works like a charm as the $_POST var will be empty if
it comes from one of my "back" links to the page...
Rasmus Lerdorf wrote:
>Yup, get rid of both ini_set() calls and take out the $sid=...
>and stuff and it should simply work.
>
>On Tue, 30 Jul 2002, Petre wrote:
>
>>Thanks, will work through this immediately.
>>Just to be clear.
>>If I DO stick with your suggestion of letting PHP do the url mangling,
>>and taking your code below, I can simply remove the
>>
>>ini_set('session.use_trans_sid',false); and from your code to make it work
>exactly as is?
>>
>>Thanks
>>
>>
>>
>>Rasmus Lerdorf wrote:
>>
>>>The trick is to not name your form vars the same as your session vars.
>>>Keep them separate so you have full control of what ends up where. Also,
>>>note that if you are not relying on trans_sid or cookies then don't use
>>>SID. Call session_id() explicitly to get the session id. So, a quick
>>>little mockup to illustrate this.
>>>
>>>login.php:
>ini_set('session.use_cookies',false);
>>>ini_set('session.use_trans_sid',false);
>>>session_start();
>>>$sid = session_name().'='.session_id();
>>>session_register('username');
>>>$username = 'petre';
>>>?>
>>>Next Page
>>>
>>>page1.php:
>ini_set('session.use_cookies',false);
>>>ini_set('session.use_trans_sid',false);
>>>session_start();
>>>$sid = session_name().'='.session_id();
>>>?>
>>>
>>>
>>>
>>>
>>>page2.php:
>ini_set('session.use_cookies',false);
>>>ini_set('session.use_trans_sid',false);
>>>session_start();
>>>$sid = session_name().'='.session_id();
>>>session_register('foo');
>>>$foo = $_POST['form_foo'];
>>>echo "You entered $foo\n";
>>>?>
>>>Back
>>>
>>>
>>>I am ini_setting on each page to force PHP to not do trans-sid/cookies.
>>>Would be easier to simply turn these off in the php.ini file.
>>>
>>>When you hit the back link, $_SESSION['foo'] will exist on page1.php and
>>>the form will get filled in with the previous value. You can then change
>>>it, hit enter again and the session value will take on the new submitted
>>>value because I have decoupled the form data from the session data and I
>>>set the session var in page2.php.
>>>
>>>There are other ways to do this, but this is probably the easiest method
>>>to understand. Play with this simple example until you understand how it
>>>works.
>>>
>>>But again, I'd suggest letting PHP do session id handling for you by
>>>letting it default to cookies and fall back to url mangling in the few
>>>cases where cookies are turned off.
>>>
>>>-Rasmus
>>>
>>>On Tue, 30 Jul 2002, Petre wrote:
>>>
Yes, it is a forward link to the page, but as mentioned, that page
contains a form with the selection options, and on that form's action
page is where I don't see the values change, so the question should
probably be something like "how do I change the value in the session_var
with the newly selected value?
And oh, I almost forgot:
Due to that fact that this type of app doesn't really have a logical end
page, I cannot issue a session_destroy() anywhere logically ( except
using a logout button), but that's not going to ensure that people use it...
I would ideally like to have this "app" run on an intranet, where people
will most probably have this app open indefinately, and thus I also
battle with my logic of keeping a session alive.
Thanks
.
Rasmus Lerdorf wrote:
>Well, how exactly do you implement the back button? If it is a normal
>client-side back, then of course the previous value will be shown. If it
>is actually a forward-link to the previous page, then your logic on that
>target page is bogus.
>
>By the way, trans-sid is compiled in by default in PHP so should always be
>available. And it will fallback to sid mangling only if cookies are
>disabled. You would probably be better off just letting php manage this
>for you.
>
>-Rasmus
>
>On Tue, 30 Jul 2002, Petre wrote:
>
>>Well, I have asked a couple of questions on this list, but they havn't
>>really helped alot. Maybe you can help?
>>
>>My situation background is as follow:
>>I have always written my apps in the following way: register_globals=on,
>>so I allowed PHP to "generate" my variables for me on the action page,
>>and if I cannot use a form to "send" variables to the next pages, I
>>added them manually to the url.
>>So, then I discovered sessions and thought my probelms were solved, only
>>to discover that it uses cookies by default, and has to have the
>>--trans-sid option co
Re: [PHP] Good books on sessions
Yes , I agree,But that is exactly where my problem comes in, when I link
the person forward, it DOES NOT take the new value for the project_id,
as it is a form element and it only becomes variable on the action page.
This is where I'm unsure about how to "initialize" the variable. As
mentioned earlier in my posts, I simply do a
session_register("project_id"); on the action page, I DO NOT say
anything like
$_SESSION['project_id'] = "45"; or any other form of assignment whatsoever, as I leave
the work to register_globals=on and it's normal expected behaviour. And I think this
is where the problem lies.
It seems I MUST actually do that for things to work??? Unfortunately I cannot test
this yet, as I'm busy with something else, and just trying to get the basic academics
right. I understand the way you are explaining sessions 100%, but when I put that
knowledge to practise, things doesn't seem to work... :( .
I am still to test yours and Rasmus' sugestions and will come back shortly.
Thanks for the help so far.
Justin French wrote:
>*shakes head a bit*
>
>I'm not REALLY sure what the problem is here, but let's take a step back.
>
>A session ID is a unique, random number assigned to a user as they kick
>around your site.
>
>To maintain state (a session) across multiple pages, you pass the session id
>around. This can be done with the URL or cookies. Yes, trans_sid is in
>there as well, but all it does is re-write URLs.
>
>No surprises so far.
>
>
>You then assign variables to the session. If you're using PHP >= 4.1, I'd
>use $_SESSION['varname'] = "value"; rather than session_register(), because
>it's a lot more logical, and clearer to think through.
>
>Furthermore, the manual tells us NOT to mix use of session_register('var')
>and $_SESSION['var'] = 'value'... so, pick a method, and stick to it...
>since the $_SESSION array is the new way, I'd be going with it.
>
>
>So, the first two session vars YOU assign after the user logs in is the
>username and password (I wouldn't register the password).
>
>$_SESSION['username'] = "justin";
>$_SESSION['password'] = "secret";
>
>
>Then a few pages later, they pick an option from a pull-down list, and you
>assign another variable to the session:
>
>$_SESSION['project_id'] = "45";
>
>The user clicks through a few more pages, and later wants to work on a
>different project, so you link them through (forward) to the options page.
>
>They select a new project from the pull down, so you need to overwrite the
>old project_id session var with a new one:
>
>$_SESSION['project_id'] = "74";
>
>
>Now, when they kick around through pages, they will be doing it under
>project_id 74.
>
>If you wanted to delete the project_id all together (no project), you could
>use unset().
>
>
>Now, go back, and have a look at your code, check out the logic, and I'm
>sure you'll see the mistake(s).
>
>
>As far as the "maintaining session forever" thing, I'd highly recommend
>it... it's highly insecure (walk away from your computer, someone else has
>access to everything)... besides, sessions are a temporary thing by nature,
>with garbage cleanouts, etc etc.
>
>If you really wanted to maintain state 'forever', you would have to set a
>cookie with the username and password to that person's computer, hence your
>website would 'remember them' all the time.
>
>Of course there are plenty of reasons why your shouldn't do this. I guess
>the client should be informed of the options here:
>
>1. log in every so-often as needed (if there is lots of activity, the
>session probably won't die all day anyway), and have heaps more security
>
>2. log in once only, and have the whole system wide-open forever
>
>
>I'd pick 1 over 2 anytime.
>
>I'd also provide a logout button with either system, so that people CHOOSE
>TO DESTROY THEIR SESSION. Personally, I log-out when I leave my desk, just
>in case.
>
>Imagine if you left a session open which disclosed everyone's pay rates in
>an office... not good for your career at all :)
>
>
>Hope this all helps,
>
>Justin French
>
>
>
>
>on 30/07/02 6:04 PM, Petre ([EMAIL PROTECTED]) wrote:
>
>>Yes, it is a forward link to the page, but as mentioned, that page
>>contains a form with the selection options, and on that form's action
>>page is where I don't see the values change, so the question should
>>probably be something like "how do I change the value in the session_var
>>with the newly selected value?
>>And oh, I almost forgot:
>>Due to that fact that this type of app doesn't really have a logical end
>>page, I cannot issue a session_destroy() anywhere logically ( except
>>using a logout button), but that's not going to ensure that people use it...
>>I would ideally like to have this "app" run on an intranet, where people
>>will most probably have this app open indefinately, and thus I also
>>battle with my logic of keeping a session alive.
>>
>>Thanks
>>.
>>
>>Rasmus Lerdorf wrote:
>>
>>>Well, how exactly do you implement the back button? If it is a
Re: [PHP] Good books on sessions
*shakes head a bit*
I'm not REALLY sure what the problem is here, but let's take a step back.
A session ID is a unique, random number assigned to a user as they kick
around your site.
To maintain state (a session) across multiple pages, you pass the session id
around. This can be done with the URL or cookies. Yes, trans_sid is in
there as well, but all it does is re-write URLs.
No surprises so far.
You then assign variables to the session. If you're using PHP >= 4.1, I'd
use $_SESSION['varname'] = "value"; rather than session_register(), because
it's a lot more logical, and clearer to think through.
Furthermore, the manual tells us NOT to mix use of session_register('var')
and $_SESSION['var'] = 'value'... so, pick a method, and stick to it...
since the $_SESSION array is the new way, I'd be going with it.
So, the first two session vars YOU assign after the user logs in is the
username and password (I wouldn't register the password).
$_SESSION['username'] = "justin";
$_SESSION['password'] = "secret";
Then a few pages later, they pick an option from a pull-down list, and you
assign another variable to the session:
$_SESSION['project_id'] = "45";
The user clicks through a few more pages, and later wants to work on a
different project, so you link them through (forward) to the options page.
They select a new project from the pull down, so you need to overwrite the
old project_id session var with a new one:
$_SESSION['project_id'] = "74";
Now, when they kick around through pages, they will be doing it under
project_id 74.
If you wanted to delete the project_id all together (no project), you could
use unset().
Now, go back, and have a look at your code, check out the logic, and I'm
sure you'll see the mistake(s).
As far as the "maintaining session forever" thing, I'd highly recommend
it... it's highly insecure (walk away from your computer, someone else has
access to everything)... besides, sessions are a temporary thing by nature,
with garbage cleanouts, etc etc.
If you really wanted to maintain state 'forever', you would have to set a
cookie with the username and password to that person's computer, hence your
website would 'remember them' all the time.
Of course there are plenty of reasons why your shouldn't do this. I guess
the client should be informed of the options here:
1. log in every so-often as needed (if there is lots of activity, the
session probably won't die all day anyway), and have heaps more security
2. log in once only, and have the whole system wide-open forever
I'd pick 1 over 2 anytime.
I'd also provide a logout button with either system, so that people CHOOSE
TO DESTROY THEIR SESSION. Personally, I log-out when I leave my desk, just
in case.
Imagine if you left a session open which disclosed everyone's pay rates in
an office... not good for your career at all :)
Hope this all helps,
Justin French
on 30/07/02 6:04 PM, Petre ([EMAIL PROTECTED]) wrote:
> Yes, it is a forward link to the page, but as mentioned, that page
> contains a form with the selection options, and on that form's action
> page is where I don't see the values change, so the question should
> probably be something like "how do I change the value in the session_var
> with the newly selected value?
> And oh, I almost forgot:
> Due to that fact that this type of app doesn't really have a logical end
> page, I cannot issue a session_destroy() anywhere logically ( except
> using a logout button), but that's not going to ensure that people use it...
> I would ideally like to have this "app" run on an intranet, where people
> will most probably have this app open indefinately, and thus I also
> battle with my logic of keeping a session alive.
>
> Thanks
> .
>
> Rasmus Lerdorf wrote:
>
>> Well, how exactly do you implement the back button? If it is a normal
>> client-side back, then of course the previous value will be shown. If it
>> is actually a forward-link to the previous page, then your logic on that
>> target page is bogus.
>>
>> By the way, trans-sid is compiled in by default in PHP so should always be
>> available. And it will fallback to sid mangling only if cookies are
>> disabled. You would probably be better off just letting php manage this
>> for you.
>>
>> -Rasmus
>>
>> On Tue, 30 Jul 2002, Petre wrote:
>>
>>> Well, I have asked a couple of questions on this list, but they havn't
>>> really helped alot. Maybe you can help?
>>>
>>> My situation background is as follow:
>>> I have always written my apps in the following way: register_globals=on,
>>> so I allowed PHP to "generate" my variables for me on the action page,
>>> and if I cannot use a form to "send" variables to the next pages, I
>>> added them manually to the url.
>>> So, then I discovered sessions and thought my probelms were solved, only
>>> to discover that it uses cookies by default, and has to have the
>>> --trans-sid option compiled to have PHP handle the app if you don't want
>>> cookies ( like
Re: [PHP] Good books on sessions
Yup, get rid of both ini_set() calls and take out the $sid=...
and stuff and it should simply work.
On Tue, 30 Jul 2002, Petre wrote:
> Thanks, will work through this immediately.
> Just to be clear.
> If I DO stick with your suggestion of letting PHP do the url mangling,
> and taking your code below, I can simply remove the
>
> ini_set('session.use_trans_sid',false); and from your code to make it work
>exactly as is?
>
> Thanks
>
>
>
> Rasmus Lerdorf wrote:
>
> >The trick is to not name your form vars the same as your session vars.
> >Keep them separate so you have full control of what ends up where. Also,
> >note that if you are not relying on trans_sid or cookies then don't use
> >SID. Call session_id() explicitly to get the session id. So, a quick
> >little mockup to illustrate this.
> >
> >login.php:
> > >ini_set('session.use_cookies',false);
> >ini_set('session.use_trans_sid',false);
> >session_start();
> >$sid = session_name().'='.session_id();
> >session_register('username');
> >$username = 'petre';
> >?>
> >Next Page
> >
> >page1.php:
> > >ini_set('session.use_cookies',false);
> >ini_set('session.use_trans_sid',false);
> >session_start();
> >$sid = session_name().'='.session_id();
> >?>
> >
> >
> >
> >
> >page2.php:
> > >ini_set('session.use_cookies',false);
> >ini_set('session.use_trans_sid',false);
> >session_start();
> >$sid = session_name().'='.session_id();
> >session_register('foo');
> >$foo = $_POST['form_foo'];
> >echo "You entered $foo\n";
> >?>
> >Back
> >
> >
> >I am ini_setting on each page to force PHP to not do trans-sid/cookies.
> >Would be easier to simply turn these off in the php.ini file.
> >
> >When you hit the back link, $_SESSION['foo'] will exist on page1.php and
> >the form will get filled in with the previous value. You can then change
> >it, hit enter again and the session value will take on the new submitted
> >value because I have decoupled the form data from the session data and I
> >set the session var in page2.php.
> >
> >There are other ways to do this, but this is probably the easiest method
> >to understand. Play with this simple example until you understand how it
> >works.
> >
> >But again, I'd suggest letting PHP do session id handling for you by
> >letting it default to cookies and fall back to url mangling in the few
> >cases where cookies are turned off.
> >
> >-Rasmus
> >
> >On Tue, 30 Jul 2002, Petre wrote:
> >
> >>Yes, it is a forward link to the page, but as mentioned, that page
> >>contains a form with the selection options, and on that form's action
> >>page is where I don't see the values change, so the question should
> >>probably be something like "how do I change the value in the session_var
> >>with the newly selected value?
> >>And oh, I almost forgot:
> >>Due to that fact that this type of app doesn't really have a logical end
> >>page, I cannot issue a session_destroy() anywhere logically ( except
> >>using a logout button), but that's not going to ensure that people use it...
> >>I would ideally like to have this "app" run on an intranet, where people
> >>will most probably have this app open indefinately, and thus I also
> >>battle with my logic of keeping a session alive.
> >>
> >>Thanks
> >>.
> >>
> >>Rasmus Lerdorf wrote:
> >>
> >>>Well, how exactly do you implement the back button? If it is a normal
> >>>client-side back, then of course the previous value will be shown. If it
> >>>is actually a forward-link to the previous page, then your logic on that
> >>>target page is bogus.
> >>>
> >>>By the way, trans-sid is compiled in by default in PHP so should always be
> >>>available. And it will fallback to sid mangling only if cookies are
> >>>disabled. You would probably be better off just letting php manage this
> >>>for you.
> >>>
> >>>-Rasmus
> >>>
> >>>On Tue, 30 Jul 2002, Petre wrote:
> >>>
> Well, I have asked a couple of questions on this list, but they havn't
> really helped alot. Maybe you can help?
>
> My situation background is as follow:
> I have always written my apps in the following way: register_globals=on,
> so I allowed PHP to "generate" my variables for me on the action page,
> and if I cannot use a form to "send" variables to the next pages, I
> added them manually to the url.
> So, then I discovered sessions and thought my probelms were solved, only
> to discover that it uses cookies by default, and has to have the
> --trans-sid option compiled to have PHP handle the app if you don't want
> cookies ( like me, don't want cookies at all, or for that matter,
> anything that relies on the client's side). So, I couldn't just jump in
> and use sessions as I would not be sure that my app would work on any
> PHP4 system regardless of the options it was compiled with. ( Oh, I am
> writing my apps to work with register_globals=off now, so that shouldn't
> be a problem).
> So I started to look for a way to code with sessions that will not
> >>>
Re: [PHP] Good books on sessions
Thanks, will work through this immediately.
Just to be clear.
If I DO stick with your suggestion of letting PHP do the url mangling,
and taking your code below, I can simply remove the
ini_set('session.use_trans_sid',false); and from your code to make it work
exactly as is?
Thanks
Rasmus Lerdorf wrote:
>The trick is to not name your form vars the same as your session vars.
>Keep them separate so you have full control of what ends up where. Also,
>note that if you are not relying on trans_sid or cookies then don't use
>SID. Call session_id() explicitly to get the session id. So, a quick
>little mockup to illustrate this.
>
>login.php:
>ini_set('session.use_cookies',false);
>ini_set('session.use_trans_sid',false);
>session_start();
>$sid = session_name().'='.session_id();
>session_register('username');
>$username = 'petre';
>?>
>Next Page
>
>page1.php:
>ini_set('session.use_cookies',false);
>ini_set('session.use_trans_sid',false);
>session_start();
>$sid = session_name().'='.session_id();
>?>
>
>
>
>
>page2.php:
>ini_set('session.use_cookies',false);
>ini_set('session.use_trans_sid',false);
>session_start();
>$sid = session_name().'='.session_id();
>session_register('foo');
>$foo = $_POST['form_foo'];
>echo "You entered $foo\n";
>?>
>Back
>
>
>I am ini_setting on each page to force PHP to not do trans-sid/cookies.
>Would be easier to simply turn these off in the php.ini file.
>
>When you hit the back link, $_SESSION['foo'] will exist on page1.php and
>the form will get filled in with the previous value. You can then change
>it, hit enter again and the session value will take on the new submitted
>value because I have decoupled the form data from the session data and I
>set the session var in page2.php.
>
>There are other ways to do this, but this is probably the easiest method
>to understand. Play with this simple example until you understand how it
>works.
>
>But again, I'd suggest letting PHP do session id handling for you by
>letting it default to cookies and fall back to url mangling in the few
>cases where cookies are turned off.
>
>-Rasmus
>
>On Tue, 30 Jul 2002, Petre wrote:
>
>>Yes, it is a forward link to the page, but as mentioned, that page
>>contains a form with the selection options, and on that form's action
>>page is where I don't see the values change, so the question should
>>probably be something like "how do I change the value in the session_var
>>with the newly selected value?
>>And oh, I almost forgot:
>>Due to that fact that this type of app doesn't really have a logical end
>>page, I cannot issue a session_destroy() anywhere logically ( except
>>using a logout button), but that's not going to ensure that people use it...
>>I would ideally like to have this "app" run on an intranet, where people
>>will most probably have this app open indefinately, and thus I also
>>battle with my logic of keeping a session alive.
>>
>>Thanks
>>.
>>
>>Rasmus Lerdorf wrote:
>>
>>>Well, how exactly do you implement the back button? If it is a normal
>>>client-side back, then of course the previous value will be shown. If it
>>>is actually a forward-link to the previous page, then your logic on that
>>>target page is bogus.
>>>
>>>By the way, trans-sid is compiled in by default in PHP so should always be
>>>available. And it will fallback to sid mangling only if cookies are
>>>disabled. You would probably be better off just letting php manage this
>>>for you.
>>>
>>>-Rasmus
>>>
>>>On Tue, 30 Jul 2002, Petre wrote:
>>>
Well, I have asked a couple of questions on this list, but they havn't
really helped alot. Maybe you can help?
My situation background is as follow:
I have always written my apps in the following way: register_globals=on,
so I allowed PHP to "generate" my variables for me on the action page,
and if I cannot use a form to "send" variables to the next pages, I
added them manually to the url.
So, then I discovered sessions and thought my probelms were solved, only
to discover that it uses cookies by default, and has to have the
--trans-sid option compiled to have PHP handle the app if you don't want
cookies ( like me, don't want cookies at all, or for that matter,
anything that relies on the client's side). So, I couldn't just jump in
and use sessions as I would not be sure that my app would work on any
PHP4 system regardless of the options it was compiled with. ( Oh, I am
writing my apps to work with register_globals=off now, so that shouldn't
be a problem).
So I started to look for a way to code with sessions that will not
require cookies nor require any special compile features; the answer
came in adding to all relative URL's in my app.
Alas, that is where I'm at, and it's still not working as I would have
expected.
My problem is with the way my proposed app works/should work.
I am trying to write an app that allows the user to log in, then
add/remove projects to his
Re: [PHP] Good books on sessions
The trick is to not name your form vars the same as your session vars.
Keep them separate so you have full control of what ends up where. Also,
note that if you are not relying on trans_sid or cookies then don't use
SID. Call session_id() explicitly to get the session id. So, a quick
little mockup to illustrate this.
login.php:
Next Page
page1.php:
page2.php:
\n";
?>
Back
I am ini_setting on each page to force PHP to not do trans-sid/cookies.
Would be easier to simply turn these off in the php.ini file.
When you hit the back link, $_SESSION['foo'] will exist on page1.php and
the form will get filled in with the previous value. You can then change
it, hit enter again and the session value will take on the new submitted
value because I have decoupled the form data from the session data and I
set the session var in page2.php.
There are other ways to do this, but this is probably the easiest method
to understand. Play with this simple example until you understand how it
works.
But again, I'd suggest letting PHP do session id handling for you by
letting it default to cookies and fall back to url mangling in the few
cases where cookies are turned off.
-Rasmus
On Tue, 30 Jul 2002, Petre wrote:
> Yes, it is a forward link to the page, but as mentioned, that page
> contains a form with the selection options, and on that form's action
> page is where I don't see the values change, so the question should
> probably be something like "how do I change the value in the session_var
> with the newly selected value?
> And oh, I almost forgot:
> Due to that fact that this type of app doesn't really have a logical end
> page, I cannot issue a session_destroy() anywhere logically ( except
> using a logout button), but that's not going to ensure that people use it...
> I would ideally like to have this "app" run on an intranet, where people
> will most probably have this app open indefinately, and thus I also
> battle with my logic of keeping a session alive.
>
> Thanks
> .
>
> Rasmus Lerdorf wrote:
>
> >Well, how exactly do you implement the back button? If it is a normal
> >client-side back, then of course the previous value will be shown. If it
> >is actually a forward-link to the previous page, then your logic on that
> >target page is bogus.
> >
> >By the way, trans-sid is compiled in by default in PHP so should always be
> >available. And it will fallback to sid mangling only if cookies are
> >disabled. You would probably be better off just letting php manage this
> >for you.
> >
> >-Rasmus
> >
> >On Tue, 30 Jul 2002, Petre wrote:
> >
> >>Well, I have asked a couple of questions on this list, but they havn't
> >>really helped alot. Maybe you can help?
> >>
> >>My situation background is as follow:
> >>I have always written my apps in the following way: register_globals=on,
> >>so I allowed PHP to "generate" my variables for me on the action page,
> >>and if I cannot use a form to "send" variables to the next pages, I
> >>added them manually to the url.
> >>So, then I discovered sessions and thought my probelms were solved, only
> >>to discover that it uses cookies by default, and has to have the
> >>--trans-sid option compiled to have PHP handle the app if you don't want
> >>cookies ( like me, don't want cookies at all, or for that matter,
> >>anything that relies on the client's side). So, I couldn't just jump in
> >>and use sessions as I would not be sure that my app would work on any
> >>PHP4 system regardless of the options it was compiled with. ( Oh, I am
> >>writing my apps to work with register_globals=off now, so that shouldn't
> >>be a problem).
> >>So I started to look for a way to code with sessions that will not
> >>require cookies nor require any special compile features; the answer
> >>came in adding to all relative URL's in my app.
> >>Alas, that is where I'm at, and it's still not working as I would have
> >>expected.
> >>My problem is with the way my proposed app works/should work.
> >>
> >>I am trying to write an app that allows the user to log in, then
> >>add/remove projects to his list, then, when a project is selected, he
> >>should have access to all the relevan documents in that project, again
> >>allowing him to add/remove documents from the project here, and in the
> >>last step, when a document is selected, allows hime to add/remove/edit
> >>chapters to the document.
> >>
> >>My first attempt at using sessions with this failed miserably ( keeping
> >>in mind my approach of adding SID at end of urls). I have a "back" link
> >>on all the pages that takes the user to the previous step(s) and thus
> >>on the last page ( the chpaters edit/remove/add page), there is a link
> >>to go back one level, two and three levels. Yet, using these causes
> >>unexpected results.
> >>I think the problem comes in with overriding the value of the session
> >>variable.
> >>For instance, on the first page you have a login form, on the action
> >>page I session_register("username","passwor
Re: [PHP] Good books on sessions
Yes, it is a forward link to the page, but as mentioned, that page
contains a form with the selection options, and on that form's action
page is where I don't see the values change, so the question should
probably be something like "how do I change the value in the session_var
with the newly selected value?
And oh, I almost forgot:
Due to that fact that this type of app doesn't really have a logical end
page, I cannot issue a session_destroy() anywhere logically ( except
using a logout button), but that's not going to ensure that people use it...
I would ideally like to have this "app" run on an intranet, where people
will most probably have this app open indefinately, and thus I also
battle with my logic of keeping a session alive.
Thanks
.
Rasmus Lerdorf wrote:
>Well, how exactly do you implement the back button? If it is a normal
>client-side back, then of course the previous value will be shown. If it
>is actually a forward-link to the previous page, then your logic on that
>target page is bogus.
>
>By the way, trans-sid is compiled in by default in PHP so should always be
>available. And it will fallback to sid mangling only if cookies are
>disabled. You would probably be better off just letting php manage this
>for you.
>
>-Rasmus
>
>On Tue, 30 Jul 2002, Petre wrote:
>
>>Well, I have asked a couple of questions on this list, but they havn't
>>really helped alot. Maybe you can help?
>>
>>My situation background is as follow:
>>I have always written my apps in the following way: register_globals=on,
>>so I allowed PHP to "generate" my variables for me on the action page,
>>and if I cannot use a form to "send" variables to the next pages, I
>>added them manually to the url.
>>So, then I discovered sessions and thought my probelms were solved, only
>>to discover that it uses cookies by default, and has to have the
>>--trans-sid option compiled to have PHP handle the app if you don't want
>>cookies ( like me, don't want cookies at all, or for that matter,
>>anything that relies on the client's side). So, I couldn't just jump in
>>and use sessions as I would not be sure that my app would work on any
>>PHP4 system regardless of the options it was compiled with. ( Oh, I am
>>writing my apps to work with register_globals=off now, so that shouldn't
>>be a problem).
>>So I started to look for a way to code with sessions that will not
>>require cookies nor require any special compile features; the answer
>>came in adding to all relative URL's in my app.
>>Alas, that is where I'm at, and it's still not working as I would have
>>expected.
>>My problem is with the way my proposed app works/should work.
>>
>>I am trying to write an app that allows the user to log in, then
>>add/remove projects to his list, then, when a project is selected, he
>>should have access to all the relevan documents in that project, again
>>allowing him to add/remove documents from the project here, and in the
>>last step, when a document is selected, allows hime to add/remove/edit
>>chapters to the document.
>>
>>My first attempt at using sessions with this failed miserably ( keeping
>>in mind my approach of adding SID at end of urls). I have a "back" link
>>on all the pages that takes the user to the previous step(s) and thus
>>on the last page ( the chpaters edit/remove/add page), there is a link
>>to go back one level, two and three levels. Yet, using these causes
>>unexpected results.
>>I think the problem comes in with overriding the value of the session
>>variable.
>>For instance, on the first page you have a login form, on the action
>>page I session_register("username","password"), and that works fine even
>>when using the back buttons as the values are never changed. But, on the
>>2nd page I have the drop down select containing all the project names (
>>gets built with a while that reads all the project names from the
>>project_table) and send over the project_id.
>>On that actio page, I session_register("project_id"); and it also works
>>fine for all pages "down stream", however, when I come back to that page
>>to select a new project, it keeps the old variable...
>>At first I did nothing special in the sence of assigning a value to the
>>session variables, as I let the register_globals=on do it's trick, but
>>later I explicitly said
>>$project_id = $HTTP_POST_VARS["project_id"];
>>
>>But that also did not overwrite the value of the session var. In the end
>>I was forced to again add all my variables to the end of the url,
>>keeping the session solely for the username and password.
>>
>>I don't know if you would like me to post my code ( it is quite a bit
>>already ) but I would really appreciate it if someone could look at it,
>>and then point out where I'm missing the picture, as then I would have
>>two pictures that I can compare and see where my reasoning failed.
>>
>>Thanks for your time.
>>
>>
>>Rasmus Lerdorf wrote:
>>
>>>What issues? Just ask.
>>>
>>>-Rasmus
>>>
>>>On Mon, 29 Jul 2002, Petre wrote:
>
Re: [PHP] Good books on sessions
Well, how exactly do you implement the back button? If it is a normal
client-side back, then of course the previous value will be shown. If it
is actually a forward-link to the previous page, then your logic on that
target page is bogus.
By the way, trans-sid is compiled in by default in PHP so should always be
available. And it will fallback to sid mangling only if cookies are
disabled. You would probably be better off just letting php manage this
for you.
-Rasmus
On Tue, 30 Jul 2002, Petre wrote:
> Well, I have asked a couple of questions on this list, but they havn't
> really helped alot. Maybe you can help?
>
> My situation background is as follow:
> I have always written my apps in the following way: register_globals=on,
> so I allowed PHP to "generate" my variables for me on the action page,
> and if I cannot use a form to "send" variables to the next pages, I
> added them manually to the url.
> So, then I discovered sessions and thought my probelms were solved, only
> to discover that it uses cookies by default, and has to have the
> --trans-sid option compiled to have PHP handle the app if you don't want
> cookies ( like me, don't want cookies at all, or for that matter,
> anything that relies on the client's side). So, I couldn't just jump in
> and use sessions as I would not be sure that my app would work on any
> PHP4 system regardless of the options it was compiled with. ( Oh, I am
> writing my apps to work with register_globals=off now, so that shouldn't
> be a problem).
> So I started to look for a way to code with sessions that will not
> require cookies nor require any special compile features; the answer
> came in adding to all relative URL's in my app.
> Alas, that is where I'm at, and it's still not working as I would have
> expected.
> My problem is with the way my proposed app works/should work.
>
> I am trying to write an app that allows the user to log in, then
> add/remove projects to his list, then, when a project is selected, he
> should have access to all the relevan documents in that project, again
> allowing him to add/remove documents from the project here, and in the
> last step, when a document is selected, allows hime to add/remove/edit
> chapters to the document.
>
> My first attempt at using sessions with this failed miserably ( keeping
> in mind my approach of adding SID at end of urls). I have a "back" link
> on all the pages that takes the user to the previous step(s) and thus
> on the last page ( the chpaters edit/remove/add page), there is a link
> to go back one level, two and three levels. Yet, using these causes
> unexpected results.
> I think the problem comes in with overriding the value of the session
> variable.
> For instance, on the first page you have a login form, on the action
> page I session_register("username","password"), and that works fine even
> when using the back buttons as the values are never changed. But, on the
> 2nd page I have the drop down select containing all the project names (
> gets built with a while that reads all the project names from the
> project_table) and send over the project_id.
> On that actio page, I session_register("project_id"); and it also works
> fine for all pages "down stream", however, when I come back to that page
> to select a new project, it keeps the old variable...
> At first I did nothing special in the sence of assigning a value to the
> session variables, as I let the register_globals=on do it's trick, but
> later I explicitly said
> $project_id = $HTTP_POST_VARS["project_id"];
>
> But that also did not overwrite the value of the session var. In the end
> I was forced to again add all my variables to the end of the url,
> keeping the session solely for the username and password.
>
> I don't know if you would like me to post my code ( it is quite a bit
> already ) but I would really appreciate it if someone could look at it,
> and then point out where I'm missing the picture, as then I would have
> two pictures that I can compare and see where my reasoning failed.
>
> Thanks for your time.
>
>
> Rasmus Lerdorf wrote:
>
> >What issues? Just ask.
> >
> >-Rasmus
> >
> >On Mon, 29 Jul 2002, Petre wrote:
> >
> >>What are good books/websites about sessions.
> >>I'm looking for more advanced stuff, I have the Luke Welling/Laura
> >>Tompson book, and have read the manual, but I still have issues that are
> >>unresolved.
> >>
> >>Thanks
> >>
> >>
> >>
> >>--
> >>PHP General Mailing List (http://www.php.net/)
> >>To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Good books on sessions
Well, I have asked a couple of questions on this list, but they havn't
really helped alot. Maybe you can help?
My situation background is as follow:
I have always written my apps in the following way: register_globals=on,
so I allowed PHP to "generate" my variables for me on the action page,
and if I cannot use a form to "send" variables to the next pages, I
added them manually to the url.
So, then I discovered sessions and thought my probelms were solved, only
to discover that it uses cookies by default, and has to have the
--trans-sid option compiled to have PHP handle the app if you don't want
cookies ( like me, don't want cookies at all, or for that matter,
anything that relies on the client's side). So, I couldn't just jump in
and use sessions as I would not be sure that my app would work on any
PHP4 system regardless of the options it was compiled with. ( Oh, I am
writing my apps to work with register_globals=off now, so that shouldn't
be a problem).
So I started to look for a way to code with sessions that will not
require cookies nor require any special compile features; the answer
came in adding to all relative URL's in my app.
Alas, that is where I'm at, and it's still not working as I would have
expected.
My problem is with the way my proposed app works/should work.
I am trying to write an app that allows the user to log in, then
add/remove projects to his list, then, when a project is selected, he
should have access to all the relevan documents in that project, again
allowing him to add/remove documents from the project here, and in the
last step, when a document is selected, allows hime to add/remove/edit
chapters to the document.
My first attempt at using sessions with this failed miserably ( keeping
in mind my approach of adding SID at end of urls). I have a "back" link
on all the pages that takes the user to the previous step(s) and thus
on the last page ( the chpaters edit/remove/add page), there is a link
to go back one level, two and three levels. Yet, using these causes
unexpected results.
I think the problem comes in with overriding the value of the session
variable.
For instance, on the first page you have a login form, on the action
page I session_register("username","password"), and that works fine even
when using the back buttons as the values are never changed. But, on the
2nd page I have the drop down select containing all the project names (
gets built with a while that reads all the project names from the
project_table) and send over the project_id.
On that actio page, I session_register("project_id"); and it also works
fine for all pages "down stream", however, when I come back to that page
to select a new project, it keeps the old variable...
At first I did nothing special in the sence of assigning a value to the
session variables, as I let the register_globals=on do it's trick, but
later I explicitly said
$project_id = $HTTP_POST_VARS["project_id"];
But that also did not overwrite the value of the session var. In the end
I was forced to again add all my variables to the end of the url,
keeping the session solely for the username and password.
I don't know if you would like me to post my code ( it is quite a bit
already ) but I would really appreciate it if someone could look at it,
and then point out where I'm missing the picture, as then I would have
two pictures that I can compare and see where my reasoning failed.
Thanks for your time.
Rasmus Lerdorf wrote:
>What issues? Just ask.
>
>-Rasmus
>
>On Mon, 29 Jul 2002, Petre wrote:
>
>>What are good books/websites about sessions.
>>I'm looking for more advanced stuff, I have the Luke Welling/Laura
>>Tompson book, and have read the manual, but I still have issues that are
>>unresolved.
>>
>>Thanks
>>
>>
>>
>>--
>>PHP General Mailing List (http://www.php.net/)
>>To unsubscribe, visit: http://www.php.net/unsub.php
>>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Good books on sessions
What issues? Just ask. -Rasmus On Mon, 29 Jul 2002, Petre wrote: > What are good books/websites about sessions. > I'm looking for more advanced stuff, I have the Luke Welling/Laura > Tompson book, and have read the manual, but I still have issues that are > unresolved. > > Thanks > > > > -- > PHP General Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
