Dealing with POST data and expired sessions

PHP
41

keeping POST data in session is good.

allspiritseve, You were absolutely right.

Using the model I described gives a better user experience

kyberfabrikken, You were wrong. It is usability fault.
sessions aren’t that scaring.
and sessions are required in such cases. for CSRF prevention.

Out of curiousity, how do you fill forms with data from $_POST?

Consider template use.
Prepare all data before output.
And then call form with all data ready.

if (/* we got data */) {
  foreach ($row as $k => $v) $row[$k]=htmlspecialchars($v);
} else {
  $fields=array("name","phone","comments");
  foreach ($fields as $v) $row[$v]='';
}
include "form.php";

and then just

<input type="text" name="name" value="<?=$row['name']?>">
<input type="text" name="phone" value="<?=$row['phone']?>">
<input type="text" name="email" value="<?=$row['email']?>">
// etc

There are also monster machines for the form handling, like http://pear.php.net/package/HTML_QuickForm2

42

“you were right”. Great. Bother telling why exactly you think he was right? No offense, but stating someone is right and another person is wrong with no motivation whatsoever is not an addition to the thread, it’s not a poll.

I don’t think so. Well, I agree that sessions really aren’t that scary, but I do like to think that web applications should be as stateless as possible. Nevertheless, your theory that using sessions is a good thing because it counters CSRF is flawed: you can’t send a POST request by using an image, and a GET request should never, ever, change anything on your server side.

43

but I do like to think that web applications should be as stateless as possible

Surely depends on the application? I want state on my shopping cart (but not necessarily all in the same browser… preferably per tab or window) or any multi-step (with the ability to click back to either see what I did (passive) or make one change of all the steps taken (active)) process.

44

webaddictz you just messed up xss and csrf.
csrf being forged using javascript, not image.
it is important only for registered users though

about being right. he’s explained everything. it is usability fault.
user struck with completely confusing message. what to do? send or cancel? no good answer, no good action.

only reason against this technique - the “sessionophobia”.
yes, it can be done both ways. like many other things.
you can do it stateless, all right. but nothing bad in sessions too.
and eliminating this confusing screen is worth using sessions

pardon my english. sometimes i go crazy of it because i can’t tell what i want.

45

Sessions are not scary, but using them has implications on scalability & cache-ability. So in my view should be only used as a last resort, as they are hack on a stateless protocol for lazy developers.

And sessions are not required for CSRF prevention. Will demonstrate shortly…

46

That would depend on the chosen presentation mechanism. If you use a template engine, there’s probably some built-in mechanism for generating form fields, or you can abstract it out to functions or view helpers or whatever it’s called. Straight-up procedural style gets rather verbose, agreed.

As I read webaddicts post, the as possible part covers this. If session state is a feature, then surely it should be there. That’s the case with a shopping cart. If it’s used as an implementation mechanism, then it’s dubious.

47

I don’t think I have. Plus, you can do user identification without storing the POST values in a session, so you’re mixing two different discussions into one.

You wouldn’t get a message by implementing the technique discussed in this thread. The suggestion was merging user-logins with a “normal” edit form, instead of saving the values in a session, redirecting to the login page and upon successful authentication, retry the original posting. Even when writing this, it becomes painfully clear which is harder to implement.

I use sessions. I just don’t use them if the problem at hand does not call for sessions. They are not the solution to everything. I might argue you are a sessionophile :wink:

That’s no problem really, we understand you, you understand us.

Exactly. State can be a requirement of your application, in which case you’d be foolish not to use sessions: that is their reason for existence, after all. Implementing a “remember all of my post values”, however, is not why sessions have been invented.

48

I meant csrf prevention is significant only for registered users. there is no csrf problem for anonymous users. nothing more. nothing to mix.
But yes, you can do it without session, I have to admit. Database can handle it too.
But no, csrf techniques are not limited with one single example from wikipedia article.

You wouldn’t get a message by implementing the technique discussed in this thread

I’d be glad to click on some working demo.

49

I use PHP for templates. I guess I was wondering what you do personally, though.

50

Ah. I’ve worked on a variety of applications and I haven’t necessarily been in full control of the development environment for each. However if I am, I would probably prefer a view helper object, which holds function for generating html form elements. If I’m using a template engine, these helpers would probably end up as some sort of plugin. If we’re talking plan php templates, helpers could be as simple as global php functions. It really depends a lot on the rest of the application.

51

Yes, aslong as have something identifying a user, presumably a cookie, you can combine that with some random data, and use a keyed cryptographic hash function*, to generate a MAC as a token.

Thus any attempt to forge a post cannot reasonably create the token, without knowing the key that is used to generate them.

It can also provide an extra layer of validation for any <input type=“hidden”> values, if also use them to generate the MAC.