3

is it possible to read an attribute from a form element?

I got this:

<input class="number required" min="1250" max="999999999" id="insert_counter1" name="my_counter" value="" type="text">

After submit I can access the value. But is there any way to get to the other attributes like "min" or "max"?

Right now I have a hidden readonly input field named my_counter_min where the "min" attribute is stored. I do not know if that is a work-a-round or if it actually is the only way to do it.

Br. Anders

UPDATED based on answers below:

Thanks for good feedback. As I read the answers there are three good solution with some pros and cons.

  • Store value in input type=hidden. Easy to do, but can be tampered with
  • Use parser. Takes more time to code but original value will be fetched through a new web request. So no tampering
  • Store value in DB. If the form is related to a specific rcord in the DB then storing extra values can make good sence and will not cost a lot of coding effort if other values have to go into and out of the DB allready (just add a value).

I got three different answers for my question. Fastest answer marked correct even though there are more than this one solution.

BR. Anders

Tillebeck
  • 3,493
  • 7
  • 42
  • 63

4 Answers4

4

No. Only the name and value will reach the server, so you will need a workaround (like the one which you described).

karim79
  • 339,989
  • 67
  • 413
  • 406
3

I do not know if that is a work-a-round or if it actually is the only way to do it.

It's the only good way to do it. The form elements' other attributes are not transmitted in the request.

Pekka
  • 442,112
  • 142
  • 972
  • 1,088
3

They are not transmitted, but you could load the page with an HTML parser and extract the values.

The big question is, why do you want to do that? If you want to use min/max to make sure the submitted value is in this range, you should hardcode these values at the serverside instead of relying to get them from the clientside somehow.

Passing that range as hidden field is pointless because it can easily be tampered with. Pulling them with a parser makes sure they are not tampered but adds the overhead of a second request.

Community
  • 1
  • 1
Gordon
  • 312,688
  • 75
  • 539
  • 559
  • I thought of this too, but it's not really a *good* way in most cases IMO – Pekka Nov 23 '10 at 13:29
  • 1
    @Pekka what makes you think that? Adding hidden fields means adding clutter and they can be tampered with easily. Whether pushing or pulling them is a *good* way depends on what the OP needs these values for. If s/he uses them to make sure the value is inside these boundaries, pulling them is better. Of course, the other question is why they have to come from the UI in the first place. The *best* way would be to have all the necessary form validation at the server side right from the start and neither pushing, nor pulling them. – Gordon Nov 23 '10 at 13:34
  • yeah, but making a request to fetch the originating page? I don't know. Depends on the use case, I guess. – Pekka Nov 23 '10 at 13:36
  • @Pekka if I have to pick between an additional request or tampered data, I pick additional request. Data integrity weighs more than performance. See my update though. – Gordon Nov 23 '10 at 13:43
  • Well, it's a valid alternative. +1 – Pekka Nov 23 '10 at 13:44
2

Interesting. I had the same problem once, and fixed it the same way you did. Never actually looked back at the problem.

One thing I can think of is storing the values in a database, so you can: 1. Use them as input variable. 2. Access it any time you want to.

Ps: Originally this was a comment, but seeing as you'r accepting alternatives.

Nick
  • 1,082
  • 1
  • 15
  • 27