1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-11 17:32:41 +01:00
Commit graph

5 commits

Author SHA1 Message Date
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