A few enhancements to the Input class:

* Adds new config value $config[‘allow_get_query’] that turns on the ability to use GET values with $this->input->get()
* Adds $this->input->env() (for $_ENV), mostly just for completeness
* input::xss_clean() now processes arrays recursively, so more than just the first level (or in a couple cases, only the first two levels) are cleaned.
* A few little code cleanups and optimizations

The patch is at http://gregmaclellan.com/CI_Input-get.patch, which can be applied in the libraries/ directory

Note: I removed some code from Router that grabbed the first element of the $_GET array and used it as the current path.. I’m not really sure what it was for- possibly for supporting “http://mysite.com/?controller/method” as a URL? I couldn’t find any documentation explaining that was even possible, nor can I really see why it would be necessary. If anyone is actually using this or sees benefit in keeping it, let me know and I’ll adjust the patch to continue to allow it. It will likely cause problems when allow_get_query is on, but it may be possible to work around it - but there’s no point if no one is using it

You can also add the following code to your application/config/config.php file:

Overall, except for the bit of code removed in Router, these changes provide total backwards compatibility with CI as it is now. GET remains totally disabled unless allow_get_array is on. If enable_query_strings is used (and allow_get_array is off), the $_GET array isn’t actually cleared,  but $this->input->get() will still always return false.

I agree that GET data should be present in the Input class..  but not with the option part - it should be present aways.

As much as I like the URI segment way of doing things, GET is still necessary. e.g.

http://www.domain.tld/controller/function[/]?var1=content&var2=content

One big thing about POST method is that when people click back in their browser they get that “page has expired” / “re-post data” confirmation dialog.. which is good when you want it, but not when you don’t.

If Google used POST method instead of GET it would drive me mad!

The code that kills GET:

  Why don’t you like GET Rick? 

Don’t get me wrong Code Igniter is GREAT! and these are only minor things..

Hmm, yeah, you raise a valid point .. why not just keep GET enabled all the time? It’s only accessible via $this->input->get() (or $_GET .. but the CI way is to not use that).  I don’t see much harm in it, I just did the patch this way because it keeps it backwards compatible.

Section 9.1.1 of RFC2616 states:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

So basically, it’s against the HTTP specs to use GET for anything but the retrieval of data (eg, doing any INSERT/UPDATE/DELETE operations). Anyone that thinks there is extra security because it is harder for users to edit POST info than GET is fooling themselves. I’m really not sure what the reasoning is behind disabling GET, but my opinion as a web developer for the last 6 or so years (professionally) is that there is no harm with GET as long as you’re using it properly, and know how to sanitize input. CI as a framework provides means to do both of those.

Hello,

Using $_GET tables are not harmfull. $_REQUEST is woriest for a web developper. But not every one sanitize correctly input data, especially, get data.
Injections are possible by multiple ways, like post or get data. Just have to do some check.

Why translating $_GET in some library using ? Perhaps to do always some sanitize for new one that not understanding this.
You could do some sanitize directly without using CI way (like I do on my sites since many years).

When you know what you have to retrieve, and what you have to do with it, just take your cleanning machine and do your stuff. Get or Post doesn’t really matter. Only kick off Request practice, and you will be fine.

I agree. It would be very reassuring to see $this->input->get() back in the main codebase.

SEO friendly segments are useful for some purposes, and GET value pairs suit other purposes.

Being part of peoples everyday computer use, a significant number of people will directly edit a URL rather than go back to the form - especially if POST is required (which should be only for update/destructive edits as per above). Breaking this and replacing it with a solution that offers no clue as to what each value represents is of no advantage.

Please consider accepting this patch into trunk, so we can rely on CI supporting $this->input->get() going forward.

Using $_REQUEST is *too* ugly!

Cheers