DB_escape_string

[icedlava]

Hi Jo,
mysql_real_escape_string() is deprecated as at PHP 5.5.
Tim

Yes, if it is mysql_real_escape_string() in the code then it is a copy/paste error from a different branch. Should have been mysqli_real_escape_string().

I note Phil has changed your commits to use this function

Yes I emailed Phil and informed him of the problem with these 'corrections'. There should be a correction from mysql to the mysqli if mysql was used in error but that is all at the moment.

Unfortunatley, the DB_escape_string is broken and it continues to introduce problems into the database data.

There is no 'easy' solution as it is a code wide issue. There is no one easy function that can be provided, especially if we continue to use mysqli. This is a much bigger issue than just entities or unescaped charaters.

This is a change that has potential to affect how database security is handled (will we use bind parameters or not?), are we willing to change all the database inserts/updates in the codebase?, will we continue with mysqli or pdo?, how are we going to handle post vars through the code ? The latter of course is involved due to the current way the code is handled in session.inc and elsewhere with post, get, session vars.

What is the minimum level of php that we should code for? We will have to at some stage, make a break and perhaps keep a maintenance release for those that want php 5.2 or less.

For any future development I would think we have to go with at a minimum php 5.3 - even php 5.5 is the current release. There are incompatibilities wtih php versions so there has to be a decision on this.

So, it is not a quick fix with some 'improved functions'. It is something that should be actively discussed by webERP developers and planned for the code base.

---

In relation to a temp fix for DB_escape_string - as mentioned in my commit (it was temporary), we should in fact cater for mysql and mysqli which that quick fix didn't (but should have been mysqli).

There is the option of setting up another function such as DB_escape_string2 (as example) that corrects for the current DB_escape_string. I mentioned this in my email to Phil

Personally i'm not keen in introducing 'temp' functions into the api.
If you do want to have this as a solution then I can add one to cater for the 'temp' fixes so we do not have to use the current DB_escape_string function but still cater for mysql/mysqli.

Just let me know.

Cheers,