[RFC|Merged] Request Class

[igorw]

http://github.com/igorw/phpbb3/compare/ ... uest-class

[bantu]

There are remaining accesses to $_COOKIE that have to be converted.

[nickvergessen]

I just used $_POST and got this error-message:

Code: Select all

General Error
Illegal use of $_POST. You must use the request class or request_var() to access input data. Found in E:\phpBB-development\htdocs\phpBB-git\3.1\phpBB\includes\mcp\mcp_main.php on line 664.
This error message was generated

The last sentence is ... it's really confusing me I didn't even know, that error-messages have to be generated, I thought they were just there?!

[bantu]

Looks like an incomplete sentence. At least I think it wasn't intentional because punctuation is missing.

Code: Select all

afischer@miraculix:/var/www/projects/phpbb3 (develop) phpBB $ grep "This error message was generated" . -R
./includes/request/deactivated_super_global.php:		$message = 'Illegal use of $' . $this->name . '. You must use the request class or request_var() to access input data. Found in %s on line %d. This error message was generated';

[naderman]

I believe the thinking behind that was that PHP itself outputs a file name and line number, but they would reflect that piece of code triggering the error instead of the file and line having actually caused the issue. But apparently your PHP does not output those?

[igorw]

https://github.com/phpbb/phpbb3/pull/92

[naderman]

That was actually intentional so that the standard PHP output which appends file and line number would say generated in file xyz on line abc ... I guess this doesn't always work?

[igorw]

I'm always getting an error message that ends with 'This error message was generated'. PHP 5.3.3.

[bantu]

Would it make sense to get rid of trim() in set_var? See for example http://tracker.phpbb.com/browse/PHPBB3-8713

[Oleg]

Mysql does trimming, with that in mind maybe we should keep it.

How about adding a 'password' (or 'raw') field type which will not be trimmed?

My guess is that trimming the username is still ok. Practically speaking, on most installations if someone entered a space before their username by accident I would expect them to want to be logged in anyway, and for those installs where it matters the admin could patch the code to use the password field type for username as well.