Tokenized 'visit topic' link to auto log users into discourse

feature
#1

I would love to see an option to add a token to the “visit topic” link when users get an email from discourse that would auto log them in when they click on the link.

Many app based email clients - like gmail - use web view to load the links you click on that don’t have cookies saved if you may have previously logged in. The result is users are blocked from responding if they don’t have their login handy and often abandon the impetus to respond.

I think this would be easily fixed if you had an option to add a token that would auto login the user so they could immediately respond if they click on the link. An added option for how long the token lasts, would be useful as well.

#2

It’s certainly a creative solution to a problem I’d solve by recommending not using an email client’s webview, or replying via email.

I don’t use third-party login systems, but I think this concept fights a bit with how those work, correct? If you click on links to other sites that sign-in with a social media account, how are those handled in the email client webview? Do the login tokens work in that scenario? :thinking:

#3

While I understand what you’re saying I think you’ve already lost the average user who probably doesn’t even understand the difference between a web view and opening in mobile safari.

Many sites do similar the idea being similar to a ‘magic link’ when signing into services like slack. Instead of putting in your username and password, you can request a magic link sent via email. When you click on the magic link you’re logged in. The magic link being a tokenized URL.

If you can reset your password with a link sent to your email what’s the difference?

#4

In case you were responding to this part:

What I meant was: do magic links work when a user has signed up with a social media account? I don’t know. Your feature may be contesting with a lot of login systems, so I was preempting R&D. :slight_smile:

I get that a lot… :weary:

#5

Sorry I didn’t address that… a core developer of discourse would know better than I, but in similar systems I’ve worked on it shouldn’t be an issue. Your SSO be it social or otherwise is basically just a token exchange between the SSO service provider and Discourse. So it would actually be similar except in this case your SSO would be your email. Over simplifying it a bit, but generally speaking I’d imagine it would work fine.

#6

This is very specific to iOS right? Android equivalent (Chrome Custom Tabs) shares cookies by default, so this isn’t a problem in Android.

1 Like
#7

I’m not entirely sure and haven’t had a chance to test on an android device. But I think it kind of goes beyond this use case. Even if you’re on a desktop and you just happen to have not engaged in the community in a while it would encourage engagement because it would auto log you in when you went to respond.

Generally I’ve disabled reply by email on most discourse instances we manage because the result of the email parsing can be a bit hit or miss and the mobile web interface for disqus is so great… so when it works (you’re already logged in) clicking on the “visit topic” (I might even add a reply now button that opens up the reply dialogue) is almost as seamless as hitting reply in your email client.

1 Like