No support for apostrophes in user names

It occurs on 5.x versions too, and likely 6.x and beyond until fixed.

Anyone have a resolution for this yet?

subscribing (have a boss with an Irish surname, who want this sorted).

Hi,

I know that there is a function in MySQL for the special characters. Specially this one, mysql_real_escape_string. I have also read somewhere that the functionality magic_quote is sometimes active on the server. I think that you can see if they are active with this function get_magic_quotes_gpc and try to change it. Hope this will help.

julien: I don't think that we should use mysql_real_escape_string, as not everyone uses MySQL as their backend database. We'd need something database agnostic, even if it wraps mysql_real_escape_string for MySQL users or another function for Postgre users.

Thing is, the solution isn't that tough, the problem is where does it go?

Scratch that, it's user_validate_name that we want to edit. Specifically, the ereg call around line 252 in user.module, which should include an apostrophe thus designating it a legal character. I'd make a quick patch were I on a machine that I could do development work with. Unfortunately I'm not, so I'll leave that to someone else. Then we can start checking if we need to put in escaping at the database layer or earlier.

have added two regex, so i can enter O'reilly but not O''reilly or O'r'eilly, but it's not really complete now. The second regex is not exact and miss a string like this "O'reilly[".

Rather than add two additional regexen, what's wrong with adding a tick to the one on the line I suggested and an additional one after checking that there aren't any doubled ticks? Also, let's leave this as 5.x-dev since the problem is in the 5.x stream as well. Once there it'll all but automatically slip into newer releases anyway.

I'll try out your patch and I'll have a new one either tonight or tomorrow.

Hi there,

As you said, i have modified the regex and add the quote. But it has to be review, it's working for O'reilly, O'r'eilly, not for O'[reilly.
I have the 6.xdev, and the user.module did'nt accept O'reilly that's why i purpose this patch.

Hi,

I tried Julien's patch which now makes it possible to have the apostrophe in the username, but Drupal links to the Username's blog will still not recognise the apostrophe, so for example a link to:

Tim O'reilly's blog

becomes:

Tim O'reilly's blog

Anyone else seeing this problem?

oops, Drupal is correcting the rendering on the forum. it should look like:

Tim O&#039reilly's blog but with an extra ; after the 9.

We need to know the reasoning for username chars being so restricted - i doubt it's a db problem, as drupal's handling of strings is kickass, and doesn't need things like magic quotes.

Why is drupal's usernames restricted to \x80-\xF7 [:alnum:]@_.- ???? Is the reason still valid?

The Drupal username is a "screen name" it isn't meant to cover all possible characters in people's names. If you need a full name field, look at profile.module.

I'm not sure how using the profile module would solve the problem of people not being able to have a blog in their actual name. Am I missing something?

If it's of any use, I recently overrode the theme_username function to display custom usernames.
If the name is stored correctly in the DB, perhaps a theme function could output it correctly.
Nevertheless, something like this may best reside in the core codebase rather than at the theme layer.
If anyone's interested, with PHPTemplate you can add a function to your template.php file:

<?php
/**
 * Returns themed username as string
 * @param object $object
 * node object or user object
 * @param boolean $link
 * return a hyperlink username
 */
function phptemplate_username($object, $link = TRUE) {
....
//get the username
//return string

}
?>

it was always presumed that the username is not safe so i see no secholes in supporting this. I am not fond of Julien's patch, there is already a regex, change that, do not add another especially not with ereg which is old and slow. #11/12 seems to be another issue -- you say that we double escape usernames? that's not good. Please submit a better patch and investigate the double escape.

subscribing

I had an issue a while ago where I imported a load of users from phpbb and users who have apostrophes in their names were locked out (because they were trying to log in with their non-stripped name). So big +1 from me.

I just want to keep this thread warm as I'm still keen to have my users have their real names with apostrophes. I would consider this a basic expectation and hope that we can have this fixed soon. I'd be happy to test patches, etc., unfortunately I don't know enough about the relationship between the user.module and the rest of core to figure out why this is happening.

As mentioned above, the patch for the user.module part of this will allow a username to pass with apostrophes, but the blog name and resultant rss feed, etc. will still come out garbled. If anyone can at least point us to some possible places to look that would be helpful.

Here is a patch that solves the issue with apostrophe in names in feeds and in blogs, in addition to allowing users to register with names like O'Mally and O'Reilly.

Drupal 5.x and HEAD versions provided.

Apostrophe, Can I use the above patch to fix issues in a users "personal information" profile. Let's say I have a user with the username of "XYZ42" but when they edits their personal profile with a first name of Joe and last name O'Something I get "Joe O'Something"

I guess my question is will this patch fix all instances of Apostrophes?

Thanks

brent85_98: why not try it?

Short answer: try it, as catch said.

Long answer: the patch is two parts:

1. Allow user names to have an apostrophe in it. So a user can register with O'Connor, O'Reilly, ...etc.

2. Displays the apostrophe as apostrophe, not as an HTML escaped entity. That part is not specific to user names and will apply to all strings.

I would like to see this patch get in, but I think that because the description text 'Spaces are allowed; punctuation is not allowed except for periods, hyphens, and underscores.' would need to be changed that the string freeze deadline may push this into 7.x territory.

I recently imported a lot of user information and chose to use their full names for usernames rather than make up arbitrary usernames for them. The inability to have apostrophes messed up a lot of names. Considering that foreign characters are allowed in usernames, certainally apostrophes should be allowed too.

I'd like to see this fixed too. AP had a news story on the subject of apostrophes yesterday, btw.

http://news.yahoo.com/s/ap/20080221/ap_on_hi_te/apostrophes_in_names

Rerolled for 7.x, and corrected the help text to include apostrophes.

I would like to confirm that this works on Drupal 6.1 Even if no new users are allowed with apostrophes, existing users (those imported from other systems) should be supported and IMO atleast that part of the patch to check_plain function in bootstrap.inc is a no brainer.

(My particular problem was unsightly breadcrumbs and links to the user's blog: http://drupal.org/node/228951)

Thanks Khalid. This patch works great on our 5.x installation.

Atleast two people have tested this and confirmed it to work. Is it time to make it RTBC? if not, please reset.

It's a very minor change which fixes a very annoying issue (I ran into this specifically when importing some users from phpbb back in 4.7 - where a couple of users were unable to log in due to their cleaned up user names and had to contact me directly). Patch looks sane, string changes are good etc. +1 from me.

Just added this patch to my 5.7 and it works great. Nice and pretty.

um, looks good except why pass ENT_NOQUOTES rather than ENT_COMPAT to htmlspecialchars()?

http://www.php.net/manual/en/function.htmlspecialchars.php

subscribe

Let's write a test case for this. Thanks!

I've merged kbahey's patch with my code cleanup of user_valid_name() (and added the test) at http://drupal.org/node/266488#comment-870874

In that case, I guess this issue should be made rtbc for Drupal 6.x

Patches are applied to the development version, then to 6.x unless there's a good reason not to, to keep the versions in sync as much as possible.

Additionally, there's no simpletest in core for 6.x, so this wouldn't apply there anyway and will need to be backported if that's an option.

The patch for 7.x has been rolled into the issue linked in comment 38 (Cleanup for user_validate_name() + tests).

Sorry about being too early. I guess this will need to be set to Drupal 6.x AFTER that has been committed to 7.x

Sorry, my mistake. Completely the wrong issue, I thought we were on the other one. However I don't think there's an RTBC patch for 6.x here is there?

patch in comment #28 is what I have used and tested previously (on both 6.1 and 6.2).

Also posted on #266488:

Using ENT_NOQUOTES or ENT_COMPAT allows values to 'run out' of attribute values:

Consider:

$output = '<tag attribute="'. check_plain($somevalue) .'" />';

Now, suppose $somevalue is 'foo" onerror="javascript:evil_js()" '

You'll get:

<tag attribute="foo" onerror="javascript:evil_js()" />

In HTML 4, attributes may be delimited by either single or double quotes. Single quotes may be used unencoded in attribute values when the value is surrounded by double quotes and vv. As check_plain has no information about which quotes are used to embed something we need to play it safe and cater to both delimiters.

So, ENT_QUOTES needs to be kept. Rather, as chx wrote, investigate and fix the double encoding.

Fixed here: http://drupal.org/node/266488

double escaping in check_plain has an issue here: http://drupal.org/node/275308

Is this confirmed? #266488 is marked as active, and #275308 is marked won't fix. Is there something actually committed to CVS that fixes this? I see that commit 123728 updates user.test, but that doesn't change user.module.

That is an incomplete commit.

I think this should be marked as a duplicate of http://drupal.org/node/266488, and that patch (plus more) be backported to Drupal-6 since the approach in this issue is deemed insecure.

If #266488 does solve this bug as well, then I'm all for it.

http://drupal.org/node/266488 allows for usernames for apostrophes.

http://drupal.org/node/276174 fixes the display of usernames in the blog module.

I don't think there are other areas where the username display was broken, so them to cover this issue. Marking as duplicate.

For those following at home, I need help in #276174: Do not check_plain() usernames more than once to find out where the names are "check_plain"ed. Otherwise this bug/feature will go unsolved until Drupal 7 which is a ways off.