SitePoint Sponsor

User Tag List

Page 2 of 3 FirstFirst 123 LastLast
Results 26 to 50 of 51
  1. #26
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    You would use the POST data from the request to populate the form, so I don't see any security problem there.
    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.

  2. #27
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    I guess my only issue with this is I always redirect after post.
    PRG++ I'm a huge fan of keeping working Back buttons : )

  3. #28
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    I guess my only issue with this is I always redirect after post.
    Why is that?

    Quote Originally Posted by Stomme poes View Post
    PRG++ I'm a huge fan of keeping working Back buttons : )
    Redirecting only when the form is valid preserves the back button and allows you to use purely client side state (eg. no sessions).

  4. #29
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    Why is that?
    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?

  5. #30
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    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.

  6. #31
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    I've never liked the message asking if I want to resubmit a form, if I hit a back button.
    Quote Originally Posted by Stomme poes View Post
    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:

    Code:
    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.

  7. #32
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    You won't get that if you redirect once the form is completed.
    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?

  8. #33
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    Right but you would get it if you hit the back button after POSTing an invalid form.
    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.

    Quote Originally Posted by allspiritseve View Post
    I guess I don't see what's wrong with some minor session use if it improves the user experience?
    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.

  9. #34
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2008
    Posts
    5,757
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  10. #35
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So what's wrong with setting a specific value for cookie_lifetime for the form?

    Code:
    // Leave session active until the browser closes
    ini_set('session.cookie_lifetime', 0);
    There’s more than one way to skin a cat.

  11. #36
    SitePoint Member
    Join Date
    Nov 2009
    Posts
    16
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  12. #37
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by nacho View Post
    So what's wrong with setting a specific value for cookie_lifetime for the form?

    Code:
    // Leave session active until the browser closes
    ini_set('session.cookie_lifetime', 0);
    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.

  13. #38
    SitePoint Addict
    Join Date
    May 2003
    Location
    The Netherlands
    Posts
    391
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    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 ).

    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.
    There’s more than one way to skin a cat.

  14. #39
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    it's a lot easier to implement and maintain a system which has no server side state.
    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

  15. #40
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

    PHP Code:
    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
    PHP Code:
    <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

  16. #41
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrapnel_N5 View Post
    allspiritseve, You were absolutely right.
    "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.

    Quote Originally Posted by Shrapnel_N5 View Post
    kyberfabrikken, You were wrong. It is usability fault. sessions aren't that scaring. and sessions are required in such cases. for CSRF prevention.
    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.
    Yes, I blog, too.

  17. #42
    SitePoint Wizard Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,283
    Mentioned
    51 Post(s)
    Tagged
    2 Thread(s)
    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.

  18. #43
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    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.

  19. #44
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrapnel_N5 View Post
    kyberfabrikken, You were wrong. It is usability fault.
    sessions aren't that scaring.
    and sessions are required in such cases. for CSRF prevention.
    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...

  20. #45
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    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
    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.

    Quote Originally Posted by Stomme poes View Post
    Surely depends on the application?
    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.

  21. #46
    SitePoint Addict webaddictz's Avatar
    Join Date
    Feb 2006
    Location
    Netherlands
    Posts
    295
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrapnel_N5 View Post
    webaddictz you just messed up xss and csrf.
    csrf being forged using javascript, not image. it is important only for registered users though
    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.

    Quote Originally Posted by Shrapnel_N5 View Post
    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.
    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.

    Quote Originally Posted by Shrapnel_N5 View Post
    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
    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

    Quote Originally Posted by Shrapnel_N5 View Post
    pardon my english. sometimes i go crazy of it because i can't tell what i want.
    That's no problem really, we understand you, you understand us.

    Quote Originally Posted by kyberfabrikken View Post
    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.
    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.
    Yes, I blog, too.

  22. #47
    Non-Member
    Join Date
    Oct 2009
    Posts
    1,852
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by webaddictz View Post
    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.
    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.

  23. #48
    Spirit Coder allspiritseve's Avatar
    Join Date
    Dec 2002
    Location
    Ann Arbor, MI (USA)
    Posts
    648
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken View Post
    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.
    I use PHP for templates. I guess I was wondering what you do personally, though.

  24. #49
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by allspiritseve View Post
    I use PHP for templates. I guess I was wondering what you do personally, though.
    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.

  25. #50
    SitePoint Wizard Ren's Avatar
    Join Date
    Aug 2003
    Location
    UK
    Posts
    1,060
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Shrapnel_N5 View Post
    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.
    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.

    * php.net/hash_hmac for instance.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •