How do I harden OC against "Cannot find controller" errors?

Hello,

I am customizing a very nice OC installation, including vQMods, Override Engine, SEO URLs with NGinx and so on.

It's all very nice and dandy but i'd like to harden it against a very common error:

Blank page with:

Notice: Cannot find controller class file for route 'about' in /var/www/hostname/public_html/system/engine/factory.php on line 152


In order to get that error all I need is to replace one bit in the URL with a random word.

I know, end users are probably not going to tamper with the URLs and replace:

http://www.domain.tld/about_us

with

http://www.domain.tld/about

But:

1) It's very ugly to crash a polished website and spam OC log entries just because somebody entered a word.

Log:
2013-10-09 11:02:28 - PHP Notice: Cannot find controller class file for route 'about' in /var/www/hostname/public_html/system/engine/factory.php on line 152


2) Malicious users WILL get information about the installed software, server layout and configuration and thus get an edge into hacking into the website.


What I'd like to do is to replace the blank page with something as basic as the "Not found" page.


Is there any kind soul who could please tell me the 2-3 lines to write in to achieve that effect, and where to put them?

Thanks in advance.

You can "harden" it by the simple expedient of moving to a server with Apache, OC is meant to run on Apache not IIS or "NGinx and so on". It may seem polished to you but the software combination supporting it is not polished and is not even an appropriate vehicle, relative to OC. Try stackoverflow.

The "Malicious users WILL" line seems to mean that errors are being thrown onto the screen. On a production box you have error reporting on, turn that off; leave error logging on. The log entries themselves are scarcely "spam" of any sort, they are recording consequences of whatever is a mismatch.

You have the override engine. Ask JNeuhoff (he supports it) whether he has any ideas as to what it is doing in context of the server where you put it.

A completely blank page is a nullity, the processor received and executed what was nonsense and stopped. See if there are any missing or extra semicolons (your basic garden variety ";") ending lines, or any improperly escaped (needing "\") quotes or special characters. That nullity is not something you can "replace" with any standard error document (such as Apache 404) -- the processing stopped dead in its tracks, the browser painted dead white for a dead blank page.

butte wrote:You can "harden" it by the simple expedient of moving to a server with Apache, OC is meant to run on Apache not IIS or "NGinx and so on". It may seem polished to you but the software combination supporting it is not polished and is not even an appropriate vehicle, relative to OC. Try stackoverflow.

OC runs exceptionally well on NGinx. Not only it's blazing fast but it's also serving nice SEO URLs like: / as home page, /privacy that replaces /information/information&information_id=6 and so on.

I don't see how switching to Apache (somewhat hard on a redundant server cluster meant for lots of connections) would improve that.

butte wrote: The "Malicious users WILL" line seems to mean that errors are being thrown onto the screen. On a production box you have error reporting on, turn that off; leave error logging on. The log entries themselves are scarcely "spam" of any sort, they are recording consequences of whatever is a mismatch.

I am still finishing development on it, so of course error reporting is on. I don't tolerate even the sligthest notice so I want to catch them before we go public.

butte wrote: You have the override engine. Ask JNeuhoff (he supports it) whether he has any ideas as to what it is doing in context of the server where you put it.

I will.

butte wrote: A completely blank page is a nullity, the processor received and executed what was nonsense and stopped. See if there are any missing or extra semicolons (your basic garden variety ";") ending lines, or any improperly escaped (needing "\") quotes or special characters. That nullity is not something you can "replace" with any standard error document (such as Apache 404) -- the processing stopped dead in its tracks, the browser painted dead white for a dead blank page.

There's no missing semicolons, I am willfully trying to break the software and fix the weaknesses before someone more malicious does.
If I throw nonsense to ANY software, it HAS to gracefully degrade.
After all, a 404 page is also "nonsense" but the web apps don't throw a blank 404 page in the face of the users since several years.
In the eyes of an end user, a missing / not found controller is like a missing / not found page: an error. And errors may be reported as a crude blank page or a nice "Ooops please try again" page. The former is going to scare the user away, he does not even have a link to return back to the website. The latter helps him.