Jump to content

[SOLVED] get value of Input type image in IE


abdfahim

Recommended Posts

well, my form has

<input type="image" src="image.jpg" name="del" value="thisval">

 

I know isset($_POST['del']) will not work in IE, I have to give isset($_POST['edit_x']), but my question is how can I get the value of that input type? One process I know is write the value in a hidden field at form submit using javascript, but is there any straight forword way?

No I want to use a image as my form submit button, also I need the value of that image input, because it is dynamically allocated. I know I can use a button for submit and change button style to paste that image on top, but that really lacks the fillings I wanna give to my page !

I don't understand what the problem is that you are having. If the name of the input is "del," then $_GET will hold 'del_x' and 'del_y' with their corresponding values.

No man .. this is not so straight forward :).

 

Let me tell you, if you use FF, it will return the following 3 values on form submit

$_POST['del'] = VALUE OF THE INPUT //in my case "thisval"

$_POST['del_x'] = pixel of x-th position of the image

$_POST['del_y'] = pixel of y-th position of the image

 

But if you use IE, it will give you the last two, that is position, but not the first one (value).

That value is hardcoded so why don't you just hardcode it into a hidden element? If it isn't hardcoded, it has to be dynamically set through code, not the user, so why don't you make that code set a hidden element instead of the input image?

 

The reason that IE doesn't return that value is because "value" isn't a valid property of input type=image. This just further raises the question of why you want a value in that tag. Maybe if you show more code I would understand it better.

ok guys .. here is the full description to end confusion ...

 

I have a table of may be 100 row with 100 records fetch from database. I have a edit image in the left of the table. Each image will act as a button clicking on that you can edit that particular record. Now the question is how php understand which row's image been clicked. Thats why I give the value of that image input type as the hidden ID for that record so that if I could get the value of that image input, I know which record to edit.

 

Now one question may come, why I am not using a simple linked image like page.php?ID=blabla. The reason is simple and obvious, I dont wanna reveal the ID in the address bar. Here is some portion of the code

 

<table ...... >
<form ....... >
while($row1=mysql_fetch_assoc($res1)){
      echo "<tr><td><input type='image' src='image.jpg' name='edit' value='".$row1['ID']."'></td></tr>";
}
</table></form>

That does make more sense now. First of all, if all this is about not showing the Id in the address bar, you could use the POST method, but I will assume there is a reason you don't want to do that.

 

If you don't want to use Javascript, one thing you can do is make a separate form for each different button that will be available. This would allow you to hardcode a hidden input element and whichever button is pressed only submits that particular one.

<form>
<input type="hidden" name="hid" value="thisvalue">
<input type="image" src="image.jpg" name="del">
</form>
<form>
<input type="hidden" name="hid" value="thisvalue2">
<input type="image" src="image.jpg" name="del">
</form>

 

Also, using an input type=submit element wouldn't necessarily fix the problem because the value of that tag isn't passed in IE if the user hits Enter instead of clicking it.

Right, because it's so difficult to view the source to look at the ID?

 

The idea that POST is somehow more secure than GET is a complete falacy. Sure it might take slightly more effort, but it's no more secure.

yes, you may right .. but even then giving those keys/IDs in address bar (GET method) is something not so standerd .. also why dont bound them to give "slightly more effort" if they want to break it, rather then giving them ready-made :).

 

And I dont get how you can get post variables by viewing source, you can do that in case of GET vars, as far as I know.

Right, because it's so difficult to view the source to look at the ID?

 

The idea that POST is somehow more secure than GET is a complete falacy. Sure it might take slightly more effort, but it's no more secure.

yes, you may right .. but even then giving those keys/IDs in address bar (GET method) is something not so standerd .. also why dont bound them to give "slightly more effort" if they want to break it, rather then giving them ready-made :).

 

And I dont get how you can get post variables by viewing source, you can do that in case of GET vars, as far as I know.

 

If your application would break because someone found an ID then you pretty deep in the brown stuff.

First of all, if all this is about not showing the Id in the address bar, you could use the POST method, but I will assume there is a reason you don't want to do that.

I actually do use POST method, there is no confusion on that.

 

If you don't want to use Javascript.

 

well .. i guess I wrote wrong in my first post. if IE cant get the values from image inputs, then no use for using javascript, i guess.

 

one thing you can do is make a separate form for each different button that will be available. This would allow you to hardcode a hidden input element and whichever button is pressed only submits that particular one.

That's a good idea !!

 

Also, using an input type=submit element wouldn't necessarily fix the problem because the value of that tag isn't passed in IE if the user hits Enter instead of clicking it.

Thanks !! I totally forget this fact and was planning to go back to input type submit if had this not worked, which will produce same result, of course !!

If your application would break because someone found an ID then you pretty deep in the brown stuff.

Not that easy buddy !! I have some 4 levels of protection, but that does not mean I would want to reveal my first level of protection so cheaply !!

 

Archived

This topic is now archived and is closed to further replies.

×
×
  • 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.