Jump to content

Using hidden form fields


SaranacLake

Recommended Posts

Is there anything wrong (or insecure) with using hidden form fields?

I am working on a page where the user can choose one of 4 different subscription options.

The approach I was going to use is to have a separate form for each plan, and when the user chooses one, submit a hidden form value so my script knows which subscription plan to grab out of the database.

Thoughts?

Link to comment
Share on other sites

1 hour ago, ginerjm said:

When the user selects a plan, do you not save that in his "record" for future reference?  Once you do that you can always look it up when he logs in and save it as a session var and not have to 'hide' it on the web page.

You missed what I am doing and the question...

I have a page with 3 boxes side by side like this...

image.png.4f4d5231b1e6e96fc92d9b54fd76a382.png

 

So each plan would be its own form, but I need a way to send in my $_POST some variable/value so my script knows which plan was chosen and then write that in the shopping cart table.

That is the design I want - nothing else.

So back to my OP...

Is there any problem using hidden form values to pay a product_code to my script?

 

Link to comment
Share on other sites

3 minutes ago, SaranacLake said:

You missed what I am doing and the question...

Doesn't seem that way to me.

3 minutes ago, SaranacLake said:

So each plan would be its own form,

Why? You don't need to do that. Managing one form would be simpler than managing three, right?

3 minutes ago, SaranacLake said:

but I need a way to send in my $_POST some variable/value so my script knows which plan was chosen and then write that in the shopping cart table.

<button>s support a name and value, as well as a separate (HTML) caption displayed to the user. Compare that to regular <input type=button>s which support a name and (string) value, however the value is also used as the caption.

3 minutes ago, SaranacLake said:

Is there any problem using hidden form values to pay a product_code to my script?

Other than the general design of what you're doing? Not especially.

Hidden inputs are for when you want to include data in the form but the user isn't supposed to interact with it. It is no more or less secure than any other form field. You still have to validate it in your script like you would everything else.

Link to comment
Share on other sites

12 minutes ago, requinix said:

Why? You don't need to do that. Managing one form would be simpler than managing three, right?

<button>s support a name and value, as well as a separate (HTML) caption displayed to the user. Compare that to regular <input type=button>s which support a name and (string) value, however the value is also used as the caption.

Sounds like < button > is HTML5?

I'm behind the times and just trying to get my website done...

 

12 minutes ago, requinix said:

Other than the general design of what you're doing? Not especially.

Hidden inputs are for when you want to include data in the form but the user isn't supposed to interact with it. It is no more or less secure than any other form field. You still have to validate it in your script like you would everything else.

If using hidden values does NOT pose any security risks, then I think I'd prefer to use that approach since it is more familiar to me.

May seem funny, but I don't want to start changing my approach when I am 90% done.

I can upgrade my approaches when I start on v2.0 next year.

 

 

Link to comment
Share on other sites

8 minutes ago, SaranacLake said:

Sounds like < button > is HTML5?

No, it's from HTML 4. People just didn't really start learning about it until HTML 5 and the push towards semantic markup and better web design.

8 minutes ago, SaranacLake said:

If using hidden values does NOT pose any security risks, then I think I'd prefer to use that approach since it is more familiar to me.

Any additional risks. Besides a developer having a faulty assumption of "well it's hidden from the user so they can't do anything to it".

8 minutes ago, SaranacLake said:

May seem funny, but I don't want to start changing my approach when I am 90% done.

I can upgrade my approaches when I start on v2.0 next year.

"I know it's wrong but we'll do it right next time"... yeah, if I had a nickel every time someone said that to me...

Link to comment
Share on other sites

26 minutes ago, requinix said:

No, it's from HTML 4. People just didn't really start learning about it until HTML 5 and the push towards semantic markup and better web design.

A-ha

 

26 minutes ago, requinix said:

Any additional risks. Besides a developer having a faulty assumption of "well it's hidden from the user so they can't do anything to it".

I always scrub user data before using it, so that isn't an issue.  I just had a fear that the hidden values could be easily altered by a hacker.

 

26 minutes ago, requinix said:

"I know it's wrong but we'll do it right next time"... yeah, if I had a nickel every time someone said that to me...

That's a wrong assertion.

I bet that HTML6 and CSS4 will have some improvements over what is currently available.  Should I wait until they come out?

Using older version of code doesn't necessarily make it "wrong" or "insecure", and "in the real" world, you can't keep perfecting things before you ship them otherwise you never ship anything!

 

 

Link to comment
Share on other sites

1 hour ago, requinix said:

No, it's from HTML 4. People just didn't really start learning about it until HTML 5 and the push towards semantic markup and better web design.

IE didn't handle <button> properly, that's why it wasn't used/taught so much I believe.  Now that the browsers all seem to handle it properly it's more common.  I almost always use <button> now days in my stuff so I can label buttons with an icon + text.

1 hour ago, SaranacLake said:

That's a wrong assertion.

I bet that HTML6 and CSS4 will have some improvements over what is currently available.  Should I wait until they come out?

That's not really related at all to the comment made. The current proper method being hypothetically deprecated in the future is completely different than using the old deprecated method now when a better method exists just because you're not familiar with the newer method.  Especially when that newer method is not complicated to learn.

If you want to use separate forms because it fits your situation better then fine.  Sometimes multiple forms is easier to do.  Just don't dismiss alternatives simply because they are new.  In your situation I'd probably go for a single form and separate buttons.  It's easier and less markup overall. 

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.