#318 Mockup for when freenode registration lost
Opened 7 years ago by duffy. Modified 6 years ago

(Related ticket: issue #283)

If someone's freenode registration has lapsed and someone else took their nickname and they can no longer authenticate to it, we need to handle that case.

How can this happen?

  • If the user doesn't confirm their email address when we prompt them to, and 24 hours pass, if someone else attempts to take the nick and register it, they can take it over.
  • After 10 weeks of inactivity during which a user is not identified with their nick, it is considered expired. This means it may be subject to a db purge (which happen infrequently) or another user who wants the same nick requesting it be dropped so they can register it.
  • Activity means "you logged in to the account, regardless of the nickname you used to do so." So this will be a very edge case with our ircb usage as long as we make sure we continue to authenticate the account with nickserv.
  • if a nick does expire, and the user tries to log in again, their same credentials will work as long as someone else didn't grab the nick or the db wasn't purged.

cases to handle:
- nick expired, still available: no issue, just log them in
- nick expired, db purge: re-register same nick
- nick expired, someone else grabbed it: need to re-register with new nick

If the nick can be recovered, we can do that behind the scenes. This issue only applies to the situation in which the registration was lost and the user must come up with another nick.

General workflow thoughts

  1. If nick has been taken, we disable the IRC feature hubs wide.
  2. When user goes to use IRC feature in hubs, they'll see that the IRC widget has been disabled.
  3. Disabled IRC widget will have a note that they need to re-register
  4. User clicks on "on" button to re-enable IRC, which will kick off the IRC nick wizard again (maybe with a flash note about why this happened) (see issue #283 for mocks of this wizard)
  5. User is re-registered

Metadata Update from @sayanchowdhury:
- Issue untagged with: milestone1
- Issue marked as depending on: #283
- Issue marked as depending on: #291

6 years ago

Metadata Update from @sayanchowdhury:
- Issue set to the milestone: Flock 2017

6 years ago

Metadata Update from @duffy:
- Issue unmarked as depending on: #291
- Issue marked as depending on: #283
- Issue marked as depending on: #291

6 years ago

Metadata Update from @ryanlerch:
- Issue set to the milestone: None (was: Flock 2017)

6 years ago

Login to comment on this ticket.

Metadata