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 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
