[Vtigercrm-developers] <RANT>When coding do not turn off warnings!</RANT>

[Hamono, Chris (DPC)]

"The problem mentioned by Chris was about a scenario in which an end user sees errors and it is a serious security problem so I expressed my disapproval for this part of his email"

You must have missed my subject line. "When CODING do not turn off warnings!"

I am aware that due to legacy code in vtiger that warnings must and should be turned off.

The reason for my rant was to say these issues would not be so prevalent had the tools provided (warnings) been used from day one. There are many developers reading this forum. Many of whom are self taught. They may consider it acceptable to ignore and disable warnings. It is not!

To be clear...

In a production environment. TURN ON WARNINGS but send them to the log file and watch the log file. it can catch many errors which may at best be an inconvenience to your customers or at worse it could be a security issue.
When CODING either send warnings to the display (sometimes impractical). To the console (I use firephp) or to the log file - Make sure your code does not emit warnings!

Unfortunately with vtiger there are so many warnings that your growing logs will crash your server, so in this case we are forced to turn off warnings.


Chris 

________________________________________
From: vtigercrm-developers-bounces at lists.vtigercrm.com [vtigercrm-developers-bounces at lists.vtigercrm.com] On Behalf Of Błażej Pabiszczak [b.pabiszczak at yetiforce.com]
Sent: Saturday, May 16, 2015 2:04 AM
To: vtigercrm-developers at lists.vtigercrm.com
Subject: Re: [Vtigercrm-developers] <RANT>When coding do not turn off warnings!</RANT>

I described a scenario for an end user. A programmer has many ready-made tools that help to diagnose problems. If there are any problems [e.g. white screen] then he can check in a testing environment what is the reason of the problem. A testing environment can have an option for displaying errors enabled and a different server configuration.

The problem mentioned by Chris was about a scenario in which an end user sees errors and it is a serious security problem so I expressed my disapproval for this part of his email.

Another issue is the fact that displaying of warnings should be constantly developed. If a programmer cannot find an error in application logs, then each time a problem is solved, a tool should also be improved and developed so in the future it will be easier to find and solve similar problems. Vtiger skips logging of errors in many locations and it is necessary to add them. Additionally some of JS are placed in wrong locations, e.g. in html instead of separate js files so the analysis from the browser level is much more difficult.

In summary:

1. NO for displaying errors to an end user.

2. YES for log development in order to optimize error search.

Recently we organized everything a bit and moved it to one location: https://github.com/YetiForceCompany/YetiForceCRM/blob/master/config/debug.php, maybe it would be worth doing it in Vtiger 6.3, too.

---
Z poważaniem / Regards

Błażej Pabiszczak
Chief Executive Officer
M: +48.884999123
E: b.pabiszczak at yetiforce.com<mailto:b.pabiszczak at yetiforce.com>
________________________________



W dniu 2015-05-14 22:58, Alan Bell napisał(a):

well there are development settings and production settings for a reason, the idea is you develop with errors turned on, then turn them off for production. It would be rather nice if vtiger wasn't such a complete avalanche of warnings, it would make development easier. I want to see errors I caused, much better than staring at a blank white screen and guessing what the problem was! "Patches welcome" is a fair response to this kind of thing, it isn't hard to address most warnings, someone just has to get on and do it.

Alan.

On 14/05/15 21:55, Błażej Pabiszczak wrote:

I completely disagree with you. All good security practices, which I have got familiar with, clearly describe principles for displaying errors. A user should only see errors handled by the application. Other errors such as sql, php, apache shouldn't be visible and I don't think there are any arguments against it.

Not a single application is ideal, but displaying errors is a serious breach of security and should never happen. A good example are websites with web server errors [e.g. 403, 404] that should be also handled by the application [should have its own error pages] because hakers can get information about software and its version from the default websites for server errors.

---
Z poważaniem / Regards

Błażej Pabiszczak
Chief Executive Officer
M: +48.884999123
E: b.pabiszczak at yetiforce.com<mailto:b.pabiszczak at yetiforce.com>



W dniu 2015-05-14 03:02, Hamono, Chris (DPC) napisał(a):

A note to developers, vtiger, yetiforce or otherwise.

If you must recommend turning off php warnings in your code. You are doing it wrong!

I cannot make this point strongly enough.

There is a reason all compilers and interpreters spit out massive amounts of warnings. It's because these warnings indicate where your code is SLOPPY.

By ignoring those warnings you are potentially coding security risks and buggy code. uninitialized variables are the most common source of warnings and also the most common source of bugs.

So if you tell users they must turn off warnings it's a sign that the code is poorly written.

Chris

_______________________________________________
http://www.vtiger.com/



_______________________________________________
http://www.vtiger.com/


_______________________________________________
http://www.vtiger.com/