Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

Re^2: Browser behavior in remembering parameters

by seefurst (Initiate)
on May 08, 2012 at 15:52 UTC ( #969490=note: print w/replies, xml ) Need Help??

in reply to Re: Browser behavior in remembering parameters
in thread Browser behavior in remembering parameters

That's what cookies are for? Why not just store all choices in a cookie and then update the cookie as necessary. That way no matter where they are, their choices are there, their pathways are preserved. You can detect if a browser doesn't take cookies. Also, the links should still be the same if they click back, because, in most cases the page is rendered from a local cache and not from the server.
  • Comment on Re^2: Browser behavior in remembering parameters

Replies are listed 'Best First'.
Re^3: Browser behavior in remembering parameters
by Anonymous Monk on May 08, 2012 at 16:06 UTC
      Thanks a lot for your replies. OK now, here lies the problem. I cant use sessions because I am forbidden to do so due to some reasons. And neither am I too keen on using cookies since there is a chance that some paranoid users may have disabled cookies in their browsers. So that lead me to think that since this involves the click on just one browser back button, would it be safe to go ahead with such an arrangement?

        I think there are two distinct issues here:

        1. Is it safe? In other words, does it prevent a malicious user from changing parameters by editing the URL? No, it doesn't. This may not matter to you; a user changing 'choice=1' to 'choice=2' may be no different from if he'd backed up and switched a checkbox. But if he can change something like 'paid=no' to 'paid=yes', that may be a big problem. It depends on the data you're passing through the URL, and what he could affect by editing it.

        2. Is it likely to break the functionality? Funny stuff happens with the back button and dynamic pages, depending on server and browser cache settings and other things. You really can't control what happens when they back up, whether their browser fills in the fields as they were before, or whether it submits the same form info that created the previous page, etc. So each step in your process has to be able to handle the fact that the browser could send anything (or nothing) any number of times for that particular step.

        Sessions are the way to go, whether your powers-that-be like it or not. If you're concerned that someone will refuse cookies, you can pass a session key in the URL, but still keep your sensitive data on the server end, preventing users from editing the data directly.

        Aaron B.
        Available for small or large Perl jobs; see my home node.

        excuses excuses ... would it be safe to go ahead with such an arrangement?

        No, it wouldn't be safe, though I admit I'm not entirely sure what arrangement you're referring to

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://969490]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (7)
As of 2018-06-23 10:56 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (125 votes). Check out past polls.