CodeIgniter 1.6.3 Maintenance and Security Release

[eluser]louis w[/eluser]
get_post is a welcome addition for me.

It will be nice to replace
$item = $this->input->post('input') ? $this->input->post('input') : $this->input->get('input');
with
$item = $this->input->get_post('input');

[eluser]EEssam[/eluser]
Thank you, just updated my app

[eluser]achilleusrage[/eluser]
Does the xss vulnerability, fixed in the latest release, exist in earlier versions of CI? (<1.6)? I'm in a situation where I cannot upgrade to 1.6 because of the MySql 4.1 requirement. Is there an xss_clean patch for older versions of CI? Any other info on the bug would be appreciated.

[eluser]Derek Jones[/eluser]
Yes, it exists in all versions < 1.6.3. You can replace the Input class and have your installation patched, achilleusrage, or even better, create a legacy mysql driver (there's very little at present that you'd need to change from the current mysql driver) that you can use so going forward you aren't hindered from keeping up to date with the latest and greatest.

[eluser]achilleusrage[/eluser]
Derek,
Thanks for the info. I remember now that back when 1.6 came out there was a temporary solution for Mysql < 4.1. http://codeigniter.com/wiki/MySQL_4.0/

[eluser]Derek Jones[/eluser]
No problem; that wiki article is helpful in terms of identifying the current portion of the MySQL driver not compatible with versions < 4.1, but for portability and to prevent keeping up with hacks, you should make a copy of the current MySQL driver, rename it (and the files) to something like mysql_legacy, have the db_set_charset() method return TRUE, and select the newly named driver in your database config. Then all you have to do when updating is drop your legacy driver folder into your installation and viola.

[eluser]Seppo[/eluser]
Derek, is it too much to ask that if some one establish

Code:

$db['default']['char_set'] = FALSE;
$db['default']['dbcollat'] = FALSE;

the db_set_charset method wont get called?

I know, I know... it's easy to change and some future features (can't wait to see that!) require MySQL 4.1, but you could make everyone life easier...

And by the way (and now, really off-topic, but I just notice this) in DB_driver.php lines 178-188 are the same as 152-162... isn't there a way to avoid repeat it or wrap them in a new method?

[eluser]Derek Jones[/eluser]
Dunno if it's worth the overhead of an additional function call to avoid code duplication in 2 spots that are so close together, and not likely to ever be used anywhere else, but the point is taken.

What I would rather see, and might do when I get some time, is go ahead and create an official MySQL legacy driver. I really don't like the idea of creating an exception based on a config variable - the driver itself should handle it, IMO, returning TRUE for that method if the db doesn't support it. Shouldn't be something the user really has to know or understand unless they're interested.

[eluser]Seppo[/eluser]
Are you talking about creating something like "Mysql_old_driver" (you can use a better name =P) ? I like that idea... although you will be having 3 drivers using a mysql server where you should change each thing... (OK, I'm reading "Refactoring" by Martin Fowler and it really got me against duplicated code!)

I like the idea of the config file because you can update easily and I don't think it is an exception - You are setting the config to not use it.

And about the overhead... I think many things can be done to improve performance - For example a way to avoid hooks / benchmark classes to be loaded that most of the time are not used and yet loaded on every call. (I've been thinking that for a while and now I have the opportunity of writing it =))

[eluser]Derek Jones[/eluser]
As the MySQL driver's features grow, it would be necessary to continue to write in version exceptions, and that is a bigger pain than maintaining separate drivers. MySQL < 4.1, MySQL 4.1+, and MySQLi, while all close cousins, are three significantly different animals.

And I don't disagree with you about code duplication, in fact, you can see how much the Input class got refactored to avoid it, which I did at a user's suggestion. I'm just keeping a sense of perspective. Since you'd still need to repeat a conditional and return, the only code you're preventing from using twice is:

Code:

log_message('error', 'Unable to set database connection charset: '.$this->char_set);

if ($this->db_debug)
{
    $this->display_error('db_unable_to_set_charset', $this->char_set);
}

Re: hooks and the benchmark object, have you measured on various environments how much is gained by their removal?