Impossible to remove the last OpenID in a BrowserID-based account
Bug #858823 reported by
François Marier
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Libravatar (obsolete) |
Won't Fix
|
Low
|
Unassigned | ||
Bug Description
For users that have an account using BrowserID auth and haven't set a manual password, adding an OpenID is not a reversible operation.
This is due to the fact that we make sure that the last OpenID in an account cannot be removed unless there is a fallback manual password that can be used.
Not sure what's the right thing do. Should we allow users to set a new manual password if they control one of the confirmed emails? (and therefore disable the "last OpenID check")
Or should we somehow keep track of the emails we've seen come through BrowserID to be better able to tell whether or not an account will be lost?
| Changed in libravatar: | |
| assignee: | nobody → François Marier (fmarier) |
| Changed in libravatar: | |
| assignee: | François Marier (fmarier) → nobody |
Revision history for this message
| François Marier (fmarier) wrote | #1 |
| Changed in libravatar: | |
| status: | Triaged → Won't Fix |
To post a comment you must log in.
Superseded by bug 1533018.