Closed (won't fix)
Project:
Strongarm
Version:
6.x-2.0-rc1
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
15 Jul 2010 at 16:35 UTC
Updated:
4 Aug 2010 at 19:35 UTC
if $_POST['q'] is set, then $_GET['q'] gets assigned that value.
For example, take the following at /node/add/foo:
<form>
<input type="hidden" name="q" value="/node/add/bar" />
<input type="submit" name="submit" />
</form>
When this form is submitted, Strongarm assigns $_GET['q'] = '/node/add/bar'.
In turn, the menu system will hand the request to the wrong menu handler -- the callback for 'node/add/bar' instead of 'node/add/foo'.
I ran into this issue when trying to use autosave module.
@see #850934: Incompatibility with Strongarm module
Comments
Comment #1
yhahn commentedI've looked at this and it is simply not a good idea to use
$_POST['q'], especially when it's being used by autosave simply as a way of storing and retrieving a path value.The problem is that PHP is merging
$_POST['q']down into$_REQUEST['q']. It's very important that$_REQUEST['q']preserves the original request path value in Drupal as the language andcustom_url_rewritestack can alter$_GET['q'],$_REQUEST['q']serves as a check of the initial/literal path that was requested. If you're using$_POST['q']it will overwrite that, leaving a developer with no way of knowing what the actual request path may have been.For example, on a normal Drupal page
Request against
http://example.com/en/fooRequest against
http://example.com/en/foowith post dataq=barIn the latter case,
$_REQUEST['q']no longer provides an indicator of the actual request path, but more importantly, there is no indicator at all of the actual request path. Moreover, there is no guarantee of how$_POST['q']might be used, e.g. you could use it as a regular FormAPI field and its value might be "My grandma's apple pie".The short is, in this particular case and in all others using
$_POST['q']in Drupal is a bad idea.