Jump to content

Recommended Posts

I want to accomplish two things: save some server overhead and create a friendlier user experience.

Thus, prior to form submission, the user should have the opportunity to check whether the chosen username is available.

As I've begun researching the topic, I've discovered AJAX, Vue, and XMLHttpRequest alternatives.

 

Any suggestions and alternatives that would give me guidance would be appreciated.

 

Additionally, are there any characters that should be expressly prohibited from use in a username (or other input field) that could aid malicious hackers in causing harm to my website, database, and files?

 

 

Link to comment
https://forums.phpfreaks.com/topic/312045-is-username-available/
Share on other sites

15 minutes ago, phppup said:

I want to accomplish two things: save some server overhead and create a friendlier user experience.

Thus, prior to form submission, the user should have the opportunity to check whether the chosen username is available.

As I've begun researching the topic, I've discovered AJAX, Vue, and XMLHttpRequest alternatives.

 

Any suggestions and alternatives that would give me guidance would be appreciated.

 

Additionally, are there any characters that should be expressly prohibited from use in a username (or other input field) that could aid malicious hackers in causing harm to my website, database, and files?

 

 

I would personally just do it silently with an unique constraint in MySQL and not advertising it too much to users. The more you broadcast it or let it be known that an username exists the more like they will attack your website. I'm not saying NOT to do it, but simply say "username can't be used at this time", "Choose a different username" or something more vague than that after the user attempts to registers. It's usually not that big of deal having to come up with a different username as you can save all the other registration info (except password) back on the HTML form as a convenience to the user.  That's what I do.

Edited by Strider64

That sounds a tiny bit contradictory.

I mean, changing a message is simple enough, but the end result will be the same.

Wouldn't a simple user be unfazed by the terminology?

Wouldn't a seasoned hacker read right through the thin veil?

Is this REALLY something to stay away from?

Please also address my other questions within the post.

Are there characters or names that users should find unavailable. Is it safe to allow a user access to the name ADMIN? Or PHP? etc.

And what about code alternatives? Which are best? Which to avoid?

Edited by phppup
Forgot item

There are plenty of sites that will tell you if the username you're choosing is unavailable - I'm pretty sure github does this, but it's been a while so I could be wrong. While I agree that if you're making the user hit submit with both password and username, don't tell the user whether it's the username or password that's incorrect; however if your goal is to let the user know before they hit send, you're gonna have to do it. As for usernames of 'PHP' or 'admin', you shouldn't be using that alone to determine capability to begin with. Hopefully your system has not only password protection, but roles to disallow major system changes from all but specific users. So in the grand scheme of things, it doesn't really matter what the user name is as long as it's not 'Little Bobby Tables' and/or you use prepared statements to protect against SQL-injection and avoid using exec(). Use AJAX to check for the username after it's been entered and let the user know if it's not available. Just make sure the passwords are strong - there are some libraries and information available if you Google.

This IDEA would be implemented in a REGISTRATION form, NOT a sign in.  The effort is strictly for user convenience to allow someone to check whether a username is available before completing additional steps to register.

As for Little_Bobby_Tables, I would think that underscores in a name are harmless (and acceptable). So it's not about the name, but the additional characters that should be disallowed.

My concern is the overall safety and security of the website, and NOT compromising it for user convenience.

As for password strength, how much of that burden should be placed on the user?  If a user wants a weak password (and knows it is weak), is there a reason that I should not allow it to be acceptable?

 

Edited by phppup
Typos

regardless of what you do to pre-check the username, from the point in time when you pre-check if the username is available, to the point where the user actually submits the form, someone else could have submitted the same username and it is no longer available. your database table must enforce uniqueness, by defining the relevant column(s) to be unique indexes. you must then have error checking for the INSERT query to detect if a duplicate was attempted to be inserted, and report back to the user if the username already exists.

Yup. Already realized that, and appreciate the insight.

But aside from a message/disclaimer advocating that the user "Hurry before the name is removed" there's really not much else to be done.

[I suppose I could INSERT the name immediately and DELETE it if registration isn't completed within a given timeframe, but that seems like a lot of work in the babe of "convenience"... LOL]

I guess the overriding questions are still: is it worth the effort? Does it compromise the website's security?

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.