Summary:
Ref T10917. This cheats fairly heavily to generate SSH key mail:
- Generate normal transaction mail.
- Force it to go to the user.
- Use `setForceDelivery()` to force it to actually be delivered.
- Add some warning language to the mail body.
This doesn't move us much closer to Glorious Infrastructure for this whole class of events, but should do what it needs to for now and doesn't really require anything sketchy.
Test Plan: Created and edited SSH keys, got security notice mail.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10917
Differential Revision: https://secure.phabricator.com/D15948
Summary:
Ref T10917. Converts web UI edits to transactions.
This is about 95% "the right way", and then I cheated on the last 5% instead of building a real EditEngine. We don't need it for anything else right now and some of the dialog workflows here are a little weird so I'm just planning to skip it for the moment unless it ends up being easier to do after the next phase (mail notifications) or something like that.
Test Plan: {F1652160}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10917
Differential Revision: https://secure.phabricator.com/D15947
Summary:
Ref T10917. This primarily prepares these for transactions by giving us a place to:
- review old deactivated keys; and
- review changes to keys.
Future changes will add transactions and a timeline so key changes are recorded exhaustively and can be more easily audited.
Test Plan:
{F1652089}
{F1652090}
{F1652091}
{F1652092}
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10917
Differential Revision: https://secure.phabricator.com/D15946
Summary:
Ref T10917. Currently, when you delete an SSH key, we really truly delete it forever.
This isn't very consistent with other applications, but we built this stuff a long time ago before we were as rigorous about retaining data and making it auditable.
In partiular, destroying data isn't good for auditing after security issues, since it means we can't show you logs of any changes an attacker might have made to your keys.
To prepare to improve this, stop destoying data. This will allow later changes to become transaction-oriented and show normal transaction logs.
The tricky part here is that we have a `UNIQUE KEY` on the public key part of the key.
Instead, I changed this to `UNIQUE (key, isActive)`, where `isActive` is a nullable boolean column. This works because MySQL does not enforce "unique" if part of the key is `NULL`.
So you can't have two rows with `("A", 1)`, but you can have as many rows as you want with `("A", null)`. This lets us keep the "each key may only be active for one user/object" rule without requiring us to delete any data.
Test Plan:
- Ran schema changes.
- Viewed public keys.
- Tried to add a duplicate key, got rejected (already associated with another object).
- Deleted SSH key.
- Verified that the key was no longer actually deleted from the database, just marked inactive (in future changes, I'll update the UI to be more clear about this).
- Uploaded a new copy of the same public key, worked fine (no duplicate key rejection).
- Tried to upload yet another copy, got rejected.
- Generated a new keypair.
- Tried to upload a duplicate to an Almanac device, got rejected.
- Generated a new pair for a device.
- Trusted a device key.
- Untrusted a device key.
- "Deleted" a device key.
- Tried to trust a deleted device key, got "inactive" message.
- Ran `bin/ssh-auth`, got good output with unique keys.
- Ran `cat ~/.ssh/id_rsa.pub | ./bin/ssh-auth-key`, got good output with one key.
- Used `auth.querypublickeys` Conduit method to query keys, got good active keys.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10917
Differential Revision: https://secure.phabricator.com/D15943
Summary: This error message is pointless and dead-ends logged-in users needlessly if they're sent to the register page by documentation or Advanced Enterprise Sales Funnels.
Test Plan: Visited `/auth/register/` while logged in, was sent home.
Reviewers: chad
Reviewed By: chad
Differential Revision: https://secure.phabricator.com/D15739
Summary: Ref T7673. This is really just so I can force admin.phacility.com logout when you log out of an instance, but there are a few other things we could move here eventually, like the WILLREGISTERUSER event.
Test Plan: Logged out of an instance, got logged out of parent (see next change).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T7673
Differential Revision: https://secure.phabricator.com/D15629
Summary:
Ref T7303. Ref T7673. This implements an "auth.logout" which:
- terminates all web sessions;
- terminates the current OAuth token if called via OAuth; and
- may always be called via OAuth.
(Since it consumes an OAuth token, even a "malicious" OAuth application can't really be that much of a jerk with this: it can't continuously log you out, since calling the method once kills the token. The application would need to ask your permission again to get a fresh token.)
The primary goal here is to let Phacility instances call this against the Phacility upstream, so that when you log out of an instance it also logs you out of your Phacility account (possibly with a checkbox or something).
This also smooths over the session token code. Before this change, your sessions would get logged out but when you reloaded we'd tell you your session was invalid.
Instead, try to clear the invalid session before telling the user there's an issue. I think that ssentially 100% of invalid sessions are a result of something in this vein (e.g., forced logout via Settings) nowadays, since the session code is generally stable and sane and has been for a long time.
Test Plan:
- Called `auth.logout` via console, got a reasonable logout experience.
- Called `auth.logout` via OAuth.
- Tried to make another call, verified OAuth token had been invalidated.
- Verified web session had been invalidated.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T7303, T7673
Differential Revision: https://secure.phabricator.com/D15594
Summary: [WIP] Tossing this up for safety and to read through it. Need to test, update some of the other flows. This updates everything in Auth for new UI and modern conventions.
Test Plan: Loooots of random testing, new providers, edit providers, logging out, forgot password... more coming.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D15550
Summary:
Ref T10603. This makes minor updates to temporary tokens:
- Rename `objectPHID` (which is sometimes used to store some other kind of identifier instead of a PHID) to `tokenResource` (i.e., which resource does this token permit access to?).
- Add a `userPHID` column. For LFS tokens and some other types of tokens, I want to bind the token to both a resource (like a repository) and a user.
- Add a `properties` column. This makes tokens more flexible and supports custom behavior (like scoping LFS tokens even more tightly).
Test Plan:
- Ran `bin/storage upgrade -f`, got a clean upgrade.
- Viewed one-time tokens.
- Revoked one token.
- Revoked all tokens.
- Performed a one-time login.
- Performed a password reset.
- Added an MFA token.
- Removed an MFA token.
- Used a file token to view a file.
- Verified file token was removed after viewing file.
- Linked my account to an OAuth1 account (Twitter).
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10603
Differential Revision: https://secure.phabricator.com/D15478
Summary:
Ref T10603. This converts existing hard-codes to modular constants.
Also removes one small piece of code duplication.
Test Plan:
- Performed one-time logins.
- Performed a password reset.
- Verified temporary tokens were revoked properly.
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T10603
Differential Revision: https://secure.phabricator.com/D15476
Summary: Mostly for consistency, we're not using other forms of icons and this makes all classes that use an icon call it in the same way.
Test Plan: tested uiexamples, lots of other random pages.
Reviewers: epriestley
Reviewed By: epriestley
Subscribers: Korvin
Differential Revision: https://secure.phabricator.com/D15125
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
