DB_escape_string

[icedlava]

Which 5.3 issues haven't been addressed? Pretty sure I did that a long time ago, and I haven't seen any 5.3 issues since then.

Hi Tim,

I was making a general point about php versions getting higher and older ones reaching end of life (meaning not supported), and our code remaining the same. This is specifically in relation to the problem at hand ie escaping of variables without context, the symptoms it produces, and security issues with database queries that we could solve at the same time. A big job, yes, depending on the method chosen - but I believe inevitable in some form or other at some point in the future.

---

Hi Exson,

According to some sample codes committed, we have to add a variables array, which is total different from those styles we used before. We have to add lots of question mark? Did this really make it safer than Tim's simple mysqli_real_escape()?

Yes, as mysqli_real_escape is not sufficient.

It seems that we have to rewrote all those scripts about query? It will make webERP green code instead of a mature system. Does this effort really need?

I believe some rewrite is inevitable - has to be done and I hope sooner than later so we can get it out the way. I think it will help make webERP a hardened, and up to date system.

I have also meet some extra slash problem, but I think it's solvable. Why we cannot solved it case by case?

I think part of the problem is the fact there is patching case by case - some cases which should not exist but due to incorrect escaping of data out of context (eg in session.inc or the old db_escape_string with the entities encoding in it). A more consistent system approach might help.

It's not like other projects which almost broken after php5.3. I hope this merit can also be kept.

I believe this is a symptom of those projects not acting in time to cater for php 5.3. But php 5.3 is already near end of life - we need to be looking at php 5.5 and 5.6 (php 5.6 alpha is out for a while now).

If there is new version feature only support in higher version, I suggest to provide a solution for lower version instead of push users to upgrade their operation environments.

I really understand this problem and the fact that some people cannot easily upgrade to a higher php.

However, at some point we cannot continue to code and support php 5.2 as we only loose the benefits of higher php versions and our code becomes more and more out of date.

Does anyone remember coding for php 3? or php 4? These debates to upgrade minimum php version are not new and there was much angst and discussion in some projects to do the work to stop support for php4!

But what would happen if we didn't upgrade our code since php3?

Sorry for being a broken record, but I believe we should be maintaining a branch for our webERP with php 5.2 support and making a higher minimum say php 5.3 for development and stable branch. That's one suggestion anyway.

I do think you have valid concerns Exson, but I believe we also need to move on at some point.

Cheers,
[Edit - 6 updated to 5.6]