Skip to:
Content

Opened 4 years ago

Closed 2 years ago

Last modified 2 years ago

#2207 closed enhancement (fixed)

Login with capital letters on registration

Reported by: motomac Owned by:
Milestone: 1.6 Priority: normal
Severity: normal Version:
Component: XProfile Keywords: has-patch
Cc:

Description

If user enters his login with capital letters on registration like "Alex", BP rejects it with error.
I think, BP should automatically change letter case.

Attachments (2)

2207.01.patch (574 bytes) - added by boonebgorges 2 years ago.
2207.02.patch (979 bytes) - added by boonebgorges 2 years ago.

Download all attachments as: .zip

Change History (25)

comment:1 johnjamesjacoby4 years ago

BuddyPress currently mirrors how WordPress works in this regard. It's possible there is room for improvement here, but for now it does things the WordPress way.

comment:2 crashutah4 years ago

The problem is that WordPress hasn't given much thought to the users I think because most WordPress users don't have people creating lots of accounts. Some sort of BuddyPress solution to allow uppercase would be great.

The other solution I’ve considered is to have some javascript function that will check the username to make sure 1. it’s available 2. that it’s lowercase and 3. Any other validation. At least a notification before they click submit would be a sufficient user experience. Certainly could be done as a plugin or theme, but would be a nice part of the core.

comment:3 r-a-y4 years ago

It looks like it's quite easy to support uppercase characters.

Replace the first preg_match line in the bp_core_validate_user_signup() function so uppercase characters match.

preg_match( "/[a-zA-Z0-9]+/", $user_name, $maybe );

Untested, someone give it a shot.

comment:4 crashutah4 years ago

I tried the suggest r-a-y offered and it's still causing the error for uppercase. I wish I understood regular expressions better to know why it wasn't working.

comment:5 r-a-y4 years ago

sanitize_user() appears to be the blocker. It's utilized in validate_user() and there's a bunch of weird things happening in sanitize_user(). Will need to look into this.

This will work in the meantime. Add this to your theme's functions.php:

function my_sanitize_user( $username, $raw_username, $strict ) {
	$username = $raw_username;
	$username = wp_strip_all_tags( $username );
	$username = remove_accents( $username );
	// Kill octets
	$username = preg_replace( '|%([a-fA-F0-9][a-fA-F0-9])|', '', $username );
	$username = preg_replace( '/&.+?;/', '', $username ); // Kill entities

	// If strict, reduce to ASCII for max portability.
	if ( $strict )
		$username = preg_replace( '|[^a-z0-9 _.\-@]|i', '', $username );

	// Consolidate contiguous whitespace
	$username = preg_replace( '|\s+|', ' ', $username );

	return $username;
}
add_filter( 'sanitize_user', 'my_sanitize_user', 100, 3 );

comment:6 crashutah4 years ago

I tested that r-a-y and it works well. I also tested the login with various versions of CAPS and no CAPS and the login to WP/BP doesn't do any checking for case against the username. So, I could login as Admin or ADMIN or admin and they are all seen as the same user.

I also tried to register a user with the same name, but various versions of capital letters and the signup appropriately recognized all of the various usernames as the same username regardless of case.

comment:7 DJPaul4 years ago

  • Type changed from defect to enhancement

It is like this because WordPress enforces lower-case usernames in its registration. It'd be useful if someone could confirm/reject that statement on WordPress 3.0 (without BuddyPress).

comment:8 crashutah4 years ago

I tested with no BP on WP 3.0 and it doesn't enforce the lower-case requirement. However, I tested it on WP 3.0 Multisite (MU) and it enforced the lower-case requirement.

comment:9 DJPaul4 years ago

Thanks -- that'd explain it, as BuddyPress used to require WPMU (as I'm sure you know).

comment:10 crashutah4 years ago

To round out the testing, I tried to create an account with WP 3.0 standard install and BuddyPress and it enforced the lower-case requirement. So, it looks like BuddyPress is taking the WPMU defaults instead of the WP regardless of what's installed. Which as you said kind of makes sense because BP used to require WPMU.

So, I guess the core question is why did WPMU require it to be lowercase? I assume it was because they used the username for the blog name and so they wanted to make sure it was lowercase for the blog? Seems like something like r-a-y's solution should even solve that since it just basically converts any login to lowercase.

comment:11 boonebgorges3 years ago

If you allow uppercase, do you also allow for boonebgorges in addition to BooneBGorges? Or do uniqueness-checks continue to ignore case?

comment:12 DJPaul3 years ago

I think bp_core_validate_user_signup() needs to be rewritten to be a bit smarter, and try to hand-off to WP's register_new_user() or wpmu_validate_user_signup() appropiately. BuddyPress shouldn't worry about validating usernames.

comment:13 crashutah3 years ago

I agree that bp_core_validate_user_signup() should be smarter, but I think it's a bad plan to have it hand-off to the WP user creation functions. I say this because WP doesn't care too much about user creation, but it's absolutely essential to BP.

comment:14 r-a-y3 years ago

  • Keywords close added; registration capital letter removed

News from plugin-land: Sergey has packaged up a variant of the code above with BP signup validation checks here:
http://code.google.com/p/l10n-ru/downloads/list?can=2&q=allow

Proposal to close in the meantime?

comment:15 boonebgorges3 years ago

  • Milestone changed from 1.3 to 1.4

It's worthwhile to revisit this issue (even if there is a plugin for it - it strikes me as an unnecessary restriction by BP) but not for 1.3.

comment:16 InterMike3 years ago

  • Severity set to normal

If I register via /wp-login.php?action=register I can use a capital at the beginning of my username, PLUS I'm able to avoid all required profile fields I've set in BuddyPress that are shown on /register. But on /register, you can't use a capital to begin your username. But, the above little plugin works, though (1.5-beta-2). Oh, and shouldn't /wp-login.php?action=register redirect you to /register? :S. (Should I create a new ticket for the register issue?)

comment:17 boonebgorges3 years ago

Oh, and shouldn't /wp-login.php?action=register redirect you to /register? :S. (Should I create a new ticket for the register issue?)

Yes it should, and yes you should.

comment:18 DJPaul3 years ago

  • Keywords needs-patch added; close removed

This would be nice to get in 1.6 as it's a long standing issue, and the behaviour is different depending on multisite or not.

comment:19 boonebgorges2 years ago

  • Keywords has-patch added; needs-patch removed
  • Priority changed from major to normal

2207.01.patch removes the lowercase restriction in BuddyPress. This leaves username validation to WP. That means that you can have BooneBGorges in WP single, but not in MS. That's because of http://core.trac.wordpress.org/browser/tags/3.2.1/wp-includes/ms-default-filters.php#L21 (line 21).

IMO, this is as far as BP should go. As DJPaul points out, BP has no business validating usernames. If you're unhappy with the lowercase restriction in MS, you can either petition WP to remove the restriction in WP core (see #WP17904) or you can
remove_filter( 'sanitize_user', 'strtolower' );
in a plugin.

boonebgorges2 years ago

comment:20 boonebgorges2 years ago

2207.02.patch removes BP's username checking altogether (probably preferable).

boonebgorges2 years ago

comment:21 DJPaul2 years ago

Let's go with 2207.0.2.patch. It's not going to cause any regression.

comment:22 boonebgorges2 years ago

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

(In [5443]) Removes BP's rudimentary username sanitization during registration, falling back on WordPress core functions. Fixes #2207

comment:23 boonebgorges2 years ago

I've marked this as resolved. If you have further requests for how usernames should/shouldn't be sanitized, see the WP ticket linked above (#WP17904)

Note: See TracTickets for help on using tickets.