DB_escape_string

[icedlava]

Hi Jo, as I said in a previous post, PHP 6 was dropped a couple of years ago, and the decision to re-open 6.0 has not been taken yet.

Sorry, I edited the post - should have been 5.6 not 6 - 5.6 alpha is out for a while now.

Most projects still have 5.2 as the minimum requirement for reasons that I have said before. The end of life you talk about is from the core developers, but the distros and the hosing companies still maintain the older releases.

Most projects that I work with, or have worked with for some years have a minimum of 5.3 to base development on but in some case the code will work on php 5.2 but not all of it - for example some modules may fail.

These are just my thoughts on the matter in relation to what code we should use to fix the issue of this thread - which is off track now.

It is very time consuming going over and over the same thing when in fact this thread is about fixing the escaping of data in context (rather than with a broad brush as in session.inc now) and how to do that.

One method is to use bind vars for database data, and something else for output data.

Perhaps we can get back to deciding if anything now - is going to be fixed?

Thanks,

note that php 5.2 has already had end of life past some years ago.

---

Hi Agaluski,

Can I assume right now that If i wish to add a new field to the database and I add the the existing INSERT or UPDATE statement something like comments = '". $_POST['WOComments'.$i] ."' that the posted variable has already been cleaned in includes/session.inc so I do not need to escape it?

In the current code, all variables including session, post and get variables, no matter what they are are escaped using DB_escape_string which applies mysqli_db_escape_string to the data.

So yes.

However this is the problem of this thread - the escaping is not done in context. This is what needs to be fixed and the thread is looking for a solution when the session.inc code if fixed by removal of that escaping.

This code worked at the time it was done as a quick fix to an important problem, but was applied across all data which is causing problems elsewhere and requires fixing.

Thanks for your comment and interest.

---

I started a thread on minimum php version here http://www.weberp.org/forum/showthread.php?tid=2181 if anyone is interested. This might be better than hijacking this thread with it's pros and cons.

Cheers,