fwiw I do not repro. my steps were

• generate a user
• go in the database and expire the token
  • use phabricator_auth;
  • select * from auth_temporarytoken; // just one record for me
  • update auth_temporarytoken set tokenExpires = 1015322729 where id = 1;
• use /bin/mail to find the pertinent email and uri
• go to the uri page and click the button to send another email
• end up on the page to enter an email address to reset your password
  • this is confusing maybe?
• fill it out and everything works though

Hmm, nope - I was definitely seeing a 404 after clicking the button to send another email.
I'll try again tomorrow and see if I can get any more specific info.

Looks like we’re getting a 404 error for http://<domain>/login/email/

In T6479#82521, @anton.vladimirov wrote:

Looks like we’re getting a 404 error for http://<domain>/login/email/

So https://secure.phabricator.com/login/email/ is a 404 on your install?

better call the local exorcist!

Note it is possble to get a 400 error if you do not have the Username / Password auth enabled. If its a 400, see http://<domain/auth/ for your settings. If you don't have the Username / Password auth type enabled, turning it on should fix this workflow. That said, please let us know what the settings you do have here are as I don't think you should have fallen into this hole with any combination of settings.

We don't have username/password authentication enabled - just LDAP. Is that a bad idea?

I just logged myself out, navigated to /login/email and I'm seeing 400. And I now feel dumb. Should have really looked at what I was getting before filing a bug, sorry.

I'm actually not familiar with the LDAP stuff as I don't have a working LDAP server. Adding in my cohorts though.

@chad / epriestley - Is this something we need to get right for SAAS or is this something we can ship SAAS without and improve later? Otherwise does my assessment sound right here (i.e. both administrators and users are confused under this setup and scenario)?

I don't have everything set up locally, but two general pieces of information:

• If you add users with People > Create New User, those accounts are not LDAP accounts, and not linked to LDAP in any way. Users who miss the registration email time window can click "Forgot Password?" and use the password reset link to recover their accounts, if Username/Password authentication is enabled.
• The expected way to deal with LDAP is to just enable the LDAP provider as a registration provider, and not create any accounts manually. Users will enter their LDAP credentials and be pushed through the registration workflow, creating accounts which are linked to their LDAP accounts.
  • In particular, if you create alincoln as a (non-LDAP) Phabricator account, the user with the alincoln LDAP account will hit issues if they try to go through LDAP registration because of the name conflict.
• It's possible the "LDAP Import" workflow does some crazy stuff here, not sure if you were using it. I don't remember if it can send welcome emails. We should likely just delete it for now, resolving T4137. We can restore it after T5953.

Possibly we should have some kind of warning on People > Create New User if password auth is not enabled, since it's a confusing/advanced feature in that case (users must follow the links promptly, must link an external account, can not recover credentials, and don't get UI prompting).

On SAAS, I believe the current plan is zero LDAP support, so it's moot.

(That title might be a little clearer?)

In the long run, I think the ideal workflow here is to make import/create more of a function of providers -- so you enable LDAP and get "Import from LDAP" (users would recover by logging in with their LDAP credentials), enable Google and get "Import from Google" (users would recover by logging in with their Google credentials), enable Facebook/GitHub/Whatever and get "Import from list of accounts in a CSV file" or something (users would recover by logging in with their service credentials), and enable username/password and get "Create New Account" (users would recover via password reset -- I think they already get cued about this, maybe?). We could let you "Create New Account" anyway, maybe, but since you can do that via the CLI if you really intend to do advanced stuff it might be more straightforward to simply remove it from the web UI.

Most of this would depend on T5953. None of this impacts SAAS.

This seems to have gotten a little bit too deep, but I might be misunderstanding something.

If I log out and then navigate to /login/email I get error 400, and an ugly plain text one, too.

I would expect something, even if it's not really functional. At the minimum, a page that says "We can't do this for your config automatically. Email your administrator and have him re-generate the welcome email".
But really it seems reasonable to allow the user to self-regenerate the welcome email if they've received one in the past (i.e. given an email address, see if there's a user with that address that was created but hasn't logged in, and if so, send a new email).

Unless you specifically instructed the users who did click the links to immediately go to Settings > External Accounts and link their LDAP accounts, they're not really in better shape: they'll get locked out of their accounts as soon as they log out, too. Their LDAP credentials are not tied to their accounts. We never tie credentials together based on email addresses or usernames, because these aren't trustworthy across authentication sources.

Basically, "Create New User" creates a new Username/Password user, approximately. The root issue is that we let you do this when it's probably not what you intend to do (it might be, if the administrator is creating bot accounts, but for normal users it wasn't what you wanted).

We probably should do something other than 400 here, but even if we showed a nice message or let you automatically re-send the email, I think this workflow fundamentally doesn't do what you want.

My guess is that you should probably:

• Enable LDAP as a registration provider.
• Delete all user accounts of users who haven't logged in.
• Instruct users who have logged in to go to Settings > External Accounts and link their LDAP accounts.
• For new users, have them create their accounts by registering with LDAP, not via People > Create New User.
• If you want to invite them, just send them a personal email like "Hey, when you get a chance come register for Phabricator with your LDAP credentials."

Unless you specifically instructed the users who did click the links to immediately go to Settings > External Accounts and link their LDAP accounts, they're not really in better shape: they'll get locked out of their accounts as soon as they log out, too. Their LDAP credentials are not tied to their accounts. We never tie credentials together based on email addresses or usernames, because these aren't trustworthy across authentication sources.

The Settings->External accounts is where they're taken by default as soon as they log in, and since no-one has entered any passwords anywhere pretty much everyone clicked on "LDAP" immediately and associated their account, so I think that workflow is pretty solid.

For the record, I can easily recover from this situation by re-sending the welcome email to those users whose welcome email has expired, and my install is under 20 users currently, so I'm not really having a problem as far as getting the users logged in is concerned. I just thought I'd let you guys know that in this kind of scenario a new users sees something that they probably shouldn't. In every case this was resolved by people emailing me and that was good enough for me, but adding "complain to the admin" button for this case to automate the complaining process would make this smoother ;).