1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-09-22 18:28:47 +02:00
Commit graph

8 commits

Author SHA1 Message Date
epriestley
32f6c88896 Add first-time-setup registration flow
Summary:
Ref T1536. Currently, when you install Phabricator you're dumped on the login screen and have to consult the documentation to learn about `bin/accountadmin`.

Instead, detect that an install is running first-time setup:

  - It has no configured providers; and
  - it has no user accounts.

We can safely deduce that such an install isn't configured yet, and let the user create an admin account from the web UI.

After they login, we raise a setup issue and lead them to configure authentication.

(This could probably use some UI and copy tweaks.)

Test Plan:
{F46738}

{F46739}

Reviewers: chad, btrahan

Reviewed By: chad

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6228
2013-06-19 16:28:48 -07:00
epriestley
73c2c1d2e6 Send old login code to the bottom of the sea
Summary:
Ref T1536. This is extremely reachable and changes the login code to the new stuff.

Notes:

  - I've hard-disabled password registration since I want installs to explicitly flip it on via config if they want it. New installs will get it by default in the future, but old installs shouldn't have their auth options change.
  - Google doesn't let us change the redirect URI, so keep the old one working.
  - We need to keep a bit of LDAP around for now for LDAP import.
  - **Facebook:** This causes substantive changes in what login code is executed.

Test Plan:
  - Logged in / logged out / registered, hit new flows.
  - Logged in with google.
  - Verified no password registration by default.

Reviewers: btrahan, chad

Reviewed By: chad

CC: wez, nh, aran, mbishopim3

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6222
2013-06-19 01:33:27 -07:00
epriestley
278905543e Add very basic bin/auth tool
Summary: Ref T1536. This script basically exists to restore access if/when users shoot themselves in the foot by disabling all auth providers and can no longer log in.

Test Plan: {F46411}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6205
2013-06-17 10:55:05 -07:00
epriestley
61a0c6d6e3 Add a blanket "will login" event
Summary:
Ref T1536. Facebook currently does a check which should be on-login in registration hooks, and this is generally a reasonable hook to provide.

The "will login" event allows listeners to reject or modify a login, or just log it or whatever.

NOTE: This doesn't cover non-web logins right now -- notably Conduit. That's presumably fine.

(This can't land for a while, it depends on about 10 uncommitted revisions.)

Test Plan: Logged out and in again.

Reviewers: wez, btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6202
2013-06-16 16:35:36 -07:00
epriestley
0250b48c05 Add login buttons for button logins, fix LDAP form
Summary: Ref T1536.

Test Plan:
{F46555}

{F46556}

Reviewers: chad, btrahan

Reviewed By: chad

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6209
2013-06-16 16:31:57 -07:00
epriestley
8c3ef4b73c Support "state" parameter in OAuth
Summary:
Ref T1445. Ref T1536. Although we have separate CSRF protection and have never been vulnerable to OAuth hijacking, properly implementing the "state" parameter provides a little more certainty.

Before OAuth, we set a random value on the client, and pass its hash as the "state" parameter. Upon return, validate that (a) the user has a nonempty "phcid" cookie and (b) the OAuth endpoint passed back the correct state (the hash of that cookie).

Test Plan: Logged in with all OAuth providers, which all apparently support `state`.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, arice

Maniphest Tasks: T1445, T1536

Differential Revision: https://secure.phabricator.com/D6179
2013-06-16 10:18:56 -07:00
epriestley
104d3221d9 Implement new auth login flow and login validation controller
Summary:
Ref T1536. None of this code is reachable.

Implements new-auth login (so you can actually login) and login validation (which checks that cookies were set correctly).

Test Plan: Manually enabled FB auth, went through the auth flow to login/logout. Manually hit most of the validation errors.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6162
2013-06-16 10:15:33 -07:00
epriestley
c108ada7e4 Provide start screen and full registration flow on the new auth stuff
Summary:
Ref T1536. Code is intentionally made unreachable (see PhabricatorAuthProviderOAuthFacebook->isEnabled()).

This adds:

  - A provider-driven "start" screen (this has the list of ways you can login/register).
  - Registration actually works.
  - Facebook OAuth works.

@chad, do you have any design ideas on the start screen? I think we poked at it before, but the big issue was that there were a limitless number of providers. Today, we have:

  - Password
  - LDAP
  - Facebook
  - GitHub
  - Phabricator
  - Disqus
  - Google

We plan to add:

  - Asana
  - An arbitrary number of additional instances of Phabricator

Users want to add:

  - OpenID
  - Custom providers

And I'd like to have these at some point:

  - Stripe
  - WePay
  - Amazon
  - Bitbucket

So basically any UI for this has to accommodate 300 zillion auth options. I don't think we need to solve any UX problems here (realistically, installs enable 1-2 auth options and users don't actually face an overwhelming number of choices) but making the login forms less ugly would be nice. No combination of prebuilt elements seems to look very good for this use case.

Test Plan: Registered a new acount with Facebook.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T1536

Differential Revision: https://secure.phabricator.com/D6161
2013-06-16 10:15:16 -07:00