141–150 of 181 posts
"You might not need to store user email addresses " Emails and email addresses are two very different things.
> For every transactional email I need to send out - registration, account recovery, and email change verification - the user always initiates this by submitting their email address, and it will at that time be available to the backend to perform the needed action. This sounds like terrible UX, not to mention email use cases not initiated by the user. I really think you'd be shooting yourself in the foot by setting u…
This would not work for any serious/useful service: e-mails are not only for marketing, there are many good reasons to send one like (user requested) notifications, invoicing, ... and also screw-ups! If your service had a problem (security, broken data, invoicing again, long downtime, ...), you better contact your users before they find out on hackernews.
Plaintext email could be stored client side in a cookie and may be submitted to the server when use of the email is required, and if it validates. If the user logs in and the site is down, a backup system could email them about the issue. This is the backup system, primary systems are down. Please contact support if you need more information. No need to email users who aren't using the system currently about downtime…
To make this make sense, I think you are assuming but without explicitly stating the use of signed cookies? EDIT: "if it validates", I guess so.
The other bit which is not clear to me is, what is the key in the database to identify ownership of user information?
You need a linking record which looks like hash(email) -> uid (or user record or whatever) which does not seem any better than what is proposed in TFA.
OTOH if no information is stored against the user's email / uid / username then you probably don't need login or auth.
"You might not need to store user email addresses " Emails and email addresses are two very different things.
In technical writing within this industry, “email” is interchangeably used to mean either the protocol, an address or a message, depending on context. “If user confirmed their account by entering a confirmation code received via email or phone, that email or phone number becomes verified” is a routine sentence that will confuse no one.
As an irrelevant aside, if you insist on justifying web content, “hyphens: auto” is your friend.
- Most common: a user has a support request because they can't get into their account (e.g. you have sign-in-with-Facebook and they lost their account there, or got banned).
- Your authentication partner (again e.g. Facebook) disables your integration for some reason - someone reports your account as abusive (maybe maliciously) and it gets locked, and your attempts to work through Facebook customer support hit a brick wall. If you have email addresses you can at least get your users back into their accounts via a reset-password style flow.
- You have a data breach, and you need to tell your users what happened and what private data of theirs was leaked to an attacker.
- You get a legal threat - a DMCA takedown message for example - and need to pass it on to your users.
- You sell your service to another company and the lawyers involved in the transaction insist on emailing out a terms of service update.
There are plenty more.
"You might not need to store user email addresses " Emails and email addresses are two very different things.
In technical writing within this industry, “email” is interchangeably used to mean either the protocol, an address or a message, depending on context. “If user confirmed their account by entering a confirmation code received via email or phone, that email or phone number becomes verified” is a routine sentence that will confuse no one.
"email" isn't a protocol. SMTP is though, and referring to RFC 5321 ("a specification of the basic protocol for Internet electronic mail transport"), section 2.3.11 [1], we see that: "As used in this specification, an "address" is a character string that identifies a user to whom mail will be sent or a location into which mail will be deposited."
Earlier quoted context omitted.
In technical writing within this industry, “email” is interchangeably used to mean either the protocol, an address or a message, depending on context. “If user confirmed their account by entering a confirmation code received via email or phone, that email or phone number becomes verified” is a routine sentence that will confuse no one.
> “email” is interchangeably used to mean either the protocol, an address or a message "email" isn't a protocol. SMTP is though, and referring to RFC 5321 ("a specification of the basic protocol for Internet electronic mail transport"), section 2.3.11 [1], we see that: " As used in this specification, an "address" is a character string that identifies a user to whom mail will be sent or a location into which mail wil…
As a frequent reader of technical blogs and reference documentation, I stand by my point that “email” alone is used to mean email address quite frequently.
Earlier quoted context omitted.
In technical writing within this industry, “email” is interchangeably used to mean either the protocol, an address or a message, depending on context. “If user confirmed their account by entering a confirmation code received via email or phone, that email or phone number becomes verified” is a routine sentence that will confuse no one.
It is confusing when the referent is ambiguous. In the original title, email could mean either of two things, and there is no way to tell which it is. As an irrelevant aside, if you insist on justifying web content, “hyphens: auto” is your friend.
I am not the OP, and frankly I don’t believe full justification has a place on the web just yet. Hyphenation alone is rarely enough to make it bearable, and I think browsers’ rendering engines don’t do more than that.
Some things that become difficult if you don't have a verified email address for your users: - Most common: a user has a support request because they can't get into their account (e.g. you have sign-in-with-Facebook and they lost their account there, or got banned). - Your authentication partner (again e.g. Facebook) disables your integration for some reason - someone reports your account as abusive (maybe maliciousl…
I can't create a record, I can't delete a record, I can't see the email field, but I can change the subscription plan for this user, or change their avatar.
We tend to do table or row level permissions, matrixed with verb. Column level occurs at the application layer, leaving plenty of room underneath for exfiltration.