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 <?=$sid?> 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'; >?> ><a href="page1.php?<?=$sid?>">Next Page</a> > >page1.php: ><? >ini_set('session.use_cookies',false); >ini_set('session.use_trans_sid',false); >session_start(); >$sid = session_name().'='.session_id(); >?> ><form action="page2.php?<?=$sid?>" method="POST"> ><input type="text" name="form_foo" value="<?=$_SESSION['foo']?>"> ></form> > >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<br />\n"; >?> ><a href="page1.php?<?=$sid?>">Back</a> > > >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 <?=SID?> 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