2011-08-30 21:03:58 +02:00
|
|
|
<?php
|
|
|
|
|
|
|
|
abstract class ConduitAPI_user_Method extends ConduitAPIMethod {
|
|
|
|
|
2013-03-13 15:09:05 +01:00
|
|
|
public function getApplication() {
|
|
|
|
return PhabricatorApplication::getByClass(
|
2014-07-23 02:03:09 +02:00
|
|
|
'PhabricatorPeopleApplication');
|
2013-03-13 15:09:05 +01:00
|
|
|
}
|
|
|
|
|
2012-05-19 18:38:34 +02:00
|
|
|
protected function buildUserInformationDictionary(
|
|
|
|
PhabricatorUser $user,
|
2014-02-06 19:07:29 +01:00
|
|
|
PhabricatorCalendarEvent $current_status = null) {
|
2012-05-19 18:38:34 +02:00
|
|
|
|
2012-05-24 21:10:47 +02:00
|
|
|
$roles = array();
|
|
|
|
if ($user->getIsDisabled()) {
|
|
|
|
$roles[] = 'disabled';
|
|
|
|
}
|
|
|
|
if ($user->getIsSystemAgent()) {
|
|
|
|
$roles[] = 'agent';
|
|
|
|
}
|
|
|
|
if ($user->getIsAdmin()) {
|
|
|
|
$roles[] = 'admin';
|
|
|
|
}
|
|
|
|
|
2012-06-16 02:00:26 +02:00
|
|
|
$primary = $user->loadPrimaryEmail();
|
|
|
|
if ($primary && $primary->getIsVerified()) {
|
|
|
|
$roles[] = 'verified';
|
|
|
|
} else {
|
|
|
|
$roles[] = 'unverified';
|
|
|
|
}
|
|
|
|
|
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 23:37:04 +01:00
|
|
|
if ($user->getIsApproved()) {
|
|
|
|
$roles[] = 'approved';
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($user->isUserActivated()) {
|
|
|
|
$roles[] = 'activated';
|
|
|
|
}
|
|
|
|
|
2012-05-19 18:38:34 +02:00
|
|
|
$return = array(
|
2011-08-30 21:03:58 +02:00
|
|
|
'phid' => $user->getPHID(),
|
|
|
|
'userName' => $user->getUserName(),
|
|
|
|
'realName' => $user->getRealName(),
|
2012-04-28 02:44:10 +02:00
|
|
|
'image' => $user->loadProfileImageURI(),
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-04 01:21:40 +01:00
|
|
|
'uri' => PhabricatorEnv::getURI('/p/'.$user->getUsername().'/'),
|
2012-05-24 21:10:47 +02:00
|
|
|
'roles' => $roles,
|
2011-08-30 21:03:58 +02:00
|
|
|
);
|
2012-05-19 18:38:34 +02:00
|
|
|
|
|
|
|
if ($current_status) {
|
|
|
|
$return['currentStatus'] = $current_status->getTextStatus();
|
|
|
|
$return['currentStatusUntil'] = $current_status->getDateTo();
|
|
|
|
}
|
|
|
|
|
|
|
|
return $return;
|
2011-08-30 21:03:58 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
}
|