Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Send out magic links #2

Open
dirkroorda opened this issue Dec 2, 2022 · 9 comments
Open

Send out magic links #2

dirkroorda opened this issue Dec 2, 2022 · 9 comments

Comments

@dirkroorda
Copy link
Collaborator

When inviting users that are not yet known to the system, a magic link will be sent to such a user by email.

This link contains a secret that is stored in the user table.

Somehow the possession of the link should enable a new user, after registering, to fulfill a certain role.

I imagine that the user table will have entries without user details but with the token in a magic link.

When a user registers and presents the token, his details will be stored in the record that contains the magic link.

in this way, admins and editors can put non-existing users already in particular roles.

@dirkroorda dirkroorda converted this from a draft issue Dec 2, 2022
@vicding-mi
Copy link
Collaborator

As discussed, sendmail should send always html message. Please make sure that when feeding message to the sendmail client the message is in html form. For example, <html><head></head><body>text</body></html>

@dirkroorda
Copy link
Collaborator Author

Will do something like

H.html(H.head(), H.body(text))

@proycon
Copy link
Member

proycon commented Dec 7, 2022

This is probably none of my business but I feel very strongly about mail being plain-text (or at least multipart with a plain text) so I can't resist to say that I feel sending html-only mails is a bad idea. Feel free to ignore ;)

@vicding-mi
Copy link
Collaborator

The mail is multipart , we could include both plaintext and html. html by default will be shown though in the 'modern' mail clients ;) .

@dirkroorda , as long as the sending function gets pure html text, it should work fine. As suggested by @proycon , you can include the plain text version as well. The mail function can contain both plain and html.

@dirkroorda
Copy link
Collaborator Author

@proycon These mails are used to send a clickable link, and after the click they can discard the mail.

Just curious: what users would have a disadvantage if they would receive an html only link?

@proycon
Copy link
Member

proycon commented Dec 15, 2022

Just curious: what users would have a disadvantage if they would receive an html only link?

It's primarily a matter of principle regarding security/privacy. HTML mails with links and images are often used to obfuscate trackers or even malicious links (phishing etc). HTML mails very rarely have much added value compared to plain text (exception are cases where rich media/formatting is essential, but that is seldom the case), they add a huge amount of complexity. Don't get me wrong, I think it's fine to send out both html and plain/text, that way each users gets what he/she prefers, just don't force html upon users.

Plain-text may be boring and lacking many features, but its simplicity has advantages. Parsing and rendering is much easier everywhere (though clients will have to do url detection and make them 'clickable'), albeit limited.

@dirkroorda
Copy link
Collaborator Author

dirkroorda commented Dec 19, 2022

Then my question is:

Suppose user N follows a principled approach, and has an email client that does not render HTML.

Will N be disadvantaged if we send him an HTML only link?

Are there email clients that do not support html mail?

The other question is: maybe every major email client will make a link in a plain text email clickable.

If the latter is the case, then the principle of minimalism steers us into sending plain text mails.

@dirkroorda
Copy link
Collaborator Author

I should have read this first: https://useplaintext.email

@proycon
Copy link
Member

proycon commented Dec 19, 2022

I should have read this first: https://useplaintext.email/

Ha right, very good resource indeed, that explains it way better than I can and I fully agree with what they say there.

Suppose user N follows a principled approach, and has an email client that does not render HTML.
Will such be disadvantaged if we send him an HTML only link?

I doubt you'll encounter many users/mail clients that can't render HTML mail. I'm that principled user from your use-case, but even my neomutt can (by calling an external tool like w3m to convert html to text) visualize it fine for me. In worst case you can always open it in a browser. So I wouldn't be disadvantaged functionally, only in my principled sensibilities perhaps ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 📋 Backlog
Development

No branches or pull requests

3 participants