views:

239

answers:

7

I can't believe this - someone actually created two accounts on my social networking website using the same email even though there are both server sided as well as client sided validation checks that prevent such a thing from happening. But get this the time noted in the creation of both the accounts are exactly the same time.

For some reason I'm doubting that this was possible using the forms or any interface - however I'm more than curious to find how did this happen? Anyone have any ideas here?

+4  A: 

You should have set a unique constraint on the email or username column of the users table.

Alan Haggai Alavi
+7  A: 

probably because you don't handle this unique constraint in the database, if you would had an unique constraint on the email column in the DB then you wouldn't had that kind of problems

Omu
+12  A: 

FOr some reason I'm doubting that this was possible using the forms or any interface - however I'm more than curious to find how did this happen? Anyone have any ideas here!

Most probably, a browser double-post which you didn't track right.

If you don't want two people to share one email address in your social network, make a UNIQUE constraint on email field.

To avoid double-posts, generate a random string in a hidden control on your page, keep it in a column and make this column UNIQUE.

Quassnoi
Sorry, but I have to ask. How is this suggestion any better than making the email address field unique? From the context, Ali noticed this only because there were duplicate email addresses. If that's the case, then logically,the email address field should be set up with a UNIQUE constraint, and adding another field to the table and making that unique is just discouraging proper design, adding unnecessary data to the DB, and decreasing performance on future queries because it's a string (translated to varchar or another SQL string data type), which performs slower when used as an index...
David Stratton
I also want to say, I asked the question in the above comment in an earnest effort to understand and learn something new, not to criticise the answer.
David Stratton
How can I track those :(
Ali
+2  A: 

If you're somehow receiving double form posts and your constraints/transaction handling is not properly done, it's quite easy to do this.

Double form submissions (especially when triggered by javascript), can come fairly close in time to the server. Check your access log files for double posts.

krosenvold
I didn't understand that part on transaction handling? You mean database transactions?
Ali
You're absolutely right. It's probably just a unique constraint that's required.
krosenvold
+1  A: 

I think between the other posts, you have your answer. Probably there is no unique contstraint on the field in the database AND someone double-clicked on the submit button giving you a double post.

It's good practice to have your DB constraints set properly and from experience, it's usually best tpo disable the submit button on client side click (javascript) as soon as it's clicked to prevent those users who still try to double-click everything on the web.

David Stratton
+2  A: 

Certainly the most likely reason is that the user submitted the form twice.

The best way to avoid this is to use the redirect after post method.

RedFilter
+3  A: 

Don't rely on client-side validations! Those are just for the visitor as information. Always make sure validations are done server-side.

My guess is that someone used a script to subscribe to your site as a test to add dozens of accounts to fill your site with forum spam or whatever. By just adding two accounts, they test how easy it is. Apparently, it's quite easy. Next time, they might create a thousand accounts and use it to automatically flood your system with spam. Good luck trying to get rid of this all.

The important hints are already provided: enforce unique email addresses and unique usernames. However, when someone just subscribed to your site, make sure they can't create more accounts from that IP address for at least half an hour. Then you're annoying these automated scripts a bit.

Workshop Alex
+1 for thinking of security. Even if it turns out that this answer does not apply to this situation, it's best to look at this up front.
David Stratton