NYCPHP Meetup

NYPHP.org

[nycphp-talk] design question: user self-registration

Brian O'Connor gatzby3jr at gmail.com
Tue Aug 31 15:09:24 EDT 2010


This may very well be a dumb question, but what's wrong with doing the
insert and just detecting if it fails?  If you get a duplicate key, you know
they're in the database and can act accordingly.  Otherwise, it inserts.

This may be somewhat of a controversial stance, but I'm all in favor of
letting my database do my checks for me.

On Tue, Aug 31, 2010 at 2:58 PM, David Mintz <david at davidmintz.org> wrote:

>
>
> On Tue, Aug 31, 2010 at 12:52 PM, Dan Cech <dcech at phpwerx.net> wrote:
>
>> On 8/31/2010 12:43 PM, David Mintz wrote:
>>
>>> I want to provide a self-service user registration, with an email
>>> verification thing. They submit their data, we email them a link to
>>> verify
>>> that they control the email address they provided, bla bla, then the
>>> account
>>> is enabled. So I thought I would go ahead and do the inserts, marking
>>> both
>>> new records as 'inactive' pending email confirmation.
>>>
>>> In some cases, though, there may already be a row in people corresponding
>>> to
>>> the new user.
>>>
>>
>> In this case would it make sense to let the user know that there is
>> already an account and just offer to re-send the verification or password
>> reset email (depending on the status of the account)?
>>
>> Of course that would assume that the account hasn't been disabled for some
>> reason, in which case if you have a hard unique constraint on the email
>> you're going to have to reactivate the account rather than being able to
>> create a "new" account for the user and leave the old account as
>> deactivated.
>>
>>
>
>
>
> Sorry, I didn't explain clearly enough. There may be cases where there is
> already record for the soon-to-be user in the 'people' table, but not the
> 'users.' See the issue? If I try to insert where the email already exists, I
> run into the unique constraint, but then if I say instead 'update ... where
> email = $their_email'  before confirming the email, well, that sounds like a
> poor idea, basically  allowing anyone to run an update on anyone else's
> record in the table.
>
> Not the end of the world, but I am looking for the most graceful solution.
>
>
> --
> Support real health care reform:
> http://phimg.org/
>
> --
> David Mintz
> http://davidmintz.org/
>
>
>
> _______________________________________________
> New York PHP Users Group Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> http://www.nyphp.org/Show-Participation
>



-- 
Brian O'Connor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20100831/df12caa0/attachment.html>


More information about the talk mailing list