[codex] Some symbols are not allowed in password

[wikicms]

In note, below password fields on profile page (forum) shows symbols allowed to create strong password like !"?$%^&(

But when I try login into Codex and typing in password field symbols like ",',\ (double qoute, single qoute, backslash) symbols not accepted and I can't login.

[Otto42]

This is a MediaWiki limitation, I believe.

Note that SVN has limitations on password symbols too, which don't jive with WordPress's limits here. It's equally possible to make a password on the forums which won't let you update things in the plugins SVN.

Not much we can really do about it except to make those symbols not allowed everywhere, most likely, and I don't think that is reasonable. Not everybody needs to log into the codex or push updates to the plugin SVN.

[SergeyBiryukov]

Could we describe these MediaWiki and SVN limitations somewhere and probably add a link near the hint on forum profile pages, so that users won't have to guess why they can't log in to Codex with a valid forum password?

[wikicms]

If there is no possibility to change the limitations of symbols in passwords Codex or SVN, I also think, like SergeyBiryukov. Because I lost about 4 hours to find what is the problem. And another hour to find "forbidden" symbols.

[nacin]

I'm not aware of any password limitations for our SVN setup.

For the Codex, ​https://code.trac.wordpress.org/browser/mediawiki-wpauth/WPAuth.php seems like it should handle special characters fine. Perhaps the issue is magic quote-related?

[Otto42]

I'm fairly certain that passwords with percent % symbols in them fail for SVN. Perhaps some others. Somebody once told me caret ^ fails too.

The issue with the codex may indeed be magic quote issues if only those three characters are the problem ones.

[nacin]

I had no issue running an authenticated SVN command with a password that started with % and ended with ^.

For those who don't know, we use a modified version of mod_auth_mysql for SVN: ​https://code.trac.wordpress.org/browser/mod_auth_mysql.

[Otto42]

The SVN thing is a real problem, but it isn't something I think we can solve. And while it worked for you, it definitely does not for others. Multiple reports over the years, telling them not to use strange characters in the password works every time.

The problem is that the issue with SVN is client and locale dependent. Some clients don't take character sets into account, basically. Tortoise in particular has had this issue in the past, specifically with non-US users. Other SVN clients will have various issues depending on the local character set in use.

For example, some people tend to type a lot of umlauts, and when the encoding we use doesn't match the encoding they use on the computer where their SVN client is, well, there you go. Some SVN clients just send the binary data, not caring about the character encoding. The world still has not all gone over to Unicode.

Regarding the codex, I don't have server level access, but the first thing to check is if it is indeed using magic quotes.

[iandunn]

I ran into this today after resetting my password yesterday. I could log in to WP installs, but couldn't commit to plugins.svn. I was able to commit again again after resetting to a new password. I'm just using the standard command line client (version 1.8.1) on OS X, with everything in English.

I ran a series of tests to isolate the characters causing the problem and found that both ' and " blocked me from committing.

Not much we can really do about it except to make those symbols not allowed everywhere, most likely, and I don't think that is reasonable. Not everybody needs to log into the codex or push updates to the plugin SVN.

Given the alternatives, that doesn't seem unreasonable to me. It's a lot simpler that expecting the tens of thousands of codex/plugin users to realize that the reason they're having problems is because of a password they created months/years ago, especially when that password has been working for them on all other parts of the network, and especially if it's their first time creating a plugin and they're not sure if they have their SVN client setup correctly to begin with. Even if they do realize their password is the problem, they then have to find and avoid the breaking characters by trial and error.

Either way we're going to frustrate some group of people. The choice is between a minor annoyance for a large number of people, or a very frustrating experience for a small group of people. Personally, I think the former is better than the latter. We should be encouraging people to use randomly generated passwords anyway, so in that case there's nothing special about any individual character, so they won't care if they can't use it.

If we don't want to do that, though, what about displaying a warning to the user that using ' and " will prevent them from committing to the plugin repo? If we don't want most users to see it, we could have JS only display it if an ' or " is detected.

[samuelsidler]

I talked to @stephdau about this earlier.

Let's punt on this for the Codex and, instead, introduce OAuth for it, once we have that working on WordPress.org. It'll be weird in that no other WordPress.org site will use OAuth, but it'll make it easier for the time we have left with the Codex.

[obenland]

@jonoalderson suggested HTML5 validation on the password field, with a crafted pattern for these characters to at least avoid it for new passwords

[dd32]

I'm marking this as wontfix - The codex is on it's way out as all content gets migrated to HelpHub and DevHub (​https://wordpress.org/support/ and ​https://developer.wordpress.org/)

While this isn't a great bug, it affects so few people that it's not worth fixing the authentication plugin.