PR https://github.com/mantisbt/mantisbt/pull/215

Added code to the PR so that the config is automatically set to recommended developer's values when the server is localhost.

Users would never be running browser sessions on the web server itself...
They do.

Users A and B access the server via X11 (Unix) or RDP (Windows).
Both will be able to access http://localhost and both will get the same page.

Follow-up from grangeway's message to the mailing list
http://permalink.gmane.org/gmane.comp.bug-tracking.mantis.devel/5460

I'd argue that having fancy logic to detect error handling is a bad
idea as some people may want to run mantis in production via atrols
WAMP setup for instance, and would likely be running it locally for
personal use, and not be a 'mantis developer', and therefore not
want automatic developer settings turned on.

That was Victor's idea really, I just implemented it as I thought it made sense, but considering your and atrol's arguments I don't mind reverting it.

Personally, I think our error handling settings are too complex when
working on 2.0/next before, we simplified them to a "show_friendly_errors"
command. At the moment, we have 2-3 settings, some of which consist of
arrays of what to do when various types of errors occur etc etc.
For the most part, I believe this is over complicated, and we should
have two modes: a) live/production b) debug/developer.

I actually disagree with that. I believe it is really a good thing to have fine-grained configuration for error reporting as it provides flexibility, and while the current system is certainly not perfect, I would not want to replace it with a simple on/off switch as you're suggesting.

Being able to specify what errors do and where they go individually (Halt/Inline/Firebug etc) is good. And likewise having the option to display detailed/debug errors is highly useful in certain cases, but not desirable the rest of the time.

I worry where we attempt to support a lot of convoluted scenarios and use that as a measure of what makes sense to implement in MantisBT. Someone running MantisBT as local host and then doing remote desktop to share the instance seems like a scenario that we can safely call unusual and we do really need to worry about. I can understand WAMP for personal use (no security issue), I can even understand WAMP for intranet user (shouldn't be localhost). But WAMP with localhost then remote desktop, really?

If we take asp.net as an example, its error system supports the distinction between local and remote errors. For example:
<customErrors mode="RemoteOnly" />

The above tag means don't show the exceptions and use custom errors when the client is remote, but if local, then show it. I don't know if we need to be as sophisticated in our configs, but I wonder what ASP.NET will do when someone remote desktops on the server and browse from there? I bet the exception will be shown.

The reason I would like to make this an automatic behavior, is to have every MantisBT core or plugin contributor have this ON by default and hence make sure they can see errors without having to "read our manual", apply the settings, etc. I think this will improve quality for both core and plugins, which at the end of the day reflects on MantisBT as whole (even if errors are caused by plugins). Even for me, I have so many machines with multiple MantisBT work areas on them, and it is very easy for me to forget setting this on one of them.

and it is very easy for me to forget setting this on one of them.

Me too, but is forgetfulness a reason to decrease out of the box security?

seems like a scenario that we can safely call unusual

It might be unusual, but attackers don't ask if a scenario is unusual or not, they just use the unusual scenario.

If we really go on to implement an out of the box convenience solution for developers, we might also consider some more settings, e.g.

$g_show_detailed_errors = ON;
$g_stop_on_errors = ON;
$g_show_timer = ON;
$g_show_memory_usage = ON;
$g_show_queries_count = ON;

Furthermore there should be some more cases implemented in login_page.php where we display a warning for enabled debugging settings.

To be honest, I still don't like the idea that there is some magic in the background based on the URL.

The summary of this issue is: Default $g_display_errors setting should reflect what an admin would want to use
The change for localhost is nearly the opposite of it.

What about a checkbox during installation?
Something like: Enable typical developer settings
If set, write the settings to config_inc.php.

And/Or or function in admin directory for existing installations.

decrease out of the box security?

Wait a minute.

The only thing this change does, is display a quite harmless inline message for all PHP error types, and a standard MantisBT error page for warnings.

I don't see in what way this would introduce a security risk. At best an annoyance for hypothetical instances using Mantis in the unusual architecture you described previously.

That said, as mentioned before, I am not opposed to reverting this.

there should be some more cases implemented in login_page.php where we display a warning for enabled debugging settings.

Good idea actually.