Increasing the size of the users.username field

Hi,

We are migrating our journal users into an OJS 3 instance. We generally use only email address as username. Lots of our users have an email address which is longer than 32 characters but the users.username field is varchar(32).

If I increase users.username to varchar(255) there appears to be no problem with normal OJS functioning.

So why the limitation on users.username? We thought it might be because longer names could break the formatting of the UI. Or maybe it is a limitation imposed by automated access to an external resource.

Can you please tell me why users.username is limited to varchar(32)?

Many Thanks,

Hi @jp_ecancer,

The short answer is that usernames are currently limited to varchar(32) because that’s been enough; this is the first time a longer username has been requested, I think.

Note that I don’t think emails will be permitted because usernames are currently limited to /^[a-z0-9]+([\-_][a-z0-9]+)*$/ (see lib/pkp/classes/form/validation/FormValidatorUsername.inc.php).

See The username must contain only lowercase letters, numbers, and hyphens/underscores. · Issue #906 · pkp/pkp-lib · GitHub for a proposal to change this.

In the meantime, extending the username column won’t cause problems, but be careful to ensure that the XML-based descriptor for the users table (in lib/pkp/xml/schema/common.xml) contains the extended length – otherwise when you run the upgrade script or otherwise sync the descriptor the contents of that field will be chopped off at the length specified there.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,

This is very helpful, thank you. It sounds like we could go ahead with lengthening users.username with those two modifications for our local instance.

Could you please clarify your comment: “we might also reconsider our separation of usernames and emails; I’ve fought against this before but I’ll concede that I find that approach useful.” ? How do you find that approach useful?

Regards,

@jp_ecancer

Hi @jp_ecancer,

It’s just a matter of changing conventions. When we first released OJS, it was common practice to have usernames and emails kept separate; I was hesitant to stray from that. Now it’s very common for the email address to serve as both, and it’s also standard practice for third-party authorization toolsets.

Regards,
Alec Smecher
Public Knowledge Project Team

I wouldn’t want to require that the username be the email, but I think the administrator should be able to require that if desired.

Perhaps a good solution would be to extend the size of the username field, drop the validation from core, and provide a plugin which optionally adds validation based on a set of pre-filled regexps or a user entered regexp.

If considered valuable, I have a student assistant who could probably knock that right out.

1 Like

Thanks for the comments and suggestions.

I wonder what happens when people register and if/when they want to change their email address or username.

If I make the the username and email address the same, then the same email validation should be applied to both fields and it would need to match my users’ emails (which are quite varied including the use of hyphen). It may be better if the user does not realise they have a username separate from their email in which case several UI changes would be required. The registration form would lose username. The two fields may need to be tied together somehow in the database and logic so that should one change the other changes too.

Also, currently, I don’t see a way for a user to change their username after registration. Is it usual not to be able to change your username? The username is fairly restricted in size and form - does this give a better target for a hacker due to the reduction in number of permutations?

Thanks,

@jp_ecancer

I just want to document our solution to this issue:

  • we have retained the username field as it already is;
  • we are synchronising our users from our main application with the OJS username being user_{id} where {id} is the id from the main application;
  • we have a callback which allows users to log in using either their email address or their username;
  • we have widened the space in the form to make it easier for users with long email addresses;
  • we are making use of 1-click URLs allow users direct access into OJS from our main application.

At some point we will probably modify the user interface so users see their email address rather than their username at the top right. At the moment it provides a useful check.

Thanks,

@jp_ecancer