0

I am reviewing a system (an old system) in which in some cases, they send data in a form with POST method, but they also send parameters to the url, as if using get.

something like this:

echo "\n<FORM METHOD='POST' NAME='onegroup' ACTION='menu.php?sesion=".$sesion."' >
    <INPUT TYPE='HIDDEN'    NAME='sesion'   VALUE='".$sesion."'>
    <INPUT TYPE='HIDDEN'    NAME='index_login'   VALUE='1'>
[...]   
</FORM>\n";

(note, sesion is not a typo, is just the word "session" in spanish)

What happens is that the "sesion" parameter gets sent both by url and by an input field, thus, the 'sesion' variable is then received both in the $_POST array and the $_GET array.

Why would this be necessary and should i leave it like that? or could i just take it off from the url and just rely on the $_POST data?

I have read in the comments for this answer that it is perfectly possible and valid to send data from both GET and POST (although the method itself is only either GET or POST (or others) in this case is POST, because that is the way the form defines). Now in this specific case, why would someone want to send the SAME sesionvariable (i.e. with the same value) by both get (by url) and post requests?

In my menu.php script can read both $_POST and $_GET and each will have its "version" of the variable, but it happens to be the same. I've also played around and saw that if instead of $_POST or $_GET i read the $_REQUEST array, i get all the variables together, but in the case of the duplicated one (sesion), the post version gets precedence.

Another thing is that they rely on the "Register Globals" option, and thus, instead of explicitly using $_GET["sesion"] or $_POST["sesion"] (or even $_REQUEST[]) they just use '$sesion' everywhere to use that information (and just the same for any other variable in the request). Again, playing around, i see that in that case, the POST version of the variable gets precedence also. But can I always rely on that?

Should I just use the post method and remove the parameter from the url?

Why would they want to do this instead of just sending everything by post? As I see it, there is no reason of using both, specially since both have the SAME value. If they didn't they could just choose which version to use, but that is not the case, and I can't think of anything other that it is just something they left there and never "fixed"

What are some "real-life" examples in which someone would need to use such scenario with both POST and GET requests, and specially with the same variable name in both?

thanks.

Community
  • 1
  • 1
DiegoDD
  • 1,625
  • 4
  • 21
  • 32

2 Answers2

2

You should remove one of them (preferably GET) if the values are same. However, you also need to make sure that you make corresponding changes to your form processing logic so that the code gets the values it is expecting. It is better to use $_POST or $_GET in place of $_REQUEST since that way you are explicit about what values you are passing and what values is your code expecting. For example, if you are using $_REQUEST then your POST values can be overwritten by GET which might be a security issue. Also, it is not a good idea to rely on register globals as that could cause a security issue too plus the register global on/off setting might differ from server to server. As for why would someone do this, it could be an error or a lack of knowledge about the way PHP GET/POST works.

For a real life scenario:

For many of my applications, I use sessions and pass the php session_id as a GET parameter in the url from page to page. Each page also has a "verify.php" required which validates a session and checks if a user is logged in. If I am dealing with the forms, then I just creates forms and specify the action part as : 

action="form_submit_page.php?SID=<?php echo Session_ID(); ?>"

The form passes the values from one page to another as POST while the action part passes session as GET.

Maximus2012
  • 1,799
  • 2
  • 12
  • 15
  • I know one should use $_POST or $_GET, the problem is they RELY on register globals, so they don't use either, neither $_REQUEST. As of now we have control of the servers, and can control the flag to always be on (as well as the php version, we keep it at 5.3 so we can precisely rely on that)I will just remove the GET version of that specific variable and hope not to affect something. – DiegoDD Aug 09 '13 at 19:41
  • If that works for you then its OK (maybe not very secure though). You might also want to look into this: http://stackoverflow.com/questions/1417373/why-is-register-globals-so-bad – Maximus2012 Aug 09 '13 at 19:42
  • regarding to the update to the answer, that is exactly what they do! they pass the sesion id as a parameter in the url, but WHY to do that? why not to just send it in the POST request? I mean, why does it have to be in GET instead of POST? Or why to send it at all? Doesn't php "propagates" the session anyway? that is the point of $_SESSION and session_ID(), right? if it gets stored, why do you need to propagate it by url? – DiegoDD Aug 09 '13 at 19:44
  • YEah, I know register globals is a BAD idea , but that is the way the system is made. If it depended on my, i would eliminate it, but unfortunately it would need a lot of work to check every script and use the proper $_GET or $POST variables instead. I will take a look into that to convince people here to stop relying on it! THAnks =) – DiegoDD Aug 09 '13 at 19:47
  • They way I do it (and also the way "they" do it), is just one way to do it. The same can be achieved through cookies. The reason I need to pass the session ids from page to page is to check if the user is logged in since what we use is a global login system that is not specific to my application. That system relies heavily on php sessions. Ideally, you want to pass through POST, only the things that you are planning to use in your form. By keeping the session id in GET in place of POST, my code is uniform since not all pages are forms that get passed from one page to another. – Maximus2012 Aug 09 '13 at 19:48
  • So the reason to propagate the session id is only (in your specific case) because you can't use cookies? That also leads me to another question, how good or bad would be the idea to propagate the sesison id in a $_SESISON variable itself? something like for example `$_SESSION["my_session_id"] = session_id()` the first time, and then just read it when you need it... That way, it's always available and you don't need to rely on forms to POST data, neither on urls or cookies . I suspect is a bad idea, but I can't tell why. I don't yet understand sessions very well. – DiegoDD Aug 09 '13 at 21:14
  • I can use cookies but in this specific case I don't. I also store session_id() value as a separate value in $_SESSION array. That part is also used in verify.php to check for the validity of a session among other things. It is not exactly a bad idea but understand that $_SESSION values can be overwritten "accidentally" but session_id() values can not be easily manipulated since its coming from an internal php function. – Maximus2012 Aug 09 '13 at 21:24
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/35169/discussion-between-diegodd-and-maximus2012) – DiegoDD Aug 09 '13 at 21:32
1

I use query sting parameters (GET) to chose the active page and POST values to carry form data. There is a legitimate use-case for this.

If the data is a repeat, then kill the GET.

TecBrat
  • 3,643
  • 3
  • 28
  • 45
  • I also use querystring rather than viewstate to make some settings variables persist and to allow me to manipulate the settings of pages I open or refresh programatically. This type of procedure is often separate from form submission and thus get and post may be used concurrently. – user314321 Aug 09 '13 at 19:53