View Issue Details

IDProjectCategoryView StatusLast Update
0017501mantisbtadministrationpublic2014-12-08 00:34
ReporterdregadAssigned Todregad 
PrioritylowSeveritytweakReproducibilityN/A
Status closedResolutionfixed 
Product Version1.2.18 
Target Version1.3.0-beta.1Fixed in Version1.3.0-beta.1 
Summary0017501: Default $g_display_errors setting should reflect what an admin would want to use
Description

This follows a discussion I had with @vboctor in ~c40860, summary below:

@dregad: DISPLAY_ERROR_INLINE is actually the default value in config_defaults_inc.php. I'm wondering if we should maybe change this - IMO the defaults should generally reflect what an admin would want to use in Production; based on that, warnings should probably be set to DISPLAY_ERROR_NONE. What do you think ?

@vboctor: I agree that we should make the error reporting defaults reflect what an admin would want to use. We could apply dev defaults if host url is localhost or 127.0.0.1.

Note that this PR just changes the default, there is no automated "dev" settings for localhost atm as I didn't think it is really necessary. Let me know if you think I should actually implement that.

TagsNo tags attached.

Activities

dregad

dregad

2014-07-14 05:51

developer   ~0040918

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

dregad

dregad

2014-07-16 14:01

developer   ~0040930

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

dregad

dregad

2014-08-11 11:37

developer   ~0041044

Reminder sent to: atrol

Following up on your comment in the PR [1]

Isn't it some kind of security issue if this is the default setting for localhost?
Every user working on the same server will use the settings.
It's better to change it only if needed in config_inc.php.

I don't really see how it can be a security issue in a "real" scenario - by definition localhost is "this computer". Users would never be running browser sessions on the web server itself...

Am I missing something ?

I hope you will revert the behavior

I think it's really a useful feature for developers, so I don't think it should be reverted, unless there is indeed some security issue that I overlooked.

if not you should consider also IPv6.

Forgot about IPv6, that's a good suggestion. I'll add that.

[1] https://github.com/mantisbt/mantisbt/pull/215#discussion-diff-16026977

atrol

atrol

2014-08-11 12:50

developer   ~0041045

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.

dregad

dregad

2014-08-12 03:59

developer   ~0041049

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.

dregad

dregad

2014-08-12 03:59

developer   ~0041050

Reminder sent to: vboctor

Victor, it would be good to have your opinion on this.

vboctor

vboctor

2014-09-17 00:24

manager   ~0041231

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.

atrol

atrol

2014-09-18 10:39

developer   ~0041244

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.

atrol

atrol

2014-09-18 10:45

developer   ~0041245

Last edited: 2014-09-18 10:45

View 2 revisions

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.

dregad

dregad

2014-09-18 11:34

developer   ~0041246

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.

Related Changesets

MantisBT: master e788e933

2014-07-09 13:27:16

dregad

Details Diff
Revise default $g_display_errors setting

The default now reflects the recommended Production settings, and a
better recommendation for developers is documented in the phpDoc
comment block.

Fixes 0017501
mod - config_defaults_inc.php Diff File
mod - docbook/Admin_Guide/en-US/Configuration.xml Diff File

MantisBT: master ddc78c91

2014-07-16 13:44:36

dregad

Details Diff
Init $g_display_errors with dev settings on localhost

When the server name is localhost/127.0.0.1, we automatically set
$g_display_error to the recommended development values, i.e.

- E_USER_ERROR => DISPLAY_ERROR_HALT
- E_WARNING => DISPLAY_ERROR_HALT
- E_ALL => DISPLAY_ERROR_INLINE

Issue 0017501
mod - config_defaults_inc.php Diff File
mod - docbook/Admin_Guide/en-US/Configuration.xml Diff File

Issue History

Date Modified Username Field Change
2014-07-10 03:58 dregad New Issue
2014-07-10 04:03 dregad Assigned To => dregad
2014-07-10 04:03 dregad Status new => assigned
2014-07-14 05:51 dregad Note Added: 0040918
2014-07-16 14:01 dregad Note Added: 0040930
2014-08-07 18:25 dregad Changeset attached => MantisBT master e788e933
2014-08-07 18:25 dregad Changeset attached => MantisBT master ddc78c91
2014-08-07 18:25 dregad Status assigned => resolved
2014-08-07 18:25 dregad Resolution open => fixed
2014-08-07 18:25 dregad Fixed in Version => 1.3.0-beta.1
2014-08-07 19:25 dregad Target Version => 1.3.0-beta.1
2014-08-11 11:37 dregad Note Added: 0041044
2014-08-11 12:50 atrol Note Added: 0041045
2014-08-12 03:59 dregad Note Added: 0041049
2014-08-12 03:59 dregad Note Added: 0041050
2014-09-17 00:24 vboctor Note Added: 0041231
2014-09-18 10:39 atrol Note Added: 0041244
2014-09-18 10:45 atrol Note Added: 0041245
2014-09-18 10:45 atrol Note Edited: 0041245 View Revisions
2014-09-18 11:34 dregad Note Added: 0041246
2014-12-08 00:34 vboctor Status resolved => closed