Part of the EllisLab Network
   
1 of 3
1
CI Stupidly Kills GET Data
Posted: 04 January 2007 03:02 AM   [ Ignore ]  
Summer Student
Total Posts:  9
Joined  10-16-2006

One of the things I like the most about CI is that it doesn’t force you to write code in strict and specific ways.. it doesn’t shove its way of doing things down your neck… it doesn’t sneak around doing things behind your back.. you’re the coder and you can code however you like.

THE EXCEPTION: $_GET

The CI philosophy seems to be: worship the POST method and kill GET

Code Igniter User Guide

GET data is simply disallowed by Code Igniter since the system utilizes URI segments rather than traditional URL query strings (unless you have the query string option enabled in your config file). The global GET array is unset by the Input class during system initialization.


This is DUMB! It seems like this fundamental design decision was taken without any thought or it was assumed that GET vars (query string e.g. ?var1=value&var2=value ) could not coexist with the segment approach (e.g.  http://localhost/ci-get-fixed/seg1/seg2/?var1=value&var2=value ).. like it had to be one or the other.

THIS IS SUCH AN ANNOYING BUG!  vampire

It’s easy to fix but the fact that CI works this way as standard is sooo stupid!

Please fix this bug and set Code Igniter free smile

EDIT/CLARIFICATION:

The URI segment approach is great for links but form submissions don’t work this way (without client-side scripting).

http://localhost/store/search?q=search+terms

GET and POST have different uses as defined by the HTTP standard (RFC 2616). Submitting all form data using the POST method is improper and has adverse effects.
Both GET and POST have their place.

RELATED THREADS:

Thread: GET params (strange behaviour) ?

Thread: Input enhancements - (optionally) allow GET values

Thread: IMPLEMENTED: get() method from input class, better routing without mod_rewrite, bug fix for CI_Input methods

Thread: How to create mix urls (Segment + Querystring)

Thread: GET variables gone in 1.5.1 ?

Thread: $_GET value to controller

Thread: support for less than two GET parameters within the url

Thread: Silly Problem passing variables between controllers

Thread: $_GET[] causing problems with 1.3

...
I would link to a forum search but GET variables (query strings) aren’t supported wink
http://codeigniter.com/forums/do_search/?keywords=query+string

Profile
 
 
Posted: 04 January 2007 03:34 AM   [ Ignore ]   [ # 1 ]  
Lab Assistant
Avatar
RankRank
Total Posts:  207
Joined  12-22-2006

Euhm:

http://localhost/ci-get-fixed/seg1/seg2/?var1=value&var2=value

rewrite into:

http://localhost/ci-get-fixed/seg1/seg2/var1_value/var2_value

It is a design choice for CI and works quit good, you could also do this:

class AController extends Controller
{
    
function myFuncion($var1,$var2)
    
{}
}

And then have your URLs do

http://localhost/ci-get-fixed/acontroller/myfunction/firstvalue/secondvalue

Dont really see why you want to mix CI’s approach and $_GET

Profile
 
 
Posted: 04 January 2007 04:51 AM   [ Ignore ]   [ # 2 ]  
Summer Student
Total Posts:  9
Joined  10-16-2006

Yeah, I do that for links.. it’s great smile

The problem is that form submissions don’t (without client-side scripting).

http://localhost/store/search?q=search+terms

GET and POST have different uses as defined by the HTTP standard (RFC 2616). Submitting all form data using the POST method is improper and has adverse effects.
Both GET and POST have their place.

If Google used POST instead of GET it would drive me insane grrr

Profile
 
 
Posted: 04 January 2007 04:57 AM   [ Ignore ]   [ # 3 ]  
Lab Assistant
Avatar
RankRank
Total Posts:  207
Joined  12-22-2006
Kristian - 04 January 2007 04:51 AM

Yeah, I do that for links.. it’s great smile

The problem is that form submissions don’t (without client-side scripting).

http://localhost/store/search?q=search+terms

GET and POST have different uses as defined by the HTTP standard. Submitting all form data using the POST method is improper and has adverse effects.
Both GET and POST have their place.

If Google used POST instead of GET it would drive me insane grrr

True that if your really need GET in your forms it is a pain. I have discussed this with a colleague and he says that somehow if you use more than one GET parameter it works like this:

http://localhost/store/search?q=search+terms&var=whatever

I dont know why because I havent checked if it is true. It seems something in Router.php.

Profile
 
 
Posted: 04 January 2007 07:09 AM   [ Ignore ]   [ # 4 ]  
Administrator
Avatar
RankRankRankRankRankRank
Total Posts:  7321
Joined  03-23-2006

Have you read Enabling Query Strings in the user manual?  I think that’s what you want.

 Signature 

DerekAllard.com - CodeIgniter, ExpressionEngine, and the World of Web Design
BambooInvoice - Open Source, CodeIgniter powered invoicing.

Profile
MSG
 
 
Posted: 04 January 2007 07:25 AM   [ Ignore ]   [ # 5 ]  
Lab Assistant
Avatar
RankRank
Total Posts:  207
Joined  12-22-2006
Derek Allard - 04 January 2007 07:09 AM

Have you read Enabling Query Strings in the user manual?  I think that’s what you want.

It is only in the small case where he wants to submit something via GET. In all other cases he wants to use CI’s default behaviour. Not sure how to fix this (i am at work so shouldnt be diving into the Router code right now raspberry)

Profile
 
 
Posted: 04 January 2007 07:26 AM   [ Ignore ]   [ # 6 ]  
Grad Student
Avatar
Rank
Total Posts:  78
Joined  12-17-2006

thats less readable though : )
You could also write a MY_Router.php allow for some extra custom actions : )

 Signature 

moormanweb.info

Profile
 
 
Posted: 05 January 2007 10:26 AM   [ Ignore ]   [ # 7 ]  
Summer Student
Total Posts:  5
Joined  11-06-2006

-deleted-

Profile
 
 
Posted: 05 January 2007 04:42 PM   [ Ignore ]   [ # 8 ]  
Grad Student
Avatar
Rank
Total Posts:  78
Joined  12-17-2006

well ...the uri segmentation is a great thing about ci ... I absolutely agree on this! It transparently leads the request to a urcontroller/function and really does a great job with that
But what I just dont get about this - Why is’nt there even an option making it possible to just attach ONE get param to the url without breaking the routing down completely?? (like a simple searchquery would do)

I surely don’t like the option to pass everything to the query string and add all necessary characters that might appear within a segment to the “allowed uri characters” array and I dont get why a native PHP functionality (to use GET) is only possible if you a) use more than one get-param ... or b) make a custom MY_Router.php

And by the way ... using GET is not really less secure than using POST! The programmer himself actually ALWAYS needs to take care of the inputdata (ALL OF IT) in order to minimize potential security leaks!

greets Rico

 Signature 

moormanweb.info

Profile
 
 
Posted: 05 January 2007 06:51 PM   [ Ignore ]   [ # 9 ]  
Grad Student
Rank
Total Posts:  96
Joined  01-01-2007

hey POST is the same as GET security wise! Any idiot with FireFox can add POST headers. IT REALLY ISNT THAT HARD. Also it is quite easy to make a form and just direct it to the same action. For example because HTTPS was blocked I made a ‘mock’ login form going to http:// instead of https://.

So please don’t think that post is secure. The kind of person that would inject form data probably is smart enough to use FireFox and one of the many plugins such as the development toolbar. There is also plugins just to send POST data and edit their headers.

[hr]

The use of URL ‘GET’ method is a whole lot better and SEO compatible. The cool thing is that Google will archive both function/mode1 & function/model2 but they will not archive ANYTHING IN your site if you use GET. So unless you want the only page in your entire site to be archived the first page query strings are a bad idea. They kill any possibility of good SEO.

I personally like using the URL suffix .html but that probably doesn’t help SEO just makes your URL cooler.

[hr]

Second thing is that it is a whole lot cleaner to do that. I think that it is simply ugly and annoying to do ?blah=blah etc.

Mixing the two also is a bad idea. Also this

class controller ($cheesy,$poof)
{
}

Is cleaner than

class controller ($cheesy)
{
$poof
= $_GET['poof'];
}

And after all the reason for using a framework is to make ur code cleaner and easier to maintain.

Most frameworks have very good conventions. Even CI has conventions. Most conventions are good because it keeps people from looking at your code and saying, “WTF is this!!!” One widely used convention is to start a new line after every semi colon. Could you imagine code like

$chessy = $_GET['chessy']; $poof = $_GET['poof']; $cheesy = $_GET['cheesy']; $cheesy_poof = $_GET ['cheesy_poof']; echo $chessy; echo $poof; echo $cheesy; echo $cheesy_poof;
 Signature 

Arguing on the Internet is like running in the Special Olympics, even if you win you’re still retarded

Development Server (my laptop) WAMPP | CI 1.5.1 | Rapyd |

Server: UNIX | PHP 5 | Mysql 5 | Postgres

Profile
 
 
Posted: 05 January 2007 08:00 PM   [ Ignore ]   [ # 10 ]  
Grad Student
Avatar
Rank
Total Posts:  78
Joined  12-17-2006

I don’t actually see the problem with mixing the approaches if necessary for example to handle searching quick and easily or, as aceofspades said, to let GOOGLE index your site properly.
GET is not “BAD” or a “DEAMON” which we have to eliminate ...it CAN coexist with CI properly if you want.

And anyway ... good coding also is about using and chaining all possible approaches to create an intuitive, flexible and easy to maintain (bugtrack) application. GET (just like POST and COOKIE) also has the right to be there and to be used (I am wondering why the Input class has no “get” function as it has for “post” anyway).

PHP already has its limitations… why bother to add another one?

After all it’s the responsibility of the Coder to keep the code clean. Coding standards are there to make it easier for the Coder to keep it clean and the simple, straight way CI is set up also serves this purpose.

 Signature 

moormanweb.info

Profile
 
 
Posted: 07 January 2007 01:07 PM   [ Ignore ]   [ # 11 ]  
Research Assistant
Avatar
RankRankRank
Total Posts:  351
Joined  07-25-2006

I don’t see a problem with making your searches a POST search, with something like this function in a controller (only outlined):

function set_query() { // Post your search form here
  
$search_string = $this->input->post ('query');
  
$search_string = preg_replace ('@\W+@', '+', $search); // may also be: @[\W]+@, check your regex manual

  
redirect ("search/query/$search_string");
}

function query() { // This displays results
  
$likes = explode ('+', $this->uri->segment (3));

  
$this->db->select ('id');
  
$this->db->like ('name', array_shift ($likes));
  if (
count($likes) > 0 ) {
    
foreach ($likes as $like)
      
$this->db->orlike ('name', strtolower ($like));
  
}

  $query
= $this->db->get ('products');
  
// standard query result from active record. do what you need.

  
$this->load->view ('search_results', $data);
}

The benefit of doing it this way (assuming you can’t use GET strings with CI), is that your searches are still bookmarkable. You could also use $this->uri->uri_assoc(); to get a more refined search. The point of all this:
- This is forced “feature/bug/design choice” by Rick. I think GET strings are ugly, and POST allows you a nice step to filter search input. Only a bug if you used to working with GET data.

 Signature 

me and some random code, hosted by dh. and a blog too! ++ dead bugs

Profile
 
 
Posted: 07 January 2007 03:29 PM   [ Ignore ]   [ # 12 ]  
Summer Student
Total Posts:  13
Joined  01-05-2007

Doing it that way means you are doing 2 page loads for one action…  As far as filtering search input is concerned…. whats the point in filtering it at a redundant intermediate step when you’ve got to filter it again when its finally used anyway…

Anyway, I found that for me, GET vars work perfectly alongside segmented URIs, BUT you have to use $_REQUEST not $_GET, because as the docs state the $_GET array is unset by the Input class. 

I have my ‘uri_protocol’ set to ‘orig_path_info’ (using Lighttpd, might be different for other httpds, experiment!), and my GET variables are all available in $_REQUEST.  If you want to see what I mean, go to http://www.codescape.net/tools/hashgen?string=blah - ‘Tools’ is the controller, ‘hashgen’ is the method, and guess what - $_REQUEST[‘string’] is ‘blah’.

Hope this helps, or at least clears up the doubt of “it can’t do this!”.

Profile
 
 
Posted: 07 January 2007 04:48 PM   [ Ignore ]   [ # 13 ]  
Research Assistant
Avatar
RankRankRank
Total Posts:  351
Joined  07-25-2006
alan.briolat - 07 January 2007 03:29 PM

Doing it that way means you are doing 2 page loads for one action…  As far as filtering search input is concerned…. whats the point in filtering it at a redundant intermediate step when you’ve got to filter it again when its finally used anyway…

The first load is a header redirect, which is about as tiny as a load can get, and the second load is full load, in which your data is already filtered, and you can skip most of the checks you would make on GET data. And it’s indexable. I guess it’s a matter of taste. Most internet users are on broadband, and those that aren’t are already used to having slow internet, so why do a few extra milliseconds of redirect matter?

 Signature 

me and some random code, hosted by dh. and a blog too! ++ dead bugs

Profile
 
 
Posted: 07 January 2007 08:49 PM   [ Ignore ]   [ # 14 ]  
Summer Student
Total Posts:  13
Joined  01-05-2007

I think I am starting to see what you are getting at here.  However I still don’t get why it is felt necessary to completely obliterate the GET array to make sure nobody can actually use it…

Profile
 
 
Posted: 07 January 2007 08:52 PM   [ Ignore ]   [ # 15 ]  
Administrator
Avatar
RankRankRankRankRankRank
Total Posts:  7321
Joined  03-23-2006

Earlier in this thread I pointed to the manual to enable query strings.  CI doesn’t forbid their use, it just prefers a different way of organizing things.  It hardly prevents anybody from using it - CI is about helping us all code better by standardizing, abstracting, and use of conventions wink

 Signature 

DerekAllard.com - CodeIgniter, ExpressionEngine, and the World of Web Design
BambooInvoice - Open Source, CodeIgniter powered invoicing.

Profile
MSG
 
 
   
1 of 3
1
 
Post Marker Legend
New Topic New posts Hot Topic Hot Topic with new posts New Poll New Poll Moved Topic Moved Topic Sticky Topic Sticky topic
Old Topic No new posts Hot Old Topic Hot Topic with no new posts Old Poll Old Poll Closed Topic Closed Topic Announcement Announcements
Theme
Change Theme
Visitor Statistics
The most visitors ever was 721, on January 06, 2010 09:38 AM
Total Registered Members: 115004 Total Logged-in Users: 57
Total Topics: 122436 Total Anonymous Users: 4
Total Replies: 647302 Total Guests: 515
Total Posts: 769738    
Members ( View Memberlist )