1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-12 08:36:13 +01:00
Commit graph

298 commits

Author SHA1 Message Date
epriestley
5d76a4b0a2 Improve handling of multiple edit forms when logged out
Summary:
Ref T10004. Currently, when a logged-out user visits an application like Maniphest, we show them a disabled "Create Task" button with no dropdown menu.

This is technically correct in some sense because none of the items in the menu will work, but we can be more helpful and show the items, just in a disabled state:

{F1028903}

When the user clicks these, they'll be pushed through the login flow and (after D14804) end up on the same page they were on when they selected the item. From here, they can proceed normally.

I changed "...to continue." to "...to take this action." to hopefully be a little more clear. In particular, we do not //continue// the action after you log in: you end up back on the same page you started on. For example, if you clicked "Create New Bug" from the list view, you end up back on the list view and need to click "Create New Bug" again. If you clicked "Edit Task" from some task detail page, you end up on the task detail page and have to click "Edit Task" again.

I think this behavior is always very good. I think it is often the best possible behavior: for actions like "Edit Blocking Tasks" and "Merge Duplicates In", the alternatives I can see are:

  - Send user back to task page (best?)
  - Send user to standalone page with weird dialog on it and no context (underlying problem behavior all of this is tackling, clearly not good)
  - Send user back to task page, but with dialog open (very complicated, seems kind of confusing/undesirable?)

For actions like "Create New Bug" or "Edit Task", we have slightly better options:

  - Send user back to task page (very good?)
  - Send user to edit/create page (slightly better?)

However, we have no way to tell if a Workflow "makes sense" to complete in a standalone way. That is, we can't automatically determine which workflows are like "Edit Task" and which workflows are like "Merge Duplicates In".

Even within an action, this distinction is not straightforward. For example, "Create Task" can standalone from the Maniphest list view, but should not from a Workboard. "Edit Task" can standalone from the task detail page, but should not from an "Edit" pencil action on a list or a workboard.

Since the simpler behavior is easy, very good in all cases, often the best behavior, and never (I think?) confusing or misleading, I don't plan to puruse the "bring you back to the page, with the dialog open" behavior at any point. I'm theoretically open to discussion here if you REALLY want the dialogs to pop open magically but I think it's probably a lot of work.

Test Plan: As a logged out user, clicked "Create Task". Got a dropdown showing the options available to me if I log in. Clicked one, logged in, ended up in a reasonable place (the task list page where I'd started).

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14806
2015-12-17 08:30:54 -08:00
epriestley
e869e7df0b When logged-out users hit a "Login Required" dialog, try to choose a better "next" URI
Summary:
Ref T10004. After a user logs in, we send them to the "next" URI cookie if there is one, but currently don't always do a very good job of selecting a "next" URI, especially if they tried to do something with a dialog before being asked to log in.

In particular, if a logged-out user clicks an action like "Edit Blocking Tasks" on a Maniphest task, the default behavior is to send them to the standalone page for that dialog after they log in. This can be pretty confusing.

See T2691 and D6416 for earlier efforts here. At that time, we added a mechanism to //manually// override the default behavior, and fixed the most common links. This worked, but I'd like to fix the //default// beahvior so we don't need to remember to `setObjectURI()` correctly all over the place.

ApplicationEditor has also introduced new cases which are more difficult to get right. While we could get them right by using the override and being careful about things, this also motivates fixing the default behavior.

Finally, we have better tools for fixing the default behavior now than we did in 2013.

Instead of using manual overrides, have JS include an "X-Phabricator-Via" header in Ajax requests. This is basically like a referrer header, and will contain the page the user's browser is on.

In essentially every case, this should be a very good place (and often the best place) to send them after login. For all pages currently using `setObjectURI()`, it should produce the same behavior by default.

I'll remove the `setObjectURI()` mechanism in the next diff.

Test Plan: Clicked various workflow actions while logged out, saw "next" get set to a reasonable value, was redirected to a sensible, non-confusing page after login (the page with whatever button I clicked on it).

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T10004

Differential Revision: https://secure.phabricator.com/D14804
2015-12-17 08:30:03 -08:00
epriestley
6c4c93a091 Allow login to be disabled for authentication providers
Summary:
Fixes T9997. This was in the database since v0, I just never hooked up the UI since it wasn't previously meaningful.

However, it now makes sense to have a provider like Asana with login disabled and use it only for integrations.

Test Plan: Disabled login on a provider, verified it was no longer available for login/registration but still linkable.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9997

Differential Revision: https://secure.phabricator.com/D14794
2015-12-15 15:03:06 -08:00
epriestley
1b00ef08a0 Remove some low-hanging buildStandardPageResponse() methods
Summary: Ref T9690. I wanted to do an example of how to do these but it looks like most of them are trivial (no callsites) and the rest are a little tricky (weird interaction with frames, or in Releeph).

Test Plan:
  - Used `grep` to look for callsites.
  - Hit all applications locally, everything worked.

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9690

Differential Revision: https://secure.phabricator.com/D14385
2015-11-03 10:11:36 -08:00
Joshua Spence
c35b564f4d Various translation improvements
Summary: Depends on D14070.

Test Plan: Eyeball it.

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: Korvin, hach-que

Differential Revision: https://secure.phabricator.com/D14073
2015-11-03 07:02:46 +11:00
epriestley
59c9317101 Prevent mailing lists from being bin/auth recover'd
Summary:
Fixes T9610.

  - We currently permit you to `bin/auth recover` users who can not establish web sessions (but this will never work). Prevent this.
  - We don't emit a tailored error if you follow one of these links. Tailor the error.

Even with the first fix, you can still hit the second case by doing something like:

  - Recover a normal user.
  - Make them a mailing list in the DB.
  - Follow the recovery link.

The original issue here was an install that did a large migration and set all users to be mailing lists. Normal installs should never encounter this, but it's not wholly unreasonable to have daemons or mailing lists with the administrator flag.

Test Plan:
  - Tried to follow a recovery link for a mailing list.
  - Tried to generate a recovery link for a mailing list.
  - Generated and followed a recovery link for a normal administrator.

{F906342}

```
epriestley@orbital ~/dev/phabricator $ ./bin/auth recover tortise-list
Usage Exception: This account ("tortise-list") can not establish web sessions, so it is not possible to generate a functional recovery link. Special accounts like daemons and mailing lists can not log in via the web UI.
```

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9610

Differential Revision: https://secure.phabricator.com/D14325
2015-10-24 18:12:56 -07:00
epriestley
b038041dc6 Prevent duplicate account links from being created by swapping logins and then refreshing the link
Summary:
Fixes T6707. Users can currently do this:

  - Log in to a service (like Facebook or Google) with account "A".
  - Link their Phabricator account to that account.
  - Log out of Facebook, log back in with account "B".
  - Refresh the account link from {nav Settings > External Accounts}.

When they do this, we write a second account link (between their Phabricator account and account "B"). However, the rest of the codebase assumes accounts are singly-linked, so this breaks down elsewhere.

For now, decline to link the second account. We'll permit this some day, but need to do more work to allow it, and the need is very rare.

Test Plan:
  - Followed the steps above, hit the new error.
  - Logged back in to the proper account and did a link refresh (which worked).

{F905562}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T6707

Differential Revision: https://secure.phabricator.com/D14319
2015-10-24 04:50:36 -07:00
epriestley
5dccc14bbf Modularize generation of supplemental login messages
Summary:
Ref T9346. This mostly allows us to give users additional advice based on which instance they are trying to log in to in the Phacility cluster.

It's also slightly more flexible than `auth.login-message` was, and maybe we'll add some more hooks here eventually.

This feels like it's a sidegrade in complexity rather than really an improvement, but not too terrible.

Test Plan:
  - Wrote the custom handler in T9346 to replicate old config functionality.
  - Wrote a smart handler for Phacility that can provide context-sensitive messages based on which OAuth client you're trying to use.

See new message box at top (implementation in next diff):

{F780375}

Reviewers: chad

Reviewed By: chad

Maniphest Tasks: T9346

Differential Revision: https://secure.phabricator.com/D14057
2015-09-04 10:34:39 -07:00
epriestley
29948eaa5b Use phutil_hashes_are_identical() when comparing hashes in Phabricator
Summary: See D14025. In all cases where we compare hashes, use strict, constant-time comparisons.

Test Plan: Logged in, logged out, added TOTP, ran Conduit, terminated sessions, submitted forms, changed password. Tweaked CSRF token, got rejected.

Reviewers: chad

Reviewed By: chad

Subscribers: chenxiruanhai

Differential Revision: https://secure.phabricator.com/D14026
2015-09-01 15:52:44 -07:00
epriestley
b4b5d60f77 Fix 'key'/'type' swap in email reset / one-time-login controller
Summary: Fixes T9046. These got swapped around during refactoring.

Test Plan:
  - Used `bin/auth recover` prior to patch (failed).
  - Used `bin/auth recover` after patch (worked).

Reviewers: joshuaspence, chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T9046

Differential Revision: https://secure.phabricator.com/D13778
2015-08-03 08:01:43 -07:00
Chad Little
36103dfa18 Update Auth for handleRequest
Summary: Updates Auth app for handleRequest

Test Plan: Tested what I could, Log in, Log out, Change Password, New account, Verify account... but extra eyes very helpful here.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: epriestley, Korvin

Maniphest Tasks: T8628

Differential Revision: https://secure.phabricator.com/D13748
2015-08-01 16:49:27 -07:00
Joshua Spence
2d5f3d9e5a Fix a pht string
Summary:
This translation string is wrong and causes the following warning when running unit tests:

```
[2015-06-15 16:03:41] ERROR 2: vsprintf(): Too few arguments at [/home/joshua/workspace/github.com/phacility/libphutil/src/internationalization/PhutilTranslator.php:95]
arcanist(head=master, ref.master=956bfa701c36), phabricator(head=master, ref.master=80f11427e576), phutil(head=master, ref.master=3ff84448a916)
  #0 vsprintf(string, array) called at [<phutil>/src/internationalization/PhutilTranslator.php:95]
  #1 PhutilTranslator::translate(string)
  #2 call_user_func_array(array, array) called at [<phutil>/src/internationalization/pht.php:17]
  #3 pht(string) called at [<phabricator>/src/applications/auth/controller/PhabricatorAuthStartController.php:75]
  #4 PhabricatorAuthStartController::handleRequest(AphrontRequest) called at [<phabricator>/src/aphront/AphrontController.php:69]
  #5 AphrontController::delegateToController(PhabricatorAuthStartController) called at [<phabricator>/src/applications/base/controller/PhabricatorController.php:213]
  #6 PhabricatorController::willBeginExecution() called at [<phabricator>/src/applications/base/controller/__tests__/PhabricatorAccessControlTestCase.php:270]
  #7 PhabricatorAccessControlTestCase::checkAccess(string, PhabricatorTestController, AphrontRequest, array, array) called at [<phabricator>/src/applications/base/controller/__tests__/PhabricatorAccessControlTestCase.php:112]
  #8 PhabricatorAccessControlTestCase::testControllerAccessControls()
  #9 call_user_func_array(array, array) called at [<arcanist>/src/unit/engine/phutil/PhutilTestCase.php:492]
  #10 PhutilTestCase::run() called at [<arcanist>/src/unit/engine/PhutilUnitTestEngine.php:65]
  #11 PhutilUnitTestEngine::run() called at [<arcanist>/src/workflow/ArcanistUnitWorkflow.php:186]
  #12 ArcanistUnitWorkflow::run() called at [<arcanist>/scripts/arcanist.php:382]
```

Test Plan: `arc lint`

Reviewers: epriestley, #blessed_reviewers, chad

Reviewed By: #blessed_reviewers, chad

Subscribers: epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D13292
2015-06-15 18:01:09 +10:00
Joshua Spence
36e2d02d6e phtize all the things
Summary: `pht`ize a whole bunch of strings in rP.

Test Plan: Intense eyeballing.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: hach-que, Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D12797
2015-05-22 21:16:39 +10:00
epriestley
47b14c9bde Convert inline profile image transforms to new transformations
Summary:
Ref T7707. Fixes T7879. Fixes T4406. When creating profile images:

  - Use the new transforms;
  - mark them as "profile" images so they're forced to the most-open policies.

Test Plan:
  - Set restrictive default file policies.
  - Changed profile picture, project pictures, etc. Verified they were visible to logged-out users.
  - Registered via OAuth.
  - Updated a Conpherence thread image.
  - Browsed around looking for profile images, fixed sizing on everything I could find.

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7879, T7707, T4406

Differential Revision: https://secure.phabricator.com/D12821
2015-05-13 11:38:46 -07:00
epriestley
1c32c9b965 Improve granluarity and defaults of security.allow-outbound-http
Summary:
Ref T6755. This is a partial fix, but:

  - Allow netblocks to be blacklisted instead of making the feature all-or-nothing.
  - Default to disallow requests to all reserved private/local/special IP blocks. This should generally be a "safe" setting.
  - Explain the risks better.
  - Improve the errors rasied by Macro when failing.
  - Removed `security.allow-outbound-http`, as it is superseded by this setting and is somewhat misleading.
    - We still make outbound HTTP requests to OAuth.
    - We still make outbound HTTP requests for repositories.

From a technical perspective:

  - Separate URIs that are safe to link to or redirect to (basically, not "javascript://") from URIs that are safe to fetch (nothing in a private block).
  - Add the default blacklist.
  - Be more careful with response data in Macro fetching, and don't let the user see it if it isn't ultimately valid.

Additionally:

  - I want to do this check before pulling repositories, but that's enough of a mess that it should go in a separate diff.
  - The future implementation of T4190 needs to perform the fetch check.

Test Plan:
  - Fetched a valid macro.
  - Fetched a non-image, verified it didn't result in a viewable file.
  - Fetched a private-ip-space image, got an error.
  - Fetched a 404, got a useful-enough error without additional revealing response content (which is usually HTML anyway and not useful).
  - Fetched a bad protocol, got an error.
  - Linked to a local resource, a phriction page, a valid remote site, all worked.
  - Linked to private IP space, which worked fine (we want to let you link and redierect to other private services, just not fetch them).
  - Added and executed unit tests.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6755

Differential Revision: https://secure.phabricator.com/D12136
2015-03-23 10:44:03 -07:00
Chad Little
aa909ba072 Shorten buttons on Leaving High Security Page
Summary: Changes the text to just "Stay", which is still obvious what it means, with less copy. Fixes T7027

Test Plan: Now works on mobile.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T7027

Differential Revision: https://secure.phabricator.com/D12075
2015-03-14 07:35:01 -07:00
Chad Little
6608eea91d Fix a few minor bugs in Auth Providers
Summary: Fixes T7496, T7511. Sets text for registration is not enabled, sets can_manage on add_provider button.

Test Plan: Test with a logged in admin and logged in normal joe user.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T7496, T7511

Differential Revision: https://secure.phabricator.com/D12014
2015-03-08 11:04:57 -07:00
Chad Little
076cc6ed7e Change setErrorView to setInfoView in PHUIObjectBoxView
Summary: Renames the method in PHUIObjectBoxView to match the new PHUIInfoView class.

Test Plan: grepped codebase. Went to Calendar and tried a new status.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D12005
2015-03-06 17:03:18 -08:00
Chad Little
c038c643f4 Move PHUIErrorView to PHUIInfoView
Summary: Since this element isn't strictly about errors, re-label as info view instead.

Test Plan: Grepped for all callsites, tested UIExamples and a few other random pages.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: hach-que, Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11867
2015-03-01 14:45:56 -08:00
epriestley
4e41e164e5 Skip captcha when redeeming an invite
Summary: This wasn't actually being skipped for invites; really skip it.

Test Plan:
  - Registered without invite, captcha.
  - Registered with invite, no captcha.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D11877
2015-02-24 15:07:44 -08:00
Bob Trahan
d39da529ca Legalpad - allow for legalpad documents to be required to be signed for using Phabricator
Summary: Fixes T7159.

Test Plan:
Created a legalpad document that needed a signature and I was required to sign it no matter what page I hit. Signed it and things worked! Added a new legalpad document and I had to sign again!

Ran unit tests and they passed!

Logged out as a user who was roadblocked into signing a bunch of stuff and it worked!

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T7159

Differential Revision: https://secure.phabricator.com/D11759
2015-02-12 15:22:56 -08:00
epriestley
7797443428 Support invites in the registration and login flow
Summary:
Ref T7152. This substantially completes the upstream login flow. Basically, we just cookie you and push you through normal registration, with slight changes:

  - All providers allow registration if you have an invite.
  - Most providers get minor text changes to say "Register" instead of "Login" or "Login or Register".
  - The Username/Password provider changes to just a "choose a username" form.
  - We show the user that they're accepting an invite, and who invited them.

Then on actual registration:

  - Accepting an invite auto-verifies the address.
  - Accepting an invite auto-approves the account.
  - Your email is set to the invite email and locked.
  - Invites get to reassign nonprimary, unverified addresses from other accounts.

But 98% of the code is the same.

Test Plan:
  - Accepted an invite.
  - Verified a new address on an existing account via invite.
  - Followed a bad invite link.
  - Tried to accept a verified invite.
  - Reassigned an email by accepting an unverified, nonprimary invite on a new account.
  - Verified that reassigns appear in the activity log.

{F291493}
{F291494}
{F291495}
{F291496}
{F291497}
{F291498}
{F291499}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7152

Differential Revision: https://secure.phabricator.com/D11737
2015-02-11 06:06:28 -08:00
epriestley
2a0af8e299 Add email invites to Phabricator (logic only)
Summary:
Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests.

There's no UI to create these yet, so users can't actually get invites (and administrators can't send them).

This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere.

The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible.

Test Plan: Unit tests only.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T7152

Differential Revision: https://secure.phabricator.com/D11723
2015-02-09 16:12:36 -08:00
epriestley
8c568d88d7 Reduce severity of auth provider warning
Summary:
Ref T7208. Now that we have approvals (new installs are safe by default), take those into account when generating this warning.

Try to soften the warning to cover the case discussed in T7208, hopefully without requiring additional measures.

Test Plan:
{F286014}

{F286015}

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T7208

Differential Revision: https://secure.phabricator.com/D11708
2015-02-07 14:45:27 -08:00
Chad Little
272ce408dc Clean up authentication list
Summary: Uses more standard boxes for display, and icons!

Test Plan:
Test with all enabled, all disabled, and a mix.

{F285945}

{F285946}

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11707
2015-02-07 10:46:30 -08:00
Bob Trahan
472f316bbd Auth - allow for "auto login" providers
Summary: Ref T7153. I am not sure if this is 100% correct because sometimes you have to POST vs GET and I don't know if the redirect response will / can do the right thing? I think options to fix this would be to 1) restrict this functionality to JUST the Phabricator OAuth provider type or 2) something really fancy with an HTTP(S) future.  The other rub right now is when you logout you get half auto-logged in again... Thoughts on that?

Test Plan: setup my local instance to JUST have phabricator oauth available to login. was presented with the dialog automagically...!

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T7153

Differential Revision: https://secure.phabricator.com/D11701
2015-02-06 10:50:36 -08:00
Chad Little
3da38c74da PHUIErrorView
Summary: Clean up the error view styling.

Test Plan:
Tested as many as I could find, built additional tests in UIExamples

{F280452}

{F280453}

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: hach-que, Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11605
2015-02-01 20:14:56 -08:00
Chad Little
33c0b9423f More crumb borders
Summary: Misc crumb borders

Test Plan: reload pages

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11606
2015-02-01 20:12:13 -08:00
Bob Trahan
7d309a8e46 Application Emails - make various user email editing paths respect application emails
Summary: Ref T3404. The only mildly sketchy bit is these codepaths all load the application email directly, by-passing privacy. I think this is necessary because not getting to see an application doesn't mean you should be able to break the application by registering a colliding email address.

Test Plan:
Tried to add a registered application email to a user account via the web ui and got a pretty error.
Ran unit tests.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T3404

Differential Revision: https://secure.phabricator.com/D11565
2015-01-29 14:41:09 -08:00
Chad Little
170dc15c05 Make border conditional in crumbs
Summary: Add a setBorder call to CrumbsView to be more deliberate when a border is drawn. Could not find any CSS hacks to set it conditionally CSS.

Test Plan: Browsed every application that called crumbs and make a design decision. Also fixed a few bad layouts.

Reviewers: btrahan, epriestley

Reviewed By: btrahan

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D11533
2015-01-28 09:33:49 -08:00
Joshua Spence
c2ac63e9ad Increase visibility of PhabricatorController::buildApplicationMenu methods
Summary: Ref T6822. This method needs to be `public` because it is called from `PhabricatorApplicationSearchController::buildApplicationMenu()`.

Test Plan: I wouldn't expect //increasing// method visibility to break anything.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T6822

Differential Revision: https://secure.phabricator.com/D11416
2015-01-16 07:41:26 +11:00
epriestley
bdfbad092b Fix an issue with Auth edit 404ing
Summary: Fixes T6971. This parameter got updated slightly wrong.

Test Plan: Edited an auth provider.

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6971

Differential Revision: https://secure.phabricator.com/D11392
2015-01-14 11:04:22 -08:00
epriestley
39406bd1f3 Fix access to undeclared variable when trying to create invalid Auth provider
Summary: Ref T6971. This fixes the error the user reported. Not sure what's up with the root cause of their issue.

Test Plan: Went to `/auth/config/new/asdfqwer/` and got a 404 instead of an exception.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Maniphest Tasks: T6971

Differential Revision: https://secure.phabricator.com/D11388
2015-01-14 06:55:18 -08:00
Bob Trahan
46913f651e Auth - add "manage providers" capability
Summary: Ref T6947.

Test Plan: toggled setting in application settings and changes stuck. set policy to admin user a only and could not add a provider as a admin user b.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T6947

Differential Revision: https://secure.phabricator.com/D11356
2015-01-12 14:37:58 -08:00
epriestley
e0aa33c46b Make test for setting "next" cookie more general
Summary:
Ref T6870. Since it does not make sense to redirect the user to the login form after they log in, we try not to set the login form as the `next` cookie.

However, the current check is hard-coded to `/auth/start/`, and the form can also be served at `/login/`. This has no real effect on normal users, but did make debugging T6870 confusing.

Instead of using a hard-coded path check, test if the controller was delegated to. If it was, store the URI. If it's handling the request without delegation, don't.

Test Plan:
  - Visited login form at `/login/` and `/auth/start/`, saw it not set a next URI.
  - Visited login form at `/settings/` (while logged out), saw it set a next URI.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley, lpriestley

Maniphest Tasks: T6870

Differential Revision: https://secure.phabricator.com/D11292
2015-01-09 06:42:03 -08:00
Bob Trahan
2be746fb1f Auth - restore Phabricator OAuth as a provider
Summary: So meta it hurts. Fixes T887.

Test Plan: created a second instance of phabricator locally. made an account on oauth server phabricator. set up my normal dev phabricator to use this new oauth phabricator. noted the form worked. created an account via the oauth method and it worked.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T887

Differential Revision: https://secure.phabricator.com/D11287
2015-01-08 16:28:04 -08:00
Joshua Spence
e7f8e79742 Fix method visibility for PhabricatorController subclasses
Summary: Ref T6822.

Test Plan: Visual inspection. These methods are only called from within `PhabricatorController` subclasses.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T6822

Differential Revision: https://secure.phabricator.com/D11241
2015-01-07 07:34:59 +11:00
Joshua Spence
4e28de07fe Rename PhabricatorSettingsPanel subclasses for consistency
Summary: Ref T5655.

Test Plan: `arc lint` and `arc unit`

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T5655

Differential Revision: https://secure.phabricator.com/D11136
2015-01-02 15:20:08 +11:00
Bob Trahan
69cc5df645 Transactions - deploy buildTransactionTimeline against a few more applications
Summary:
Ref T4712. Thus far, it seems that most "non-standard" things can be done pretty easily in the controller. Aside from deploying, this diff had to fix a few bugs / missing implementations of stuff.

(Notably, PhabricatorAuthProviderConfig, HeraldRule, PhabricatorSlowvotePoll, and AlmanacNetwork needed to implement PhabricatorApplicationTransactionInterface, PhabricatorAuthAuthProviderPHIDType had to be added, and a rendering bug in transactions of type PhabricatorOAuth2AuthProvider had to be fixed.)

Test Plan: Almanac - looked at binding, device, network, and service view controllers and verified timeline displayed properly. Herald - looked at a rule and verified timeline. Slowvote - looked at a vote and verified timeline. Auth - looked at an auth provider (Facebook) and verified proper display of transactions within timeline.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Maniphest Tasks: T4712

Differential Revision: https://secure.phabricator.com/D10921
2014-12-02 14:33:59 -08:00
epriestley
5e0f218fe4 Allow device SSH keys to be trusted
Summary:
Ref T6240. Some discussion in that task. In instance/cluster environments, daemons need to make Conduit calls that bypass policy checks.

We can't just let anyone add SSH keys with this capability to the web directly, because then an adminstrator could just add a key they own and start signing requests with it, bypassing policy checks.

Add a `bin/almanac trust-key --id <x>` workflow for trusting keys. Only trusted keys can sign requests.

Test Plan:
  - Generated a user key.
  - Generated a device key.
  - Trusted a device key.
  - Untrusted a device key.
  - Hit the various errors on trust/untrust.
  - Tried to edit a trusted key.

{F236010}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T6240

Differential Revision: https://secure.phabricator.com/D10878
2014-11-20 17:33:30 -08:00
Evan Priestley
32cdc23efc Separate SSH key management from the settings panel
Summary:
Ref T5833. I want to add SSH keys to Almanac devices, but the edit workflows for them are currently bound tightly to users.

Instead, decouple key management from users and the settings panel.

Test Plan:
  - Uploaded, generated, edited and deleted SSH keys.
  - Hit missing name, missing key, bad key format, duplicate key errors.
  - Edited/generated/deleted/etc keys for a bot user as an administrator.
  - Got HiSec'd on everything.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5833

Differential Revision: https://secure.phabricator.com/D10824
2014-11-11 08:18:26 -08:00
Chad Little
4307d6816d Linkify Registration Email
Summary: Missed this in previous pass. Send these as links in HTML emails.

Test Plan: Register a new user that nees approval.

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: Korvin, epriestley

Differential Revision: https://secure.phabricator.com/D10815
2014-11-07 14:16:30 -08:00
Joshua Spence
3cf9a5820f Minor formatting changes
Summary: Apply some autofix linter rules.

Test Plan: `arc lint` and `arc unit`

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley, Korvin, hach-que

Differential Revision: https://secure.phabricator.com/D10585
2014-10-08 08:39:49 +11:00
Chad Little
f74082aecd Update AphrontRequestFailure to common display libs
Summary: Moves to PHUIObjectBox, removes old CSS

Test Plan: Pull up 404 page.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D10578
2014-09-26 17:40:09 -07:00
epriestley
4a566f9e5d Allow passwords to be edited even if account.editable is false
Summary:
Fixes T5900. We have some very old code here which does not let you update your password if the `account.editable` flag is set.

This was approximately introduced in D890, and I think it was mostly copy/pasted at that point. I'm not sure this ever really made sense. The option is not documented as affecting this, for example. In the modern environment of auth providers, it definitely does not make sense.

Instead, always allow users to change passwords if the install has a password provider configured.

Test Plan:
  - Set `account.editable` to false.
  - Used a password reset link.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5900

Differential Revision: https://secure.phabricator.com/D10331
2014-08-21 15:35:43 -07:00
epriestley
d011f8fdc6 Add a setting to disable all notification email
Summary: Ref T5861. Adds an option to opt out of all notification email. We'll still send you password resets, email verifications, etc.

Test Plan:
{F189484}

  - Added unit tests.
  - With preference set to different things, tried to send myself mail. Mail respected preferences.
  - Sent password reset email, which got through the preference.

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: rush898, epriestley

Maniphest Tasks: T5861

Differential Revision: https://secure.phabricator.com/D10237
2014-08-12 12:28:29 -07:00
epriestley
6232e9676c Don't send reset links to unverified addresses on accounts with verified addresses
Summary:
Via HackerOne. If a user adds an email address and typos it, entering `alinculne@gmailo.com`, and it happens to be a valid address which an evil user controls, the evil user can request a password reset and compromise the account.

This strains the imagination, but we can implement a better behavior cheaply.

  - If an account has any verified addresses, only send to verified addresses.
  - If an account has no verified addresses (e.g., is a new account), send to any address.

We've also received several reports about reset links not being destroyed as aggressively as researchers expect. While there's no specific scenario where this does any harm, revoke all outstanding reset tokens when a reset link is used to improve the signal/noise ratio of the reporting channel.

Test Plan:
  - Tried to send a reset link to an unverified address on an account with a verified address (got new error).
  - Tried to send a reset link to a verified adddress on an account with a verified address (got email).
  - Tried to send a reset link to an invalid address (got old error).
  - Tried to send a reset link to an unverified address on an account with only unverified addresses -- a new user (got email).
  - Requested several reset links, used one, verified all the others were revoked.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D10206
2014-08-11 12:13:09 -07:00
Joshua Spence
8fd098329b Rename AphrontQueryException subclasses
Summary: Ref T5655. Depends on D10149.

Test Plan: Ran `arc unit`

Reviewers: epriestley, #blessed_reviewers

Reviewed By: epriestley, #blessed_reviewers

Subscribers: epriestley, Korvin, hach-que

Maniphest Tasks: T5655

Differential Revision: https://secure.phabricator.com/D10150
2014-08-06 07:51:21 +10:00
epriestley
95eeffff7e Terminate other sessions on credential changes
Summary:
Fixes T5509. Currently, existing sessions live on even if you change your password.

Over the course of the program, we've recieved a lot of HackerOne reports that sessions do not terminate when users change their passwords. I hold that this isn't a security vulnerability: users can explicitly manage sessions, and this is more general and more powerful than tying session termination to password resets. In particular, many installs do not use a password provider at all (and no researcher has reported this in a general, application-aware way that discusses multiple authentication providers).

That said, dealing with these false positives is vaguely time consuming, and the "expected" behavior isn't bad for users, so just align behavior with researcher expectations: when passwords are changed, providers are removed, or multi-factor authentication is added to an account, terminate all other active login sessions.

Test Plan:
  - Using two browsers, established multiple login sessions.
  - In one browser, changed account password. Saw session terminate and logout in the second browser.
  - In one browser, removed an authentication provider. Saw session terminate and logout in the second browser.
  - In one browser, added MFA. Saw session terminate and logout in the second browser.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5509

Differential Revision: https://secure.phabricator.com/D10135
2014-08-04 12:04:35 -07:00
epriestley
e56dc8f299 Invalidate outstanding password reset links when users adjust email addresses
Summary:
Fixes T5506. Depends on D10133. When users remove an email address or change their primary email address, invalidate any outstanding password reset links.

This is a very small security risk, but the current behavior is somewhat surprising, and an attacker could sit on a reset link for up to 24 hours and then use it to re-compromise an account.

Test Plan:
  - Changed primary address and removed addreses.
  - Verified these actions invalidated outstanding one-time login temporary tokens.
  - Tried to use revoked reset links.
  - Revoked normally from new UI panel.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5506

Differential Revision: https://secure.phabricator.com/D10134
2014-08-04 12:04:23 -07:00
epriestley
30f6405a86 Add an explicit temporary token management page to Settings
Summary:
Ref T5506. This makes it easier to understand and manage temporary tokens.

Eventually this could be more user-friendly, since it's relatively difficult to understand what this screen means. My short-term goal is just to make the next change easier to implement and test.

The next diff will close a small security weakness: if you change your email address, password reset links which were sent to the old address are still valid. Although an attacker would need substantial access to exploit this (essentially, it would just make it easier for them to re-compromise an already compromised account), it's a bit surprising. In the next diff, email address changes will invalidate outstanding password reset links.

Test Plan:
  - Viewed outstanding tokens.
  - Added tokens to the list by making "Forgot your password?" requests.
  - Revoked tokens individually.
  - Revoked all tokens.
  - Tried to use a revoked token.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5506

Differential Revision: https://secure.phabricator.com/D10133
2014-08-04 12:04:13 -07:00
epriestley
49bd5721c5 Use standard infrastructure for Feed in Audit
Summary: Ref T4896. Instead of using custom stuff, use standard stuff.

Test Plan: Viewed a bunch of feed stories and published some over the Asana bridge.

Reviewers: joshuaspence, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T4896

Differential Revision: https://secure.phabricator.com/D10114
2014-08-02 00:06:56 -07:00
Joshua Spence
f4b05312cd Fix broken references to auth adapters
This was broken in D9999 but somehow didn't fail linting or unit tests.

Auditors: epriestley
2014-07-22 21:20:45 +10:00
epriestley
e46826ad36 Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.

External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.

Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.

However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).

Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:

  - Add `CAN_EDIT` on these objects.
  - Make that very restricted, but open up `CAN_VIEW`.
  - Require `CAN_EDIT` any time we're going to do something authentication/identity related.

This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.

I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.

Test Plan:
  - Viewed external accounts.
  - Linked an external account.
  - Refreshed an external account.
  - Edited profile picture.
  - Viewed sessions panel.
  - Published a bunch of stuff to Asana/JIRA.
  - Legalpad signature page now shows external accounts.

{F171595}

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3732, T1205, T3116

Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 10:18:10 -07:00
epriestley
46d9bebc84 Remove all device = true from page construction
Summary: Fixes T5446. Depends on D9687.

Test Plan: Mostly regexp'd this. Lint doesn't complain.

Reviewers: chad

Reviewed By: chad

Subscribers: epriestley, hach-que

Maniphest Tasks: T5446

Differential Revision: https://secure.phabricator.com/D9690
2014-06-23 15:18:14 -07:00
Joshua Spence
0a62f13464 Change double quotes to single quotes.
Summary: Ran `arc lint --apply-patches --everything` over rP, mainly to change double quotes to single quotes where appropriate. These changes also validate that the `ArcanistXHPASTLinter::LINT_DOUBLE_QUOTE` rule is working as expected.

Test Plan: Eyeballed it.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley, Korvin, hach-que

Differential Revision: https://secure.phabricator.com/D9431
2014-06-09 11:36:50 -07:00
epriestley
99c72a32d0 Allow installs to require multi-factor authentication for all users
Summary: Ref T5089. Adds a `security.require-multi-factor-auth` which forces all users to enroll in MFA before they can use their accounts.

Test Plan:
Config:

{F159750}

Roadblock:

{F159748}

After configuration:

{F159749}

  - Required MFA, got roadblocked, added MFA, got unblocked.
  - Removed MFA, got blocked again.
  - Used `bin/auth strip` to strip MFA, got blocked.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T5089

Differential Revision: https://secure.phabricator.com/D9285
2014-06-03 16:50:27 -07:00
epriestley
83112cc2e8 Move email verification into PhabricatorUserEditor
Summary: Both email verify and welcome links now verify email, centralize them and record them in the user activity log.

Test Plan:
  - Followed a "verify email" link and got verified.
  - Followed a "welcome" (verifying) link.
  - Followed a "reset" (non-verifying) link.
  - Looked in the activity log for the verifications.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D9284
2014-06-03 16:45:18 -07:00
epriestley
f1534e6feb Make password reset emails use one-time tokens
Summary:
Ref T4398. This code hadn't been touched in a while and had a few crufty bits.

**One Time Resets**: Currently, password reset (and similar links) are valid for about 48 hours, but we always use one token to generate them (it's bound to the account). This isn't horrible, but it could be better, and it produces a lot of false positives on HackerOne.

Instead, use TemporaryTokens to make each link one-time only and good for no more than 24 hours.

**Coupling of Email Verification and One-Time Login**: Currently, one-time login links ("password reset links") are tightly bound to an email address, and using a link verifies that email address.

This is convenient for "Welcome" emails, so the user doesn't need to go through two rounds of checking email in order to login, then very their email, then actually get access to Phabricator.

However, for other types of these links (like those generated by `bin/auth recover`) there's no need to do any email verification.

Instead, make the email verification part optional, and use it on welcome links but not other types of links.

**Message Customization**: These links can come out of several workflows: welcome, password reset, username change, or `bin/auth recover`. Add a hint to the URI so the text on the page can be customized a bit to help users through the workflow.

**Reset Emails Going to Main Account Email**: Previously, we would send password reset email to the user's primary account email. However, since we verify email coming from reset links this isn't correct and could allow a user to verify an email without actually controlling it.

Since the user needs a real account in the first place this does not seem useful on its own, but might be a component in some other attack. The user might also no longer have access to their primary account, in which case this wouldn't be wrong, but would not be very useful.

Mitigate this in two ways:

  - First, send to the actual email address the user entered, not the primary account email address.
  - Second, don't let these links verify emails: they're just login links. This primarily makes it more difficult for an attacker to add someone else's email to their account, send them a reset link, get them to login and implicitly verify the email by not reading very carefully, and then figure out something interesting to do (there's currently no followup attack here, but allowing this does seem undesirable).

**Password Reset Without Old Password**: After a user logs in via email, we send them to the password settings panel (if passwords are enabled) with a code that lets them set a new password without knowing the old one.

Previously, this code was static and based on the email address. Instead, issue a one-time code.

**Jump Into Hisec**: Normally, when a user who has multi-factor auth on their account logs in, we prompt them for factors but don't put them in high security. You usually don't want to go do high-security stuff immediately after login, and it would be confusing and annoying if normal logins gave you a "YOU ARE IN HIGH SECURITY" alert bubble.

However, if we're taking you to the password reset screen, we //do// want to put the user in high security, since that screen requires high security. If we don't do this, the user gets two factor prompts in a row.

To accomplish this, we set a cookie when we know we're sending the user into a high security workflow. This cookie makes login finalization upgrade all the way from "partial" to "high security", instead of stopping halfway at "normal". This is safe because the user has just passed a factor check; the only reason we don't normally do this is to reduce annoyance.

**Some UI Cleanup**: Some of this was using really old UI. Modernize it a bit.

Test Plan:
  - **One Time Resets**
    - Used a reset link.
    - Tried to reuse a reset link, got denied.
    - Verified each link is different.
  - **Coupling of Email Verification and One-Time Login**
    - Verified that `bin/auth`, password reset, and username change links do not have an email verifying URI component.
    - Tried to tack one on, got denied.
    - Used the welcome email link to login + verify.
    - Tried to mutate the URI to not verify, or verify something else: got denied.
  - **Message Customization**
    - Viewed messages on the different workflows. They seemed OK.
  - **Reset Emails Going to Main Account Email**
    - Sent password reset email to non-primary email.
    - Received email at specified address.
    - Verified it does not verify the address.
  - **Password Reset Without Old Password**
    - Reset password without knowledge of old one after email reset.
    - Tried to do that without a key, got denied.
    - Tried to reuse a key, got denied.
  - **Jump Into Hisec**
    - Logged in with MFA user, got factor'd, jumped directly into hisec.
    - Logged in with non-MFA user, no factors, normal password reset.
  - **Some UI Cleanup**
    - Viewed new UI.
  - **Misc**
    - Created accounts, logged in with welcome link, got verified.
    - Changed a username, used link to log back in.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T4398

Differential Revision: https://secure.phabricator.com/D9252
2014-05-22 10:41:00 -07:00
Tal Shiri
43d45c4956 can now tell phabricator you trust an auth provider's emails (useful for Google OAuth), which will mark emails as "verified" and will skip email verification.
Summary: This is useful when you're trying to onboard an entire office and you end up using the Google OAuth anyway.

Test Plan: tested locally. Maybe I should write some tests?

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley, Korvin

Differential Revision: https://secure.phabricator.com/D9150
2014-05-16 14:14:06 -07:00
Chad Little
0120388a75 Found some missing icons
Summary: Did a more exhaustive grep on setIcon and found 99.9% of the icons.

Test Plan: I verified icon names on UIExamples, but unable to test some of the more complex flows visually. Mostly a read and replace.

Reviewers: epriestley

Reviewed By: epriestley

Subscribers: epriestley, Korvin, hach-que

Differential Revision: https://secure.phabricator.com/D9088
2014-05-13 07:45:39 -07:00
Chad Little
b2f3001ec4 Replace Sprite-Icons with FontAwesome
Summary: The removes the sprite sheet 'icons' and replaces it with FontAwesome fonts.

Test Plan:
- Grep for SPRITE_ICONS and replace
- Grep for sprite-icons and replace
- Grep for PhabricatorActionList and choose all new icons
- Grep for Crumbs and fix icons
- Test/Replace PHUIList Icon support
- Test/Replace ObjectList Icon support (foot, epoch, etc)
- Browse as many pages as I could get to
- Remove sprite-icons and move remarkup to own sheet
- Review this diff in Differential

Reviewers: btrahan, epriestley

Reviewed By: epriestley

Subscribers: epriestley, Korvin, hach-que

Differential Revision: https://secure.phabricator.com/D9052
2014-05-12 10:08:32 -07:00
lkassianik
dfcccd4cb8 Add config to require real name, respect config when creating new users, drop real name from full name if not provided.
Summary: Fixes T4728, first pass, Make real name optional on user accounts

Test Plan: Default real name config should be false (not required). Create new user, real name should not be required. Toggle config, real name should be required. Users with no real name should be always listed by their usernames.

Reviewers: #blessed_reviewers, epriestley

Reviewed By: #blessed_reviewers, epriestley

Subscribers: epriestley, Korvin

Maniphest Tasks: T4728

Differential Revision: https://secure.phabricator.com/D9027
2014-05-12 09:51:41 -07:00
epriestley
50376aad04 Require multiple auth factors to establish web sessions
Summary:
Ref T4398. This prompts users for multi-factor auth on login.

Roughly, this introduces the idea of "partial" sessions, which we haven't finished constructing yet. In practice, this means the session has made it through primary auth but not through multi-factor auth. Add a workflow for bringing a partial session up to a full one.

Test Plan:
  - Used Conduit.
  - Logged in as multi-factor user.
  - Logged in as no-factor user.
  - Tried to do non-login-things with a partial session.
  - Reviewed account activity logs.

{F149295}

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T4398

Differential Revision: https://secure.phabricator.com/D8922
2014-05-01 10:23:02 -07:00
epriestley
3fde020049 Make many actions require high security
Summary:
Ref T4398. Protects these actions behind a security barrier:

  - Link external account.
  - Retrieve Conduit token.
  - Reveal Passphrase credential.
  - Create user.
  - Admin/de-admin user.
  - Rename user.
  - Show conduit certificate.
  - Make primary email.
  - Change password.
  - Change VCS password.
  - Add SSH key.
  - Generate SSH key.

Test Plan: Tried to take each action and was prompted for two-factor.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T4398

Differential Revision: https://secure.phabricator.com/D8921
2014-04-30 17:44:59 -07:00
epriestley
3f5a55fa6e Let users review their own account activity logs
Summary:
Ref T4398. This adds a settings panel for account activity so users can review activity on their own account. Some goals are:

  - Make it easier for us to develop and support auth and credential information, see T4398. This is the primary driver.
  - Make it easier for users to understand and review auth and credential information (see T4842 for an example -- this isn't there yet, but builds toward it).
  - Improve user confidence in security by making logging more apparent and accessible.

Minor corresponding changes:

  - Entering and exiting hisec mode is now logged.
  - This, sessions, and OAuth authorizations have moved to a new "Sessions and Logs" area, since "Authentication" was getting huge.

Test Plan:
  - Viewed new panel.
  - Viewed old UI.
  - Entered/exited hisec and got prompted.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T4398

Differential Revision: https://secure.phabricator.com/D8871
2014-04-27 17:32:09 -07:00
epriestley
f42ec84d0c Add "High Security" mode to support multi-factor auth
Summary:
Ref T4398. This is roughly a "sudo" mode, like GitHub has for accessing SSH keys, or Facebook has for managing credit cards. GitHub actually calls theirs "sudo" mode, but I think that's too technical for big parts of our audience. I've gone with "high security mode".

This doesn't actually get exposed in the UI yet (and we don't have any meaningful auth factors to prompt the user for) but the workflow works overall. I'll go through it in a comment, since I need to arrange some screenshots.

Test Plan: See guided walkthrough.

Reviewers: chad, btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T4398

Differential Revision: https://secure.phabricator.com/D8851
2014-04-27 17:31:11 -07:00
epriestley
d8713f6f0b Make dialogs a little easier to use
Summary:
  - Dialog pages currently have no titles or crumbs, and look shoddy. Add titles and crumbs.
  - Dialog titles aren't always great for crumbs, add an optional "short title" for crumbs.
  - `AphrontDialogResponse` is pure boilerplate. Allow controllers to just return a `DialogView` instead and get the same effect.
  - Building dialogs requires a bit of boilerplate, and we generally construct them with no explicit `"action"`, which has some issues with T4593. Provide a convenience method to set the viewer and get a reasonable, explict submit URI.

Test Plan:
  - Viewed dialog on its own.
  - Viewed dialog as a dialog.

{F132353}

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D8577
2014-03-21 14:40:05 -07:00
epriestley
aea624118b Allow users to terminate login sessions
Summary:
This is partly a good feature, and partly should reduce false positives on HackerOne reporting things vaguely related to this.

Allow a user to terminate login sessions from the settings panel.

Test Plan:
  - Terminated a session.
  - Terminated all sessions.
  - Tried to terminate all sessions again.
  - Logged in with two browsers, terminated the other browser's session, reloaded, got kicked out.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Differential Revision: https://secure.phabricator.com/D8556
2014-03-17 15:02:01 -07:00
epriestley
559c0fe886 Tune cookie behaviors for 'phcid', 'phreg', etc
Summary:
Fixes T3471. Specific issues:

  - Add the ability to set a temporary cookie (expires when the browser closes).
  - We overwrote 'phcid' on every page load. This creates some issues with browser extensions. Instead, only write it if isn't set. To counterbalance this, make it temporary.
  - Make the 'next_uri' cookie temporary.
  - Make the 'phreg' cookie temporary.
  - Fix an issue where deleted cookies would persist after 302 (?) in some cases (this is/was 100% for me locally).

Test Plan:
  - Closed my browser, reopned it, verified temporary cookies were gone.
  - Logged in, authed, linked, logged out.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: epriestley

Maniphest Tasks: T3471

Differential Revision: https://secure.phabricator.com/D8537
2014-03-14 14:33:31 -07:00
epriestley
f7b1ed7221 Fix two registration errors for unusual provider emails
Summary:
See <https://github.com/facebook/phabricator/issues/541>.

  - If a provider returns the email `""` or `"0"`, we currently don't let the user edit it and thus don't let them register.
  - If a provider returns an invalid email like `"!!!"` (permitted by GitHub, e.g.), we show them a nonsense error message.

Instead:

  - Pretend we didn't get an address if we get an invalid address.
  - Test the address strictly against `null`.

Test Plan: Registered on Phabricator with my GitHub email set to `""` (empty string) and `"!!!"` (bang bang bang).

Reviewers: btrahan, chad

Reviewed By: chad

Subscribers: aran, epriestley

Differential Revision: https://secure.phabricator.com/D8528
2014-03-13 19:03:12 -07:00
epriestley
7176240717 Whitelist controllers which can receive a 'code' parameter
Summary:
Ref T4593. There are a variety of clever attacks against OAuth which involve changing the redirect URI to some other URI on the same domain which exhibits unexpected behavior in response to an OAuth request. The best approach to dealing with this is for providers to lock to a specific path and refuse to redirect elsewhere, but not all providers do this.

We haven't had any specific issues related to this, but the anchor issue in T4593 was only a step away.

To mitigate this in general, we can reject the OAuth2 `'code'` parameter on //every// page by default, and then whitelist it on the tiny number of controllers which should be able to receive it.

This is very coarse, kind of overkill, and has some fallout (we can't use `'code'` as a normal parameter in the application), but I think it's relatively well-contained and seems reasonable. A better approach might be to whitelist parameters on every controller (i.e., have each controller specify the parameters it can receive), but that would be a ton of work and probably cause a lot of false positives for a long time.

Since we don't use `'code'` normally anywhere (as far as I can tell), the coarseness of this approach seems reasonable.

Test Plan:
  - Logged in with OAuth.
  - Hit any other page with `?code=...` in the URL, got an exception.
  - Grepped for `'code'` and `"code"`, and examined each use to see if it was impacted.

Reviewers: btrahan

Reviewed By: btrahan

Subscribers: aran, epriestley

Maniphest Tasks: T4593

Differential Revision: https://secure.phabricator.com/D8499
2014-03-12 11:30:04 -07:00
epriestley
e62c7321c2 Automatically verify the setup account's email address
Summary: Although the defaults don't require a verified email address, it's easy to lock yourself out by accident by configuring `auth.require-email-verification` or `auth.email-domains` before setting up email. Just force-verify the initial/setup account's address.

Test Plan: Went through setup on a fresh install, saw address verify.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D8365
2014-02-27 15:16:04 -08:00
epriestley
bcf255e9c9 Require CSRF submission to verify email addresses
Summary: If an attacker somehow intercepts a verification URL for an email address, they can hypothetically CSRF the account owner into verifying it. What you'd do before (how do you get the link?) and after (why do you care that you tricked them into verifying) performing this attack is unclear, but in theory we should require a CSRF submission here; add one.

Test Plan: {F118691}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D8351
2014-02-26 11:17:46 -08:00
epriestley
14627ad65b Fix an incorrectly spelled call on the registration error pathway
Summary: If you copy the registration URL, then register, then load the URL again while logged out (i.e., attempt to reuse the registration URL), we try to show you a tailored error message. However, this call is not correct so we show you a not-so tailored exception instead.

Test Plan:
  - Get to the registration screen.
  - Save URL.
  - Complete registration.
  - Log out.
  - Return to saved URL.

Previously, exception. Now, readable error.

{F117585}

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D8322
2014-02-24 11:45:28 -08:00
epriestley
a566ae3730 Require a CSRF code for Twitter and JIRA (OAuth 1) logins
Summary:
OAuth1 doesn't have anything like the `state` parameter, and I overlooked that we need to shove one in there somewhere. Append it to the callback URI. This functions like `state` in OAuth2.

Without this, an attacker can trick a user into logging into Phabricator with an account the attacker controls.

Test Plan:
  - Logged in with JIRA.
  - Logged in with Twitter.
  - Logged in with Facebook (an OAuth2 provider).
  - Linked a Twitter account.
  - Linked a Facebook account.
  - Jiggered codes in URIs and verified that I got the exceptions I expected.

Reviewers: btrahan, arice

Reviewed By: arice

CC: arice, chad, aran

Differential Revision: https://secure.phabricator.com/D8318
2014-02-23 16:39:24 -08:00
epriestley
7cf0358dda Disallow email addresses which will overflow MySQL storage
Summary:
Via HackerOne. An attacker can bypass `auth.email-domains` by registering with an email like:

  aaaaa...aaaaa@evil.com@company.com

We'll validate the full string, then insert it into the database where it will be truncated, removing the `@company.com` part. Then we'll send an email to `@evil.com`.

Instead, reject email addresses which won't fit in the table.

`STRICT_ALL_TABLES` stops this attack, I'm going to add a setup warning encouraging it.

Test Plan:
  - Set `auth.email-domains` to `@company.com`.
  - Registered with `aaa...aaa@evil.com@company.com`. Previously this worked, now it is rejected.
  - Did a valid registration.
  - Tried to add `aaa...aaaa@evil.com@company.com` as an email address. Previously this worked, now it is rejected.
  - Did a valid email add.
  - Added and executed unit tests.

Reviewers: btrahan, arice

Reviewed By: arice

CC: aran, chad

Differential Revision: https://secure.phabricator.com/D8308
2014-02-23 10:19:35 -08:00
epriestley
3c9153079f Make password hashing modular
Summary:
Ref T4443. Make hashing algorithms pluggable and extensible so we can deal with the attendant complexities more easily.

This moves "Iterated MD5" to a modular implementation, and adds a tiny bit of hack-glue so we don't need to migrate the DB in this patch. I'll migrate in the next patch, then add bcrypt.

Test Plan:
  - Verified that the same stuff gets stored in the DB (i.e., no functional changes):
    - Logged into an old password account.
    - Changed password.
    - Registered a new account.
    - Changed password.
    - Switched back to master.
    - Logged in / out, changed password.
    - Switched back, logged in.
  - Ran unit tests (they aren't super extensive, but cover some of the basics).

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, kofalt

Maniphest Tasks: T4443

Differential Revision: https://secure.phabricator.com/D8268
2014-02-18 14:09:36 -08:00
epriestley
152f05aebe Fix some security issues with email password resets
Summary:
Via HackerOne, there are two related low-severity issues with this workflow:

  - We don't check if you're already logged in, so an attacker can trick a victim (whether they're logged in or not) into clicking a reset link for an account the attacker controls (maybe via an invisible iframe) and log the user in under a different account.
  - We don't check CSRF tokens either, so after fixing the first thing, an attacker can still trick a //logged-out// victim in the same way.

It's not really clear that doing this opens up any significant attacks afterward, but both of these behaviors aren't good.

I'll probably land this for audit in a few hours if @btrahan doesn't have a chance to take a look at it since he's probably on a plane for most of the day, I'm pretty confident it doesn't break anything.

Test Plan:
  - As a logged-in user, clicked another user's password reset link and was not logged in.
  - As a logged-out user, clicked a password reset link and needed to submit a form to complete the workflow.

Reviewers: btrahan

CC: chad, btrahan, aran

Differential Revision: https://secure.phabricator.com/D8079
2014-01-27 16:53:04 -08:00
epriestley
5b1d9c935a After writing "next_uri", don't write it again for a while
Summary:
Fixes T3793. There's a lot of history here, see D4012, T2102. Basically, the problem is that things used to work like this:

  - User is logged out and accesses `/xyz/`. After they login, we'd like to send them back to `/xyz/`, so we set a `next_uri` cookie.
  - User's browser has a bunch of extensions and now makes a ton of requests for stuff that doesn't exist, like `humans.txt` and `apple-touch-icon.png`. We can't distinguish between these requests and normal requests in a general way, so we write `next_uri` cookies, overwriting the user's intent (`/xyz/`).

To fix this, we made the 404 page not set `next_uri`, in D4012. So if the browser requests `humans.txt`, we 404 with no cookie, and the `/xyz/` cookie is preserved. However, this is bad because an attacker can determine if objects exist and applications are installed, by visiting, e.g., `/T123` and seeing if they get a 404 page (resource really does not exist) or a login page (resource exists). We'd rather not leak this information.

The comment in the body text describes this in more detail.

This diff sort of tries to do the right thing most of the time: we write the cookie only if we haven't written it in the last 2 minutes. Generally, this should mean that the original request to `/xyz/` writes it, all the `humans.txt` requests don't write it, and things work like users expect. This may occasionally do the wrong thing, but it should be very rare, and we stop leaking information about applications and objects.

Test Plan: Logged out, clicked around / logged in, used Charles to verify that cookies were set in the expected way.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3793

Differential Revision: https://secure.phabricator.com/D8047
2014-01-23 14:16:08 -08:00
epriestley
69ddb0ced6 Issue "anonymous" sessions for logged-out users
Summary:
Ref T4339. Ref T4310. Currently, sessions look like `"afad85d675fda87a4fadd54"`, and are only issued for logged-in users. To support logged-out CSRF and (eventually) external user sessions, I made two small changes:

  - First, sessions now have a "kind", which is indicated by a prefix, like `"A/ab987asdcas7dca"`. This mostly allows us to issue session queries more efficiently: we don't have to issue a query at all for anonymous sessions, and can join the correct table for user and external sessions and save a query. Generally, this gives us more debugging information and more opportunity to recover from issues in a user-friendly way, as with the "invalid session" error in this diff.
  - Secondly, if you load a page and don't have a session, we give you an anonymous session. This is just a secret with no special significance.

This does not implement CSRF yet, but gives us a client secret we can use to implement it.

Test Plan:
  - Logged in.
  - Logged out.
  - Browsed around.
  - Logged in again.
  - Went through link/register.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4310, T4339

Differential Revision: https://secure.phabricator.com/D8043
2014-01-23 14:03:22 -08:00
epriestley
0727418023 Consolidate use of magical cookie name strings
Summary: Ref T4339. We have more magical cookie names than we should, move them all to a central location.

Test Plan: Registered, logged in, linked account, logged out. See inlines.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4339

Differential Revision: https://secure.phabricator.com/D8041
2014-01-23 14:01:35 -08:00
epriestley
02aa193cb0 Add a common password blacklist
Summary:
Fixes T4143. This mitigates the "use a botnet to slowly try to login to every user account using the passwords '1234', 'password', 'asdfasdf', ..." attack, like the one that hit GitHub.

(I also donated some money to Openwall as a thanks for compiling this wordlist.)

Test Plan:
  - Tried to register with a weak password; registered with a strong password.
  - Tried to set VCS password to a weak password; set VCS password to a strong password.
  - Tried to change password to a weak password; changed password to a strong password.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran, chad

Maniphest Tasks: T4143

Differential Revision: https://secure.phabricator.com/D8048
2014-01-23 14:01:18 -08:00
Chad Little
31a2bebf63 Move PhabricatorTagView to PHUITagView
Summary: For consistency and great justice.

Test Plan: tested audit, uiexamples, action headers

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7967
2014-01-14 14:09:52 -08:00
epriestley
d392a8f157 Replace "web" and "conduit" magic session strings with constants
Summary: Ref T4310. Ref T3720. We use bare strings to refer to session types in several places right now; use constants instead.

Test Plan: grep; logged out; logged in; ran Conduit commands.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4310, T3720

Differential Revision: https://secure.phabricator.com/D7963
2014-01-14 13:22:34 -08:00
epriestley
eef314b701 Separate session management from PhabricatorUser
Summary: Ref T4310. Ref T3720. Session operations are currently part of PhabricatorUser. This is more tightly coupled than needbe, and makes it difficult to establish login sessions for non-users. Move all the session management code to a `SessionEngine`.

Test Plan:
  - Viewed sessions.
  - Regenerated Conduit certificate.
  - Verified Conduit sessions were destroyed.
  - Logged out.
  - Logged in.
  - Ran conduit commands.
  - Viewed sessions again.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4310, T3720

Differential Revision: https://secure.phabricator.com/D7962
2014-01-14 13:22:27 -08:00
epriestley
220d680f37 Allow PhabricatorUserLog to store non-user PHIDs
Summary:
Ref T4310. This is a small step toward separating out the session code so we can establish sessions for `ExternalAccount` and not just `User`.

Also fix an issue with strict MySQL and un-admin / un-disable from web UI.

Test Plan: Logged in, logged out, admined/de-admin'd user, added email address, checked user log for all those events.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4310

Differential Revision: https://secure.phabricator.com/D7953
2014-01-14 11:05:26 -08:00
Chad Little
b74c7a3d37 Simplify PHUIObjectBoxViews handling of Save and Error states
Summary: This removes the bulk of the "Form Errors" text, some variations likely exists. These are a bit redundant and space consuming. I'd also like to back ErrorView more into PHUIObjectBox.

Test Plan: Test out the forms, see errors without the text.

Reviewers: epriestley, btrahan

CC: Korvin, epriestley, aran, hach-que

Differential Revision: https://secure.phabricator.com/D7924
2014-01-10 09:17:37 -08:00
epriestley
a5dc9067af Provide convenience method addTextCrumb() to PhabricatorCrumbsView
Summary: We currently have a lot of calls to `addCrumb(id(new PhabricatorCrumbView())->...)` which can be expressed much more simply with a convenience method. Nearly all crumbs are only textual.

Test Plan:
  - This was mostly automated, then I cleaned up a few unusual sites manually.
  - Bunch of grep / randomly clicking around.

Reviewers: btrahan, chad

Reviewed By: btrahan

CC: hach-que, aran

Differential Revision: https://secure.phabricator.com/D7787
2013-12-18 17:47:34 -08:00
epriestley
3a035c02e7 Recover more flexibly from an already-verified email
Summary:
Ref T4140. We could hit a redirect loop for a user with a verified primary email address but no "is verified" flag on their account. This shouldn't be possible since the migration should have set the flag, but we can deal with it more gracefully when it does happen (maybe because users forgot to run `storage/upgrade`, or because of ghosts).

In the controller, check the same flag we check before forcing the user to the controller.

When verifying, allow the verification if either the email or user flag isn't set.

Test Plan: Hit `/login/mustverify/`; verified an address.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T4140

Differential Revision: https://secure.phabricator.com/D7621
2013-11-21 14:41:32 -08:00
epriestley
a518626a85 Slightly improve behavior for unverified + unapproved users
Summary: Ref T4140. Allow unapproved users to verify their email addresses. Currently, unapproved blocks email verification, but should not.

Test Plan: Clicked email verification link as an unapproved user, got email verified.

Reviewers: btrahan, chad

Reviewed By: chad

CC: aran

Maniphest Tasks: T4140

Differential Revision: https://secure.phabricator.com/D7618
2013-11-21 12:58:58 -08:00
epriestley
fb6e38548b Respect "can edit username" in registration UI
Summary:
Fixes T3741. The flag is respected in terms of actually creating the account, but the UI is a bit unclear.

This can never occur naturally, but installs can register an event which locks it.

Test Plan:
Artificially locked it, verified I got more reasonable UI;

{F81282}

Reviewers: btrahan, datr

Reviewed By: datr

CC: aran

Maniphest Tasks: T3741

Differential Revision: https://secure.phabricator.com/D7577
2013-11-13 11:25:43 -08:00
epriestley
c0e1a63a63 Implement an approval queue
Summary:
  - Add an option for the queue.
  - By default, enable it.
  - Dump new users into the queue.
  - Send admins an email to approve them.

Test Plan:
  - Registered new accounts with queue on and off.
  - As an admin, approved accounts and disabled the queue from email.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7576
2013-11-13 11:24:56 -08:00
epriestley
c8320923c4 Implement most of the administrative UI for approval queues
Summary:
Nothing fancy here, just:

  - UI to show users needing approval.
  - "Approve" and "Disable" actions.
  - Send "Approved" email on approve.
  - "Approve" edit + log operations.
  - "Wait for Approval" state for users who need approval.

There's still no natural way for users to end up not-approved -- you have to write directly to the database.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7573
2013-11-13 11:24:18 -08:00
epriestley
7f11e8d740 Improve handling of email verification and "activated" accounts
Summary:
Small step forward which improves existing stuff or lays groudwork for future stuff:

  - Currently, to check for email verification, we have to single-query the email address on every page. Instead, denoramlize it into the user object.
    - Migrate all the existing users.
    - When the user verifies an email, mark them as `isEmailVerified` if the email is their primary email.
    - Just make the checks look at the `isEmailVerified` field.
  - Add a new check, `isUserActivated()`, to cover email-verified plus disabled. Currently, a non-verified-but-not-disabled user could theoretically use Conduit over SSH, if anyone deployed it. Tighten that up.
  - Add an `isApproved` flag, which is always true for now. In a future diff, I want to add a default-on admin approval queue for new accounts, to prevent configuration mistakes. The way it will work is:
    - When the queue is enabled, registering users are created with `isApproved = false`.
    - Admins are sent an email, "[Phabricator] New User Approval (alincoln)", telling them that a new user is waiting for approval.
    - They go to the web UI and approve the user.
    - Manually-created accounts are auto-approved.
    - The email will have instructions for disabling the queue.

I think this queue will be helpful for new installs and give them peace of mind, and when you go to disable it we have a better opportunity to warn you about exactly what that means.

Generally, I want to improve the default safety of registration, since if you just blindly coast through the path of least resistance right now your install ends up pretty open, and realistically few installs are on VPNs.

Test Plan:
  - Ran migration, verified `isEmailVerified` populated correctly.
  - Created a new user, checked DB for verified (not verified).
  - Verified, checked DB (now verified).
  - Used Conduit, People, Diffusion.

Reviewers: btrahan

Reviewed By: btrahan

CC: chad, aran

Differential Revision: https://secure.phabricator.com/D7572
2013-11-12 14:37:04 -08:00
epriestley
cd73fe78db Roadblock users trying to register with external accounts that have invalid emails
Summary:
Ref T3472. Currently, if an install only allows "@mycompany.com" emails and you try to register with an "@personal.com" account, we let you pick an "@mycompany.com" address instead. This is secure: you still have to verify the email. However, it defies user expectation -- it's somewhat confusing that we let you register. Instead, provide a hard roadblock.

(These accounts can still be linked, just not used for registration.)

Test Plan: See screenshot.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Maniphest Tasks: T3472

Differential Revision: https://secure.phabricator.com/D7571
2013-11-12 14:36:49 -08:00
epriestley
30a51dac36 Clarify registration rules more aggressively when configuring auth
Summary: See private chatter. Make it explicitly clear when adding a provider that anyone who can browse to Phabricator can register.

Test Plan: See screenshots.

Reviewers: btrahan

Reviewed By: btrahan

CC: aran

Differential Revision: https://secure.phabricator.com/D7570
2013-11-12 10:56:47 -08:00
Jakub Vrana
a29b5b070f Replace some hsprintf() by phutil_tag()
Test Plan: Looked at a diff with inline comment.

Reviewers: epriestley

Reviewed By: epriestley

CC: Korvin, epriestley, aran

Differential Revision: https://secure.phabricator.com/D7549
2013-11-11 09:23:23 -08:00
epriestley
7dde01df76 Fix issues with first-time account registration
Summary: This worked originally, but the migration broke slightly after the
config was deprecated, and there was another minor issue during setup.
2013-10-05 08:02:41 -07:00
Chad Little
cad9e548bc Add Header to Registration
Summary: Adds an ObjectBox to Phabricator Registration

Test Plan: check logged out page for new header.

Reviewers: epriestley, btrahan

Reviewed By: epriestley

CC: Korvin, aran

Differential Revision: https://secure.phabricator.com/D7223
2013-10-04 15:13:05 -07:00