Welcome Guest, Not a member yet? Register   Sign In
Misleading passage in user_guide
#1

[eluser]Majd Taby[/eluser]
Hey, I was just whining about the lack of $_GET in the IRC channel when I was made aware of:

Code:
/*
|--------------------------------------------------------------------------
| Enable Query Strings
|--------------------------------------------------------------------------
|
| By default Code Igniter uses search-engine friendly segment based URLs:
| www.your-site.com/who/what/where/
|
| You can optionally enable standard query string based URLs:
| www.your-site.com?who=me&what=something&where=here
|
| Options are: TRUE or FALSE (boolean)
|
| The two other items let you set the query string "words" that will
| invoke your controllers and its functions:
| www.your-site.com/index.php?c=controller&m=function
|
| Please note that some of the helpers won't work as expected when
| this feature is enabled, since Code Igniter is designed primarily to
| use segment based URLs.
|
*/
$config['enable_query_strings'] = TRUE;
$config['controller_trigger'] = 'c';
$config['function_trigger'] = 'm';

Which I had no idea existed...considering I read the whole user guide, then I went back to it, and it says:

"GET data is simply disallowed by CodeIgniter 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."

Which is misleading, I feel like this would be much better:

"Unless configured otherwise, GET data is unset by default. The reason being that the system utilizes URI segments rather than traditional URL query strings. You can still call controllers/methods through the URL by defining controller_trigger and function_trigger in the config.php file"

...or something like that.
#2

[eluser]wiredesignz[/eluser]
Well you better $_GET to using it JTaby. Wink
#3

[eluser]Majd Taby[/eluser]
lol i'm so excited about this, this solves a big bug in CodeExtinguisher Big Grin

EDIT: even when I set enable_query_strings to TRUE, regular CI-style URLs work just fine...why wouldn't this be enabled by default? am I missing something?
#4

[eluser]Michael Wales[/eluser]
It's not enabled by default because CI needs to understand how to build links with the URL and Form Helpers. This setting tells it which way to generate the links.
#5

[eluser]xwero[/eluser]
The handling of the GET global is confusing. Maybe the uri_protocol should have another setting namely GET instead of a separate setting which is ambiguous like you experienced.

There are a lot of people that want to use GET values maybe that could be a reason to stop manipulating the GET global.
#6

[eluser]adamp1[/eluser]
Also GET is unsecure in the fact its easier to inject code into a page using it. I know its simpler to use for passing data around, since you don't have to worry what segment to put what data in, but I would prefer the higher security.

Also none GET urls looks so much pretty and neater, that the real reason for me Smile
#7

[eluser]xwero[/eluser]
@adamp1 : GET doesn't need to be insecure if you take the same precautions like you do with other inputs. I wonder how may developers don't check uri segments making them as insecure as GET values.
In my rewrite of the validation library i check GET values which seems to be left out every validation library.
#8

[eluser]adamp1[/eluser]
I suppose they leave it out of the validation library since the form helper submits by POST and also if you submit by GET it is easy to change the sent data. To change POST you do have to go to a special effort.
#9

[eluser]xwero[/eluser]
True it's easy to change urls and POST should be used by default for sending data but there are valid cases where you add data to the url, GET or pathinfo, as secondary information like pagination offset.

A lot of people, me included, use data set in the url but don't check the data once it's set because there is no system that allows you to validate the data. I've been guilty of relying on the database class cleaning by passing uri segments to the query but lets say the segment needs to be a number but it is a string with validation the rendering should be stopped before querying the database. With the current validation library it's impossible to do
Code:
$rules[$this->uri->segment(3)] = 'numeric';
The url is an input like the form inputs and should be validated where needed whether it's a clean url or a GET query

ps : sorry for this thread jacking
#10

[eluser]nmweb[/eluser]
$_GET is just as unsecure as $_POST. Thinking that $_POST is more secure just because you can't change the variables in the url is false security and should never be promoted.

Anyway, there is a reason Google uses GET in their queries, so you can save the url and the url contains all necessary information. CI urls map to a page but it is not semantic to use CI segments as parameters in a search query.




Theme © iAndrew 2016 - Forum software by © MyBB