Opened 10 years ago

Closed 3 years ago

#277 closed defect (bug) (wontfix)

[codex] Some symbols are not allowed in password

Reported by: wikicms's profile wikicms Owned by:
Milestone: Priority: normal
Component: Codex Keywords:


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.

Change History (15)

#1 @Otto42
10 years ago

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.

#2 @SergeyBiryukov
10 years ago

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?

#3 @wikicms
10 years ago

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.

#4 @nacin
10 years ago

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

For the Codex, seems like it should handle special characters fine. Perhaps the issue is magic quote-related?

#5 @Otto42
10 years ago

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.

#6 @nacin
10 years ago

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:

Last edited 10 years ago by nacin (previous) (diff)

#7 @Otto42
10 years ago

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.

#8 @samuelsidler
10 years ago

  • Summary changed from Some symbols are not allowed in Codex password. to [codex] Some symbols are not allowed in password

#9 @samuelsidler
10 years ago

  • Component changed from General to Codex

This ticket was mentioned in IRC in #wordpress-meta by sams. View the logs.

10 years ago

#11 @iandunn
10 years ago

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.

#12 @samuelsidler
8 years ago

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 It'll be weird in that no other site will use OAuth, but it'll make it easier for the time we have left with the Codex.

This ticket was mentioned in Slack in #meta by obenland. View the logs.

6 years ago

#14 @obenland
6 years ago

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

#15 @dd32
3 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

I'm marking this as wontfix - The codex is on it's way out as all content gets migrated to HelpHub and DevHub ( and

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

Note: See TracTickets for help on using tickets.