hidden field vs. session

[blackhorse]

So if I want to pass a lot of values from page 1 to page 2. no user input here.

I could set up these values in session in page 1 and then click a link to get to page 2, in page 2 i will first get these session values and then unset these session variables.

I also can just save these values in hidden fields of a form, and then click a link (this link will call for the theform.submit() function and these hidden fields values will be submit to the taget page, page 2.

these values are non sensitive values, so no security concern here.

what limitations, advantages or disadvantages each approach have?

or hidden object and session could be used for the same purposes, no big difference? pass values (no user input) from page 1 to page 2?

Thanks!

[YAOMK]

The use of sessions lets you keep your code cleaner and leaner as you don't have to pass every single value around from page to page when more than 2 pages are used. BTW you don't necessarily have to unset variables stored using the $_SESSION super-global.

[bpat1434]

Well, looking at the very basics there are the "cosmetic" differences where a user will send a POST or GET form on a click. The session is essentially completely transparent to the user.

Now, the hidden form is much easier to hack than a session. It's still possible; however, it's easier to modify the form and pass different values from what was originally there. So in this respect, the session is more secure (although not completely secure).

If you're not worried about things, I'd use sessions as you're guaranteed for it to work on each user with any browser. Using an onsubmit might not work in all browsers (there are older browsers out there 🙁 ). Look at your target audience to get a feel for what they're capable of.

There really isn't a difference between the two in what you want to do. One is just as good as the other. Now, if later you want to add something, or secure it, it's easier to secure a session and add items to a session rather than form. But that's from my experience. Forms are too easy to manipulate. That's not to say never use forms, but I use them sparingly and track users via sessions 😉

[Weedpacket]

The bit I look at is

no user input here.

And ask myself why, if that's the case, I'd want to involve the user.

I also think happen to think that coding around session storage is a lot simpler than writing (and rewriting) forms full of hidden fields and links that run JavaScript functions to submit them, and all of the additional server-side code required to revalidate the submitted data.

[NogDog]

One advantage of hidden form fields is that they will always work regardless of the client-side cookie settings and the server-side session settings. That being said, for most applications I go with using session values, as there is normally a point in the process where sessions are going to be used for something else, anyway, so it is a given that the server and client environments must support sessions.

[bradmasterx]

Sessions are kept more secure were as hidden feild you can use if u have firefox: Tamper Data and to edit session varibles Cookie Editor

[blackhorse]

"Sessions are kept more secure were as hidden feild you can use if u have firefox: Tamper Data and to edit session varibles Cookie Editor"

Only session ID passed between the server and client, right? the session variable values are saved in the server, right?

Firefox will also save the session variables values at the client side? Firefox is better in many aspects, but it is default to remember these password etc. in the form. I don't know if it is a smart design here.

[YAOMK]

Only session ID passed between the server and client, right? the session variable values are saved in the server, right?

Yes

Firefox will also save the session variables values at the client side? Firefox is better in many aspects, but it is default to remember these password etc. in the form. I don't know if it is a smart design here.

This is a feature of the browser, it doesn't affect how you should implement sessions.

[Weedpacket]

blackhorse wrote:

Firefox will also save the session variables values at the client side?

It can't, because the server never sends session variables' values to the client.

[blackhorse]

Weedpacket wrote:

It can't, because the server never sends session variables' values to the client.

Thanks! so firefox or not, you can not edit the session variables. Right? The security concern is someone somehow will get your session id? session id hijack?

[YAOMK]

blackhorse wrote:

Thanks! so firefox or not, you can not edit the session variables. Right? The security concern is someone somehow will get your session id? session id hijack?

You always have to validate user input as this will later become the values you will use and perhaps store in sessions, so inherently sessions could be vulnerable.

Session hijacking doesn't refer to the direct manipulation of the session variables, but instead to the act of stealing the session itself. To prevent session hijacking you could do a number of things such as checking the clients environment by means of using the values stored in the $_SERVER super-global and comparing them to the original values of the client when the session was started. Google session hijacking to gain a broader understanding of the subject.

[bpat1434]

Thanks! so firefox or not, you can not edit the session variables. Right?

Not always true as some sessions will store their information on the users side as cookies. Cookies are text-files with key and value pairs. So there is possibility a user could manipulate the session vars, but once again, if you do your session handling right, it shouldn't be an issue.