View Issue Details

IDProjectCategoryView StatusLast Update
0012632mantisbtsignuppublic2014-12-08 00:34
ReportervogtAssigned Todregad 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.2.4 
Target Version1.3.0-beta.1Fixed in Version1.3.0-beta.1 
Summary0012632: Signup with empty username and e-mail is possible when display_errors[E_USER_ERROR] = 'inline'
Description

It's possible to signup to a mantisbt account without enter any username and e-mail address, i.e. leaving both fields empty.

After pressing the "Signup" button two error messages appear on the next page:

"APPLICATION ERROR 0000805: The username is invalid. Usernames may only contain Latin letters, numbers, spaces, hyphens, dots, plus signs and underscores.

APPLICATION ERROR 0001200: Invalid e-mail address."

But then continuing:

"Account registration processed.
[ - ]

Congratulations. You have registered successfully."...

The account is in fact created and it appears in the list of users where you cannot easily remove it as without the user name there is no link to the user page...

Steps To Reproduce

Go to the signup page and don't enter anything into the username and e-mail field. Press Signup (after entering the captcha if activated I guess).

TagsNo tags attached.

Relationships

related to 0015524 closeddregad Incorrect error_reporting value or setting in Apache skips required fields validation in Issue Report 
related to 0016059 closeddregad System should warn users when debug settings are enabled 
related to 0016142 closedatrol User registration accepts empty user name and/or email address 

Activities

atrol

atrol

2010-12-27 03:35

developer   ~0027705

I am not able to reproduce the issue.
I get just the 805 error message, but not the 1200 message.
After that the system stops with message: "Please use the "Back" button ...."

Did you change sourcecode of MantisBT and/or installed any plugins?

vogt

vogt

2010-12-27 03:44

reporter   ~0027706

No. Except for the phpmailer bugfix which I have reported before, I have tested it on the latest 1.2.4 which I have just installed into an empty directory only copying the config_inc.php from 1.2.3. No modifications or plugins or whatsoever.

atrol

atrol

2010-12-27 04:16

developer   ~0027707

Make a backup of file core/user_api.php and temporary add the following line after line 292 of file core/user_api.php
var_dump ( $p_username ); die();

vogt

vogt

2010-12-27 05:31

reporter   ~0027712

I press the Signup button and it shows:

string(0) ""

Nothing else.

atrol

atrol

2010-12-27 06:06

developer   ~0027716

Did you change any error handling related settings?
For example: $g_display_errors

vogt

vogt

2010-12-27 06:12

reporter   ~0027717

Yes:

$g_show_detailed_errors = ON;

    $g_display_errors = array(
            E_WARNING => 'inline',
            E_NOTICE => 'inline',
            E_USER_ERROR => 'inline',
            E_USER_WARNING => 'inline',
            E_USER_NOTICE => 'inline'
    );
atrol

atrol

2010-12-27 06:45

developer   ~0027724

Your settings are just for debugging purposes.
Have a look at the warnings in config_defaults_inc.php for the settings you made.

Please comment your settings in config_inc.php and check if this fixes your issue

vogt

vogt

2010-12-27 09:49

reporter   ~0027729

O.K. That does it. I had those settings (or similar) for a long time. I have always thought they would only adjust how or where PHP errors are displayed, like the PHP display_errors ini option.

Maybe the labeling in MantisBT could be different from what you would know and expect if you knew display_errors in PHP.

Or I think at least a message "Ignoring error, continuing because E_USER_ERROR is set to 'inline'..." would help to understand better what's happening...

atrol

atrol

2010-12-27 10:33

developer   ~0027731

You wrote: "Maybe the labeling in MantisBT could be different from what you would know and expect if you knew display_errors in PHP."
If you know display_errors in PHP you can't think that this is similiar to g_display_errors of MantisBT. diplay_errors of PHP is just a string setting (boolean in earlier version) whereas g_display_errors of MantisBT is an array.
Changing E_USER_ERROR => 'halt' to E_USER_ERROR => 'inline' is something where you have to know what you do.

I agree the name is unnecessary confusion, but this name was introduced many years ago.

I think an enhanced message for E_USER_ERROR is a good idea.
Or even E_USER_ERROR should not be changeable.

atrol

atrol

2010-12-27 10:34

developer   ~0027732

Reminder sent to: dhx

David, what do you think?
Enhancing the message or hardcoding E_USER_ERROR to 'halt'

vogt

vogt

2010-12-27 11:58

reporter   ~0027734

I guess the "confusion" can't be changed anymore.

An enhanced message telling what happens would help to understand it.

The documentation in the default config could be more extensive on this point, too. In particular, because the "inline" setting probably could have security implications which noone really knows when the code continues at a place where it supposed to stop under normal circumstances.

Maybe even a warning message similar to the one warning about the existence of the admin/install directory would be a good idea. A normal mantis installation should not run with this setting. It should be really reserved for debugging purposes and if it is enabled it should be clearly visible.

dhx

dhx

2011-01-07 04:55

reporter   ~0027840

E_USER_ERROR is always meant to be a fatal error. Using anything other than 'halt' is bad here because you're basically circumventing security errors (access denied), etc.

I think it may be best to update the new check script in MantisBT 1.3.x to check if the user has configured $g_display_errors in an undesirable way.

nselina

nselina

2011-03-30 08:36

reporter   ~0028505

I have very similar problem: It's possible to signup to a mantisbt account without enter any username and e-mail address, i.e. leaving both fields empty, but the difference is that after pressing the "Signup" button any error messages don't appear on the next page only success message and I didn't change $g_display_errors settings so mentioned fix do not useful for me, could you advise something please?

nselina

nselina

2011-03-30 12:57

reporter   ~0028511

Problem solved, errors didn't appear because of error_reporting settings set to 0

atrol

atrol

2011-09-15 15:44

developer   ~0029736

Assigned to David according 0012632:0027840

dhx

dhx

2011-09-16 05:15

reporter   ~0029743

Thanks atrol.

Not-yet-concrete thoughts for the 1.3.x branch:

$g_display_errors won't exist in 1.3.x because every error is 'fatal' unless they are caught and handled by the code.

It should also be quite safe to override PHPs built-in error reporting sensitivity for MantisBT so that it triggers a fatal error for all unexpected errors. There is nothing to be gained by having this set as a user-adjustable setting.

Saying this - there could quite easily be new error options in 1.3.x if the need arises.

atrol

atrol

2013-04-27 18:32

developer   ~0036703

Removed assignment. dhx will not contribute to this issue in near future.

dregad

dregad

2013-06-14 15:08

developer   ~0037197

dhx's comments in 0012632:0027840 have been addressed in my local 13x branch, which I'll push to github shortly, by displaying a warning on the login page, as well as in the admin checks.

Same goes for vogt's 0012632:0027734 (regarding an additional warning when displaying E_USER_ERROR inline).

Related Changesets

MantisBT: master 71b8dc96

2013-06-14 20:48:06

dregad

Details Diff
Admin Checks should warn when debug settings are used

This implements the same logic as on the login page.

Fixes 0016059, 0012632
mod - admin/check/check_config_inc.php Diff File

Issue History

Date Modified Username Field Change
2010-12-27 03:18 vogt New Issue
2010-12-27 03:35 atrol Note Added: 0027705
2010-12-27 03:35 atrol Status new => feedback
2010-12-27 03:44 vogt Note Added: 0027706
2010-12-27 03:44 vogt Status feedback => new
2010-12-27 04:16 atrol Note Added: 0027707
2010-12-27 04:16 atrol Status new => feedback
2010-12-27 05:31 vogt Note Added: 0027712
2010-12-27 05:31 vogt Status feedback => new
2010-12-27 06:06 atrol Note Added: 0027716
2010-12-27 06:06 atrol Status new => feedback
2010-12-27 06:12 vogt Note Added: 0027717
2010-12-27 06:12 vogt Status feedback => new
2010-12-27 06:45 atrol Note Added: 0027724
2010-12-27 06:45 atrol Assigned To => atrol
2010-12-27 06:45 atrol Status new => feedback
2010-12-27 09:49 vogt Note Added: 0027729
2010-12-27 09:49 vogt Status feedback => assigned
2010-12-27 10:33 atrol Note Added: 0027731
2010-12-27 10:34 atrol Note Added: 0027732
2010-12-27 11:58 vogt Note Added: 0027734
2011-01-07 04:55 dhx Note Added: 0027840
2011-03-30 08:36 nselina Note Added: 0028505
2011-03-30 12:57 nselina Note Added: 0028511
2011-09-15 15:44 atrol Note Added: 0029736
2011-09-15 15:44 atrol Assigned To atrol => dhx
2011-09-15 15:44 atrol Target Version => 1.3.0-beta.1
2011-09-16 05:15 dhx Note Added: 0029743
2013-02-21 02:48 atrol Relationship added related to 0015524
2013-04-27 18:32 atrol Note Added: 0036703
2013-04-27 18:32 atrol Assigned To dhx =>
2013-04-27 18:32 atrol Status assigned => new
2013-06-14 14:44 dregad Relationship added related to 0016059
2013-06-14 15:08 dregad Note Added: 0037197
2013-06-14 15:08 dregad Assigned To => dregad
2013-06-14 15:08 dregad Status new => assigned
2013-06-14 15:09 dregad Summary Signup with empty username and e-mail is possible => Signup with empty username and e-mail is possible when display_errors[E_USER_ERROR] = 'inline'
2013-07-05 02:32 atrol Relationship added related to 0016142
2013-10-11 23:23 dregad Changeset attached => MantisBT master 71b8dc96
2013-10-11 23:23 dregad Status assigned => resolved
2013-10-11 23:23 dregad Resolution open => fixed
2013-10-11 23:23 dregad Fixed in Version => 1.3.0-beta.1
2014-12-08 00:34 vboctor Status resolved => closed