275137 - Email address changes are accepted without being verified

Status: RESOLVED FIXED

(addons.mozilla.org Graveyard :: Developer Pages, defect)

Description

[alanjstr]

Unlike BMO, UMO does not make you verify that your new email address is valid
when you change it.

Comment 1

[Giorgio Maone [:ma1]]

Being a bug that involves usermanager (that I'm patching too), I'm taking on
this. Fundamentally I will disable the user profile and send a confirmation
unblocking code to the new email address (like we do upon registration) when he
edits it. Of course he should be warned *before* he commits the change... just
in case :-)

Comment 2

[alanjstr]

I think we need a confirmation table that lists pending confirmations.  That way
we can expire them.  

UserID, ConfirmType, Value, ConfirmCode, timestamp
ConfirmType would be A for account creation, P for Password Reset, E for Email
Change

Can't login for A and E.  

Comment 3

[Giorgio Maone [:ma1]]

(In reply to comment #2)
> I think we need a confirmation table that lists pending confirmations.  That way
> we can expire them.  
> 
> UserID, ConfirmType, Value, ConfirmCode, timestamp
> ConfirmType would be A for account creation, P for Password Reset, E for Email
> Change
> 
> Can't login for A and E.  

What if we simply change confirm code format on the userprofiles table?

{date[yymmddhhMM]}{type[A|E|P]}{random-hex-value}

for instance

0401220830A80ffc6324b

This way we spare another join, and we can still expire/discriminate.

Comment 4

[alanjstr]

We could do that.  I was trying to avoid having this extra data hang around.

Comment 5

[Dave Miller [:justdave]]

Here's what we currently do with Bugzilla:

We have a tokens table, which uses a randomly-generated 8-character token as the
primary key (not autoincrement, we generate it).  In this table we store their
old email address, the new email address, the date it was issued, and a token
type code.

Two tokens are issued for an email address change.  One gets a token type that
indicates it's for the old address, and one gets a token type that indicates its
for the new address.  Otherwise the rest of the data on the two tokens is the same.

One token is mailed embedded in URLs to each of the new and old addresses.  The
old address gets one saying "click here to cancel this change".  The new address
gets both "click here to cancel" and "click here to confirm".  I *wanted* to
have Bugzilla require the old user to either confirm or let their token expire
before the change could take effect, but the people writing the patch were lazy
and I was too busy to do any better myself at the time ;)

Comment 6

[alanjstr]

We should also record the IP 

Comment 7

[Giorgio Maone [:ma1]]

(In reply to comment #6)
> We should also record the IP 

see bug 280318

Comment 8

[alanjstr]

*** Bug 329095 has been marked as a duplicate of this bug. ***

Comment 9

[Mike Shaver (:shaver emeritus)]

Throwing this back into the queue (feel free to reclaim it if you're active on it, mao, just trying to tidy things a bit).  It'd be good to fix, but I don't think it's a major issue presently.

Comment 10

[Mike Shaver (:shaver emeritus)]

Fred: do we do this in Remora yet?

Comment 11

[Basil Hashem [:baz]]

Resolved - please reopen if found not to be true.