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

[Błażej Pabiszczak]

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 
-------------------------

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 
> 
> 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/ [1] 
> 
> _______________________________________________
> http://www.vtiger.com/ [1]

_______________________________________________
http://www.vtiger.com/ [1] 

Links:
------
[1] http://www.vtiger.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.vtigercrm.com/pipermail/vtigercrm-developers/attachments/20150515/8715d676/attachment.html>