You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 28, 2020. It is now read-only.
UserEmail and UserPhone are considered verified data, in that the record exists only if there is a verified link to a user (related: #178). This verification is used to prevent a competing UserEmailClaim or UserPhoneClaim from being created.
However, email claims are still possible in Hasjob (new job post) and Boxoffice (new order or assignee), as those apps prioritise documents over user principals (see #220). This can be a nuisance for a user who is the target of abuse, or who happens to have a common name email address that others mistakenly assume is theirs (as happens often to @kushaldas).
UserEmail and UserPhone should have an optional flag named locked that prevents such email claims from being created unless the user is logged in.
Lastuser must provide an API to check for locked status, and
Apps (Hasjob and Boxoffice) must use this to refuse a locked email address unless the user is logged in. (It's unclear how Boxoffice will do this when embedded in a third-party website that has no Lastuser login.)
There is a related but distinct issue with unwanted email/SMSes to someone who has no interest in creating an account, much less locking it. A solution is briefly discussed in hasgeek/listman#8 but merits a separate ticket.
Caveats:
What happens if there is a hard bounce of email? If the record is removed as per Removing emails from accounts #135 and Remove email on hard bounce #160, the locked status goes away as well. There is no equivalent workflow for hard bounce of SMS, unfortunately, as phones are by definition only intermittently reachable.
Does the locked status apply for password reset/account recovery emails? Refusing to send an email/SMS may totally lock the user out. Perhaps this should be an account-level lock (2FA, security questions, etc) instead of an email/phone lock.
The text was updated successfully, but these errors were encountered:
UserEmail
andUserPhone
are considered verified data, in that the record exists only if there is a verified link to a user (related: #178). This verification is used to prevent a competingUserEmailClaim
orUserPhoneClaim
from being created.However, email claims are still possible in Hasjob (new job post) and Boxoffice (new order or assignee), as those apps prioritise documents over user principals (see #220). This can be a nuisance for a user who is the target of abuse, or who happens to have a common name email address that others mistakenly assume is theirs (as happens often to @kushaldas).
UserEmail
andUserPhone
should have an optional flag namedlocked
that prevents such email claims from being created unless the user is logged in.There is a related but distinct issue with unwanted email/SMSes to someone who has no interest in creating an account, much less locking it. A solution is briefly discussed in hasgeek/listman#8 but merits a separate ticket.
Caveats:
What happens if there is a hard bounce of email? If the record is removed as per Removing emails from accounts #135 and Remove email on hard bounce #160, the locked status goes away as well. There is no equivalent workflow for hard bounce of SMS, unfortunately, as phones are by definition only intermittently reachable.
Does the locked status apply for password reset/account recovery emails? Refusing to send an email/SMS may totally lock the user out. Perhaps this should be an account-level lock (2FA, security questions, etc) instead of an email/phone lock.
The text was updated successfully, but these errors were encountered: