Expected invitation -> user login workflow

sso

(Benjol) #1

I’ve got a private site, where I’ve got:

invite_only = 1
login_required = 1
must_approve_userse = 1

And also I’ve set up (new) Google authentication (and will probably doing Facebook and Twitter when I get round to it).

What isn’t clear to me is how an invited user goes from being ‘magically’ logged on via the link in the email, to authenticating with Google. If I go into my test user’s preferences I can see ‘Define a password’, but nothing about Google authentication.

And of course my own admin account doesn’t have google authentication because it wasn’t enabled when I created the account :frowning:


(Jeff Atwood) #2

The idea is that the invite gets them in as a live new user with a magical token in a single click… but it is up to the user to set up a “real” authentication method once they arrive: either via username/pass or logging in via Google to a matching email.

It’s really all keyed on email. The invite message does go to quite some length to explain this, so maybe have a look at that.


(Benjol) #3

Thanks Jeff, guess I’ll have to invite myself (I just set up FB & Twitter too, so I’m going to have to test them anyway)


(Jeff Atwood) #4

Yes, try it out, if you have any feedbacks on improving the invite system, don’t hesitate to share it here. We’ve done a lot of work on invites over the last 12 months, it has been a popular feature, so I am open to further improvements in this area.

(And I guess this makes sense: problem #1 with a new discussion site, getting people to visit and ideally join.)


(Benjol) #5

Weird, when I click on the link in the invitation, I just get parachuted directly into the ‘home page’, without being asked for anything.

And then I get another email inviting me to set a password, when I click on that link, I just get sent to a page which wants a password, but nothing proposing Google/Facebook/Twitter.

Something setup wrong maybe?


(Jeff Atwood) #6

Sounds correct. Did you check your private messages as that user?


(Benjol) #7

Something I’m not following there then.

If that sounds correct, how does the user get from ‘auto-logged in but no password’ to ‘authenticated via Google etc.’?


(Jeff Atwood) #8

Doesn’t the private message text explain this? Did you read it?


(Benjol) #9

:lightbulb:

What wasn’t clear to me is that you have to be logged out to follow the external authentication path, whereas you can set password from inside your profile.

Have I understood correctly?

(Google & Facebook working ok, but apparently Twitter isn’t giving Discourse my email properly - in any case Discourse is saying ‘sorry, don’t know you’)


(Kane York) #10

This is correct, Twitter doesn’t give emails, so it can’t be linked with the other accounts.


(Jeff Atwood) #11

I am open to improving this in various ways, but it all starts with “did the user read the PM we sent them as a new user?”

I guess we could force them to read it with methods of increasing onerousness…


(Benjol) #12

OK, so that means there’s no point configuring Twitter authentication when using invitations, I guess?

I should have been a tester, I seem to have a gift for unwittingly picking up edge cases :slight_smile:


(Benjol) #13

I guess that the thing is that the ‘chronological disconnect’: the message about logging in again comes when the user is already ‘logged in’, so they (ok, I) tend to gloss over it.

What you said here reinforces that misconception: “setup a real authentication method once they arrive”. If I have correctly understood, in the case of external authentication, it’s not when they arrive, but when they come back next time? Or is it not even next time (if there’s a cookie involved)?

And I’m not sure that “but it must resolve to the same email address that you received your original invitation email at.” Is very understandable in normal human speak.

How about something like this:

IMPORTANT: For the moment you have been ‘magically’ logged in via the special link in your invitation. To ensure that you can connect again next time (or from another computer), you should take the time NOW to set-up a password (link to preferences). Alternatively you will be able to use your Google/Facebook account to login next time, as long as the email address associated with that account is the same as the one used for your invitation.

:thinks: For this to work, the server-side code would have to be modified to check whether Google/Facebook is effectively enabled and construct the welcome message accordingly. And as we’ve seen (I think), this wouldn’t apply to Twitter authentication.

Otherwise, with a generic message, the only way for the user to be able to work out what is available would be to log out - at which point if there isn’t an alternative authentication method, they’d have to fall back on the ‘set password link’ in the second email. So it’s not impossible, but not very intuitive either.

Well sticking that bit in the ‘set your password email’ as well as in the welcome PM would mean that they still have the means to read it again even if they didn’t the first time.


(Jeff Atwood) #14

I moved 3 posts to a new topic: Tags should be part of edit history


Tags should be part of edit history
(Jeff Atwood) #15

Remember users can have multiple login methods.

Unless you have disabled username/password logins then you can have as many login methods as you like as long as they map to the same validated email address. (Twitter is the outlier here as they don’t provide a validated email, though I heard this is changing, hopefully soon.)

Also, users can always send a password reset if they don’t “remember” their password. As in they did not set one. This works fine, test it yourself.

There’s an unusual focus in your post on arbitrarily forcing users to log in with method X or method Y when all we really care about is:

  • Are you logging in with the same email address as before? If so, It Will Just Work.

  • Did you forget your password? No problem, click “forgot” and It Will Just Work.


(Jeff Atwood) #17

True… so I just changed it to

Always use the same email address from your original invitation when logging in. Otherwise we won’t be able to tell it’s you!


(Benjol) #18

OK, point taken. I guess it’s just that personally, I consider having to invent a new password as being enormous friction* (i.e. I often don’t even bother), so I’d tend to ‘push’ the fact that they can use an existing authentication method.

*This is your fault :wink:


(Jeff Atwood) #19

Well, I agree with you, but in the case where you have sent someone a magical email token that creates their account when they click it, and they are fully logged in… It’s hard to magic up a flow that forces them to set Google or Facebook auth at the same time that isn’t a pain. I mean, the whole thing is predicated on sending an email token, right?

The general idea is whenever they need to log in again, they just “do it” using any supported method, and as long as the emails match, we’re good to go. (This includes forgot password, which will just trigger them to create one if they don’t have one, but they’ll be logged in after.)


(Benjol) #20

Thanks, I look forward to translating that once it gets into Transifex.

Just as an aside, do you know how I can get Reviewer role on Transifex? Right now I’m seeing [fr.topic.create] and
[fr.composer.create_topic] in the UI, and they’re pretty fundamental buttons…

Oh hang on, it looks like those keys don’t even exist in Transifex yet? I can only see [js.topic.create] and [js.composer.create_topic]


(Jeff Atwood) #21

@techapj can add you to whatever role is needed.