Page MenuHomePhabricator

Detect and notify user of extremely low (probably accidental) POST limits
Open, LowPublic

Description

Author: j.boyd

Description:
System Stats:

Ubuntu 6.06 LTS (fresh install)
MySQL 5.0.24a-Debian_9ubuntu2-log
PHP 5.1.6
Apache 2.0.55
MediaWiki 1.10.1

MediaWiki worked fine for about a week, after a week's time user's are no longer able to login, including WikiSysop. No changes occured on the server in terms of configuration in this time. Also had the same problem on another machine running Fedora Core 1 last week, prompting a new server and new OS install. Error message occurs when trying to login or create a new user.

Login error:
You have not specified a valid user name.

I have tried editing isValidUserName in User.php to always return true however the error still occurs. Attempted to reset passwords for users in the database using supplied changePassword.php, however error still occurs. Also attempted creating a new admin via createAndPromote.php, with the same problem occuring.


Version: unspecified
Severity: enhancement

Details

Reference
bz10668

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:50 PM
bzimport set Reference to bz10668.
bzimport added a subscriber: Unknown Object (MLST).

j.boyd wrote:

Modifying php.ini to decrease max_post_size, memory_size, etc to php.ini-dist settings fixed this issue.

As per IRC disussion; most likely cause was an invalid value for post_max_size or memory_limit setting in php.ini:

http://www.php.net/manual/en/ini.core.php#ini.post-max-size

Unfortunately the exact lines in Josh's broken php.ini are no longer available for testing, but this example reproduces the described error:

post_max_size = 1GB

K, M, and G are valid suffixes for shorthand, but KB, MB, and GB are not:
http://www.php.net/manual/en/faq.using.php#faq.using.shorthandbytes

A size specified with 'MB' or 'GB' gets interpreted just in bytes -- 1 byte for 1GB, 1024 bytes for 1024MB, etc. The result can be a much lower limit than intended, which might be hitting the limits on certain or all form submissions.

ayg wrote:

Let's fix that then, shall we?

ayg wrote:

Probably best not to make this only on installation, Rob: the original bug reported issues after the values were changed in production. Since this issue would break essentially every page that's not just a simple article (or some special pages) being viewed, we could consider putting it somewhere in OutputPage as a general check that would print a nasty warning on every page with maybe a couple of special exceptions (e.g., plain article view).

What value would be good to test for? It seems unlikely that nowadays you'd have any legitimate reason to set POST lower than 1M, but 10K wouldn't break anything if you want to use short articles and no uploads, I think. Plus, it's unlikely that someone will enter anything above 10K in the manner described above: 10240KB would be a fairly bizarre thing to type (why not 10M?). I'd err on the side of caution in displaying the message. If it's, say, 5K or 10K before the message appears, and your limit is set to 11K, the problem will only occur when submitting longish pages, which should be easier to troubleshoot in the odd case it does occur.

Four years on, maybe this would be best as a test in the new installer? Just a thought. Assuming it's not been fixed already in some way, of course.

Pppery removed epriestley as the assignee of this task.
Pppery edited subscribers, added: epriestley; removed: wikibugs-l-list.
Pppery removed a subscriber: epriestley.