Yeah. Should be also able to prefill the user field, if they were logged on when they opened the page containing the form.
So if they post after their login credentials expire, just need the user to enter their password.
Hello,
Additionally, have your clients use Firefox and the Lazarus extension. Lazarus saved my life several times in the past few weeks. Well, not my life, but a few combined hours of work.
So what’s the Opera version of that, Florent? : )
We invoke session_start() on every page, test for a login cookie on every page that processes form data, and ALL form pages POST back to themselves. If the cookie test fails, we save the current URL and POST as session data, re-direct to a login page, and finally return from whence the user came to the saved URL. Each form tests for POST session data and uses that if found; that is, we restore POST from the saved session data, then remove the session data. It seems to work.
Stomme Poes, Opera is intelligent enough to do this by default. It keeps your written text in memory, even if you (accidentally) browse away from the page and come back to it.
Stomme Poes, Opera is intelligent enough to do this by default. It keeps your written text in memory, even if you (accidentally) browse away from the page and come back to it.
Great to hear, so what’s the Safari or Chrome versions of this Lazarus?
My point wasn’t how to do it in Opera, but that we often cannot tell clients to use browser-X with extension-Y except ion rare cases, so I was questioning it. It’s okay to suggest it, but you have to still build for without it (unless this is internal application of course).
I guess my only issue with this is I always redirect after post. It does require a temporary use of the sessions, but in most cases that’s only a fraction of a second until the receiving page has time to grab the data and clear the session. So maybe in this scenario I just need to store data in sessions longer (treating it exactly as I would data with validation errors) until the user logs back in and returns to the page.
Seems simple enough.
I guess my only issue with this is I always redirect after post.
PRG++ I’m a huge fan of keeping working Back buttons : )
Why is that?
Redirecting only when the form is valid preserves the back button and allows you to use purely client side state (eg. no sessions).
I’ve never liked the message asking if I want to resubmit a form, if I hit a back button. It just seems more usable if I redirect to a GET. I try to limit my use of the session, but considering it’s only used for a fraction of a second, I figured it was worth it. I take it you disagree?
I’ve never liked the message asking if I want to resubmit a form, if I hit a back button.
That’s what you get in FF. IE just sits there and says Page Expired.
You won’t get that if you redirect once the form is completed. It goes like this:
Request: GET /form
Response: 200 form with default/blank values
Request: POST /form (invalid/incomplete values)
Response: 200 form with submitted values filled in + error message
Request: POST /form (valid values)
Response: 303 (Location: /done)
Request: GET /done
If the client now presses the back button, there will be no prompt to resubmit.
It should be called Redirect-After-Post-But-Only-Once-The-Form-Is-Valid, rather than just Redirect-After-Post, but that’s a bit long winded.
Right but you would get it if you hit the back button after POSTing an invalid form. I guess I don’t see what’s wrong with some minor session use if it improves the user experience?
You would have to go back and then refresh the page. In that situation I think the intuitive thing to do must be to re-submit the page.
Using the model I described gives a better user experience than relying on sessions, in my opinion. First, there is no session state which means that sessions can’t time out or get hijacked or any of the other common problems with session. It also allows you to have the same form open in different states. Second, it preserves the history of the actions taken by the user. If you submit the form (invalid) and then submit it again (invalid), you can go back to the first state the form was in and resume from there. Or you can browse back in the history and actually see what you did at the different states.
User experience aside, it’s a lot easier to implement and maintain a system which has no server side state.
You don’t necessarily have a problem with the back button if you don’t redirect. This is more an effect of certain http headers being sent(primarily certain cache-control headers). btw, session_start() sends cache-control headers in addition to the potential session cookie header.
So what’s wrong with setting a specific value for cookie_lifetime for the form?
// Leave session active until the browser closes
ini_set('session.cookie_lifetime', 0);
Yes, Cookie and post data are the best option other than session. If you can increase the session time out then it would be more wonderful to manage the data in session. Cookie are not so safe for important as they store on computer.
If the server deletes the session data after 20 minutes (default value), then it doesn’t matter how long the session cookie lasts. You’ll still loose the state.
You’re right, of course (well, almost; default time is actually 24 min :D).
My settings differ from the default values (gc_maxlifetime is set to 24 hrs and gc_divisor is also set to a higher value when using the file system) so I never have had this problem. My point was though that setting the session values would give you a more than acceptable solution, imo, as opposed to more complicated solutions.
Ok, I’m going to try it on my next project.
Out of curiousity, how do you fill forms with data from $_POST? I’ve just been doing an if else for each input field, but that gets tedious 