I have a module that may accept several optional parameters from the user. The "standard" way of doing this is something like "my-module/action/123/0/3/list/xyz" where everything after "123" is optional, so doesn't show up in the menu entry. I'm not crazy about this technique, although the menu system does make it easy to use. A) The user has to remember, or look up, the order of those parameters (I have to look them up because I can't remember them, and I wrote it). B) If the user is happy with an intermediate value (e.g. the "3" above), they still have to specify it in order to use "list." C) There is no flexibility. I was playing around and realized that $_GET makes getting input parameters from the query string pretty easy. It also gives me more flexibility in adding (or removing) the optional parameters, means the user doesn't have to remember the order, and means only values that are desired have to be entered. Will I be tarred and feathered for going the $_GET route? Nancy E. Wichmann, PMP No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.0/1685 - Release Date: 9/22/2008 4:08 PM
On Wed, Sep 24, 2008 at 4:49 PM, Nancy Wichmann <nan_wich@bellsouth.net> wrote:
I was playing around and realized that $_GET makes getting input parameters from the query string pretty easy. It also gives me more flexibility in adding (or removing) the optional parameters, means the user doesn't have to remember the order, and means only values that are desired have to be entered.
Will I be tarred and feathered for going the $_GET route?
It certainly makes more sense to use in-path arguments when they are simple and obvious, and as soon as you start using filter parameters, etc, Drupal core itself uses _GET parameters. Google also advises to do so, especially if you need to move around parameters: http://googlewebmastercentral.blogspot.com/2008/09/dynamic-urls-vs-static-ur... Gábor
On Sep 24, 2008, at 7:49 AM, Nancy Wichmann wrote:
Will I be tarred and feathered for going the $_GET route?
Not if you're careful with the input. ;) Also, you shouldn't be taking any action just from a GET request, or you're opening yourself to CSRF (Cross site request forgery). To avoid this, you need a confirm form that uses POST to actually trigger the action. Regards from the security team, -Derek (dww)
Also, you shouldn't be taking any action just from a GET request, or you're opening yourself to CSRF (Cross site request forgery). To avoid this, you need a confirm form that uses POST to actually trigger the action.
This isn't really about GET vs POST, but rather about using session- derived tokens (which you get for free with Form API). To avoid the annoyance of a confirm form, you can add and verify tokens manually with drupal_get_token() and drupal_valid_token(). Which you should be doing for ajax callbacks anyway, regardless of whether they are POST or GET. Steven
On Wed, Sep 24, 2008 at 10:09 PM, Steven Wittens <steven@acko.net> wrote:
Also, you shouldn't be taking any action just from a GET request, or you're
opening yourself to CSRF (Cross site request forgery). To avoid this, you need a confirm form that uses POST to actually trigger the action.
This isn't really about GET vs POST, but rather about using session-derived tokens (which you get for free with Form API). To avoid the annoyance of a confirm form, you can add and verify tokens manually with drupal_get_token() and drupal_valid_token(). Which you should be doing for ajax callbacks anyway, regardless of whether they are POST or GET.
Steven
This is why you should use sessionsbased tokens, http://www.codinghorror.com/blog/archives/001171.html Regards, Johan Forngren :: http://johan.forngren.com/
On Wednesday 24 September 2008, Steven Wittens wrote:
Also, you shouldn't be taking any action just from a GET request, or you're opening yourself to CSRF (Cross site request forgery). To avoid this, you need a confirm form that uses POST to actually trigger the action.
This isn't really about GET vs POST, but rather about using session- derived tokens (which you get for free with Form API). To avoid the annoyance of a confirm form, you can add and verify tokens manually with drupal_get_token() and drupal_valid_token(). Which you should be doing for ajax callbacks anyway, regardless of whether they are POST or GET.
Steven
Do I need a verification token for GET (=idempotent) calls? My impression was that as long nothing changes on the server (besides view counts), this token is not really needed. I try to avoid the practice of adding long verification tokens to GET URLs, since it is ugly. --yuval
Derek Wright wrote
Not if you're careful with the input. ;)
After merging the entered data with $_GET and unsetting a few unnecessary things, I do array_walk($params, 'check_plain') - is that safe enough? Nancy E. Wichmann, PMP No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.0/1685 - Release Date: 9/22/2008 4:08 PM
participants (6)
-
Derek Wright -
Gábor Hojtsy -
Johan Forngren -
Nancy Wichmann -
Steven Wittens -
Yuval Hager