2011-01-23 18:09:16 -08:00
|
|
|
<?php
|
|
|
|
|
2014-06-03 16:50:27 -07:00
|
|
|
/**
|
2015-05-14 11:15:04 -07:00
|
|
|
* @task availability Availability
|
2015-05-13 09:46:25 -07:00
|
|
|
* @task image-cache Profile Image Cache
|
2015-03-30 06:35:32 -07:00
|
|
|
* @task factors Multi-Factor Authentication
|
|
|
|
* @task handles Managing Handles
|
2014-06-03 16:50:27 -07:00
|
|
|
*/
|
2013-05-31 10:51:20 -07:00
|
|
|
final class PhabricatorUser
|
|
|
|
extends PhabricatorUserDAO
|
2013-06-07 09:55:55 -07:00
|
|
|
implements
|
|
|
|
PhutilPerson,
|
|
|
|
PhabricatorPolicyInterface,
|
2014-05-01 18:23:31 -07:00
|
|
|
PhabricatorCustomFieldInterface,
|
2014-11-11 08:18:26 -08:00
|
|
|
PhabricatorDestructibleInterface,
|
2015-06-08 13:35:57 -07:00
|
|
|
PhabricatorSSHPublicKeyInterface,
|
2015-07-20 13:43:58 -07:00
|
|
|
PhabricatorFlaggableInterface,
|
2015-12-21 09:02:55 -08:00
|
|
|
PhabricatorApplicationTransactionInterface,
|
|
|
|
PhabricatorFulltextInterface {
|
2011-01-23 18:09:16 -08:00
|
|
|
|
2011-02-05 22:36:21 -08:00
|
|
|
const SESSION_TABLE = 'phabricator_session';
|
2011-10-23 13:25:52 -07:00
|
|
|
const NAMETOKEN_TABLE = 'user_nametoken';
|
2013-08-13 14:37:23 -07:00
|
|
|
const MAXIMUM_USERNAME_LENGTH = 64;
|
2011-02-05 22:36:21 -08:00
|
|
|
|
2011-01-23 18:09:16 -08:00
|
|
|
protected $userName;
|
|
|
|
protected $realName;
|
2012-04-19 15:36:09 -07:00
|
|
|
protected $sex;
|
2012-06-14 18:08:06 -07:00
|
|
|
protected $translation;
|
2011-01-26 13:21:12 -08:00
|
|
|
protected $passwordSalt;
|
|
|
|
protected $passwordHash;
|
2011-01-30 21:28:45 -08:00
|
|
|
protected $profileImagePHID;
|
2015-05-13 09:46:25 -07:00
|
|
|
protected $profileImageCache;
|
2015-05-14 11:15:22 -07:00
|
|
|
protected $availabilityCache;
|
|
|
|
protected $availabilityCacheTTL;
|
2011-06-20 13:00:31 -07:00
|
|
|
protected $timezoneIdentifier = '';
|
2011-01-23 18:09:16 -08:00
|
|
|
|
2011-02-02 22:38:42 -08:00
|
|
|
protected $consoleEnabled = 0;
|
|
|
|
protected $consoleVisible = 0;
|
|
|
|
protected $consoleTab = '';
|
2011-02-02 13:59:52 -08:00
|
|
|
|
2011-02-05 22:36:21 -08:00
|
|
|
protected $conduitCertificate;
|
|
|
|
|
2011-04-12 19:00:54 -07:00
|
|
|
protected $isSystemAgent = 0;
|
2015-06-02 08:52:00 -07:00
|
|
|
protected $isMailingList = 0;
|
2011-05-12 10:06:54 -07:00
|
|
|
protected $isAdmin = 0;
|
|
|
|
protected $isDisabled = 0;
|
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
|
|
|
protected $isEmailVerified = 0;
|
2013-11-13 11:24:56 -08:00
|
|
|
protected $isApproved = 0;
|
2014-06-03 16:50:27 -07:00
|
|
|
protected $isEnrolledInMultiFactor = 0;
|
2011-04-12 18:19:09 -07:00
|
|
|
|
2014-04-10 11:45:10 -07:00
|
|
|
protected $accountSecret;
|
|
|
|
|
2014-03-19 19:28:04 -07:00
|
|
|
private $profileImage = self::ATTACHABLE;
|
2013-03-24 06:42:31 -07:00
|
|
|
private $profile = null;
|
2015-05-14 11:15:04 -07:00
|
|
|
private $availability = self::ATTACHABLE;
|
2011-03-31 18:46:53 -07:00
|
|
|
private $preferences = null;
|
2013-02-28 11:01:40 -08:00
|
|
|
private $omnipotent = false;
|
2013-08-14 09:53:59 -07:00
|
|
|
private $customFields = self::ATTACHABLE;
|
2015-07-23 11:46:34 -07:00
|
|
|
private $badgePHIDs = self::ATTACHABLE;
|
2011-03-30 19:21:09 -07:00
|
|
|
|
2014-01-23 14:03:54 -08:00
|
|
|
private $alternateCSRFString = self::ATTACHABLE;
|
2014-04-27 17:31:11 -07:00
|
|
|
private $session = self::ATTACHABLE;
|
2014-01-23 14:03:54 -08:00
|
|
|
|
Improve Phortune policy behavior
Summary:
Currently, PhortuneAccounts have a very open default policy to allow merchants to see and interact with them.
This has the undesirable side effect of leaking their names in too many places, because all users are allowed to load the handles for the accounts. Although this information is not super sensitive, we shouldn't expose it.
I went through about 5 really messy diffs trying to fix this. It's very complicated because there are a lot of objects and many of them are related to PhortuneAccounts, but PhortuneAccounts are not bound to a specific merchant. This lead to a lot of threading viewers and merchants all over the place through the call stack and some really sketchy diffs with OmnipotentUsers that weren't going anywhere good.
This is the cleanest approach I came up with, by far:
- Introduce the concept of an "Authority", which gives a user more powers as a viewer. For now, since we only have one use case, this is pretty open-ended.
- When a viewer is acting as a merchant, grant them authority through the merchant.
- Have Accounts check if the viewer is acting with merchant authority. This lets us easily implement the rule "merchants can see this stuff" without being too broad.
Then update the Subscription view to respect Merchant Authority.
I partially updated the Cart views to respect it. I'll finish this up in a separate diff, but this seemed like a good checkpoint that introduced the concept without too much extra baggage.
This feels pretty good/clean to me, overall, even ignoring the series of horrible messes I made on my way here.
Test Plan:
- Verified I can see everything I need to as a merchant (modulo un-updated Cart UIs).
- Verified I can see nothing when acting as a normal user.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D11945
2015-03-03 10:38:25 -08:00
|
|
|
private $authorities = array();
|
2015-03-29 18:22:27 -07:00
|
|
|
private $handlePool;
|
Make CSRF salt per-user instead of per-request
Summary:
Fixes T8326. This removes calls to PhabricatorStartup from places that daemons may access.
This salt doesn't need to be global; it's embedded in the token we return. It's fine if we use a different salt every time. In practice, we always use the same viewer, so this change causes little or no behavioral change.
Ref T8424. For Spaces, I need a per-request cache for all spaces, because they have unusual access patterns and require repeated access, in some cases by multiple viewers.
We don't currently have a per-request in-process cache that we, e.g., clear in the daemons.
We do have a weak/theoretical/forward-looking attempt at this in `PhabricatorStartup::getGlobal()` but I'm going to throw that away (it's kind of junky, partly because of T8326) and replace it with a more formal mechanism.
Test Plan:
- Submitted some forms.
- Grepped for `csrf.salt`.
- Viewed page source, saw nice CSRF tokens with salt.
- All the salts are still the same on every page I checked, but it doesn't matter if this isn't true everywhere.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T8326, T8424
Differential Revision: https://secure.phabricator.com/D13151
2015-06-04 17:26:23 -07:00
|
|
|
private $csrfSalt;
|
Improve Phortune policy behavior
Summary:
Currently, PhortuneAccounts have a very open default policy to allow merchants to see and interact with them.
This has the undesirable side effect of leaking their names in too many places, because all users are allowed to load the handles for the accounts. Although this information is not super sensitive, we shouldn't expose it.
I went through about 5 really messy diffs trying to fix this. It's very complicated because there are a lot of objects and many of them are related to PhortuneAccounts, but PhortuneAccounts are not bound to a specific merchant. This lead to a lot of threading viewers and merchants all over the place through the call stack and some really sketchy diffs with OmnipotentUsers that weren't going anywhere good.
This is the cleanest approach I came up with, by far:
- Introduce the concept of an "Authority", which gives a user more powers as a viewer. For now, since we only have one use case, this is pretty open-ended.
- When a viewer is acting as a merchant, grant them authority through the merchant.
- Have Accounts check if the viewer is acting with merchant authority. This lets us easily implement the rule "merchants can see this stuff" without being too broad.
Then update the Subscription view to respect Merchant Authority.
I partially updated the Cart views to respect it. I'll finish this up in a separate diff, but this seemed like a good checkpoint that introduced the concept without too much extra baggage.
This feels pretty good/clean to me, overall, even ignoring the series of horrible messes I made on my way here.
Test Plan:
- Verified I can see everything I need to as a merchant (modulo un-updated Cart UIs).
- Verified I can see nothing when acting as a normal user.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D11945
2015-03-03 10:38:25 -08:00
|
|
|
|
2011-10-07 15:03:00 -07:00
|
|
|
protected function readField($field) {
|
2011-11-16 09:49:18 -08:00
|
|
|
switch ($field) {
|
|
|
|
case 'timezoneIdentifier':
|
|
|
|
// If the user hasn't set one, guess the server's time.
|
|
|
|
return nonempty(
|
|
|
|
$this->timezoneIdentifier,
|
|
|
|
date_default_timezone_get());
|
|
|
|
// Make sure these return booleans.
|
|
|
|
case 'isAdmin':
|
|
|
|
return (bool)$this->isAdmin;
|
|
|
|
case 'isDisabled':
|
|
|
|
return (bool)$this->isDisabled;
|
|
|
|
case 'isSystemAgent':
|
|
|
|
return (bool)$this->isSystemAgent;
|
2015-06-02 08:52:00 -07:00
|
|
|
case 'isMailingList':
|
|
|
|
return (bool)$this->isMailingList;
|
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
|
|
|
case 'isEmailVerified':
|
|
|
|
return (bool)$this->isEmailVerified;
|
|
|
|
case 'isApproved':
|
|
|
|
return (bool)$this->isApproved;
|
2011-11-16 09:49:18 -08:00
|
|
|
default:
|
|
|
|
return parent::readField($field);
|
2011-10-07 15:03:00 -07:00
|
|
|
}
|
2011-01-31 16:00:42 -08:00
|
|
|
}
|
2011-01-30 18:52:29 -08:00
|
|
|
|
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
|
|
|
|
|
|
|
/**
|
|
|
|
* Is this a live account which has passed required approvals? Returns true
|
|
|
|
* if this is an enabled, verified (if required), approved (if required)
|
|
|
|
* account, and false otherwise.
|
|
|
|
*
|
|
|
|
* @return bool True if this is a standard, usable account.
|
|
|
|
*/
|
|
|
|
public function isUserActivated() {
|
Add `cluster.addresses` and require membership before accepting cluster authentication tokens
Summary:
Ref T2783. Ref T6706.
- Add `cluster.addresses`. This is a whitelist of CIDR blocks which define cluster hosts.
- When we recieve a request that has a cluster-based authentication token, require the cluster to be configured and require the remote address to be a cluster member before we accept it.
- This provides a general layer of security for these mechanisms.
- In particular, it means they do not work by default on unconfigured hosts.
- When cluster addresses are configured, and we receive a request //to// an address not on the list, reject it.
- This provides a general layer of security for getting the Ops side of cluster configuration correct.
- If cluster nodes have public IPs and are listening on them, we'll reject requests.
- Basically, this means that any requests which bypass the LB get rejected.
Test Plan:
- With addresses not configured, tried to make requests; rejected for using a cluster auth mechanism.
- With addresses configred wrong, tried to make requests; rejected for sending from (or to) an address outside of the cluster.
- With addresses configured correctly, made valid requests.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T6706, T2783
Differential Revision: https://secure.phabricator.com/D11159
2015-01-02 15:13:41 -08:00
|
|
|
if ($this->isOmnipotent()) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
if ($this->getIsDisabled()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!$this->getIsApproved()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (PhabricatorUserEmail::isEmailVerificationRequired()) {
|
|
|
|
if (!$this->getIsEmailVerified()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-06-02 08:52:00 -07:00
|
|
|
public function canEstablishWebSessions() {
|
|
|
|
if ($this->getIsMailingList()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($this->getIsSystemAgent()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function canEstablishAPISessions() {
|
2016-04-13 04:24:58 -07:00
|
|
|
if ($this->getIsDisabled()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Intracluster requests are permitted even if the user is logged out:
|
|
|
|
// in particular, public users are allowed to issue intracluster requests
|
|
|
|
// when browsing Diffusion.
|
|
|
|
if (PhabricatorEnv::isClusterRemoteAddress()) {
|
|
|
|
if (!$this->isLoggedIn()) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-06-02 08:52:00 -07:00
|
|
|
if (!$this->isUserActivated()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($this->getIsMailingList()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function canEstablishSSHSessions() {
|
|
|
|
if (!$this->isUserActivated()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($this->getIsMailingList()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
When we fail to process mail, tell the user about it
Summary:
Ref T4371. Ref T4699. Fixes T3994.
Currently, we're very conservative about sending errors back to users. A concern I had about this was that mistakes could lead to email loops, massive amounts of email spam, etc. Because of this, I was pretty hesitant about replying to email with more email when I wrote this stuff.
However, this was a long time ago. We now have Message-ID deduplication, "X-Phabricator-Sent-This-Mail", generally better mail infrastructure, and rate limiting. Together, these mechanisms should reasonably prevent anything crazy (primarily, infinite email loops) from happening.
Thus:
- When we hit any processing error after receiving a mail, try to send the author a reply with details about what went wrong. These are limited to 6 per hour per address.
- Rewrite most of the errors to be more detailed and informative.
- Rewrite most of the errors in a user-facing voice ("You sent this mail..." instead of "This mail was sent..").
- Remove the redundant, less sophisticated code which does something similar in Differential.
Test Plan:
- Using `scripts/mail/mail_receiver.php`, artificially received a pile of mail.
- Hit a bunch of different errors.
- Saw reasonable error mail get sent to me.
- Saw other reasonable error mail get rate limited.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3994, T4371, T4699
Differential Revision: https://secure.phabricator.com/D8692
2014-04-03 18:43:18 -07:00
|
|
|
/**
|
|
|
|
* Returns `true` if this is a standard user who is logged in. Returns `false`
|
|
|
|
* for logged out, anonymous, or external users.
|
|
|
|
*
|
|
|
|
* @return bool `true` if the user is a standard user who is logged in with
|
|
|
|
* a normal session.
|
|
|
|
*/
|
|
|
|
public function getIsStandardUser() {
|
2014-07-24 08:05:46 +10:00
|
|
|
$type_user = PhabricatorPeopleUserPHIDType::TYPECONST;
|
When we fail to process mail, tell the user about it
Summary:
Ref T4371. Ref T4699. Fixes T3994.
Currently, we're very conservative about sending errors back to users. A concern I had about this was that mistakes could lead to email loops, massive amounts of email spam, etc. Because of this, I was pretty hesitant about replying to email with more email when I wrote this stuff.
However, this was a long time ago. We now have Message-ID deduplication, "X-Phabricator-Sent-This-Mail", generally better mail infrastructure, and rate limiting. Together, these mechanisms should reasonably prevent anything crazy (primarily, infinite email loops) from happening.
Thus:
- When we hit any processing error after receiving a mail, try to send the author a reply with details about what went wrong. These are limited to 6 per hour per address.
- Rewrite most of the errors to be more detailed and informative.
- Rewrite most of the errors in a user-facing voice ("You sent this mail..." instead of "This mail was sent..").
- Remove the redundant, less sophisticated code which does something similar in Differential.
Test Plan:
- Using `scripts/mail/mail_receiver.php`, artificially received a pile of mail.
- Hit a bunch of different errors.
- Saw reasonable error mail get sent to me.
- Saw other reasonable error mail get rate limited.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3994, T4371, T4699
Differential Revision: https://secure.phabricator.com/D8692
2014-04-03 18:43:18 -07:00
|
|
|
return $this->getPHID() && (phid_get_type($this->getPHID()) == $type_user);
|
|
|
|
}
|
|
|
|
|
2015-01-14 06:47:05 +11:00
|
|
|
protected function getConfiguration() {
|
2011-01-23 18:09:16 -08:00
|
|
|
return array(
|
|
|
|
self::CONFIG_AUX_PHID => true,
|
Generate expected schemata for User/People tables
Summary:
Ref T1191. Some notes here:
- Drops the old LDAP and OAuth info tables. These were migrated to the ExternalAccount table a very long time ago.
- Separates surplus/missing keys from other types of surplus/missing things. In the long run, my plan is to have only two notice levels:
- Error: something we can't fix (missing database, table, or column; overlong key).
- Warning: something we can fix (surplus anything, missing key, bad column type, bad key columns, bad uniqueness, bad collation or charset).
- For now, retaining three levels is helpful in generating all the expected scheamta.
Test Plan:
- Saw ~200 issues resolve, leaving ~1,300.
- Grepped for removed tables.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1191
Differential Revision: https://secure.phabricator.com/D10580
2014-10-01 07:36:47 -07:00
|
|
|
self::CONFIG_COLUMN_SCHEMA => array(
|
2014-11-05 12:32:32 -08:00
|
|
|
'userName' => 'sort64',
|
Generate expected schemata for User/People tables
Summary:
Ref T1191. Some notes here:
- Drops the old LDAP and OAuth info tables. These were migrated to the ExternalAccount table a very long time ago.
- Separates surplus/missing keys from other types of surplus/missing things. In the long run, my plan is to have only two notice levels:
- Error: something we can't fix (missing database, table, or column; overlong key).
- Warning: something we can fix (surplus anything, missing key, bad column type, bad key columns, bad uniqueness, bad collation or charset).
- For now, retaining three levels is helpful in generating all the expected scheamta.
Test Plan:
- Saw ~200 issues resolve, leaving ~1,300.
- Grepped for removed tables.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1191
Differential Revision: https://secure.phabricator.com/D10580
2014-10-01 07:36:47 -07:00
|
|
|
'realName' => 'text128',
|
|
|
|
'sex' => 'text4?',
|
|
|
|
'translation' => 'text64?',
|
|
|
|
'passwordSalt' => 'text32?',
|
|
|
|
'passwordHash' => 'text128?',
|
|
|
|
'profileImagePHID' => 'phid?',
|
|
|
|
'consoleEnabled' => 'bool',
|
|
|
|
'consoleVisible' => 'bool',
|
|
|
|
'consoleTab' => 'text64',
|
|
|
|
'conduitCertificate' => 'text255',
|
|
|
|
'isSystemAgent' => 'bool',
|
2015-06-02 08:52:00 -07:00
|
|
|
'isMailingList' => 'bool',
|
Generate expected schemata for User/People tables
Summary:
Ref T1191. Some notes here:
- Drops the old LDAP and OAuth info tables. These were migrated to the ExternalAccount table a very long time ago.
- Separates surplus/missing keys from other types of surplus/missing things. In the long run, my plan is to have only two notice levels:
- Error: something we can't fix (missing database, table, or column; overlong key).
- Warning: something we can fix (surplus anything, missing key, bad column type, bad key columns, bad uniqueness, bad collation or charset).
- For now, retaining three levels is helpful in generating all the expected scheamta.
Test Plan:
- Saw ~200 issues resolve, leaving ~1,300.
- Grepped for removed tables.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1191
Differential Revision: https://secure.phabricator.com/D10580
2014-10-01 07:36:47 -07:00
|
|
|
'isDisabled' => 'bool',
|
|
|
|
'isAdmin' => 'bool',
|
|
|
|
'timezoneIdentifier' => 'text255',
|
|
|
|
'isEmailVerified' => 'uint32',
|
|
|
|
'isApproved' => 'uint32',
|
|
|
|
'accountSecret' => 'bytes64',
|
|
|
|
'isEnrolledInMultiFactor' => 'bool',
|
2015-05-13 09:46:25 -07:00
|
|
|
'profileImageCache' => 'text255?',
|
2015-05-14 11:15:22 -07:00
|
|
|
'availabilityCache' => 'text255?',
|
|
|
|
'availabilityCacheTTL' => 'uint32?',
|
Generate expected schemata for User/People tables
Summary:
Ref T1191. Some notes here:
- Drops the old LDAP and OAuth info tables. These were migrated to the ExternalAccount table a very long time ago.
- Separates surplus/missing keys from other types of surplus/missing things. In the long run, my plan is to have only two notice levels:
- Error: something we can't fix (missing database, table, or column; overlong key).
- Warning: something we can fix (surplus anything, missing key, bad column type, bad key columns, bad uniqueness, bad collation or charset).
- For now, retaining three levels is helpful in generating all the expected scheamta.
Test Plan:
- Saw ~200 issues resolve, leaving ~1,300.
- Grepped for removed tables.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1191
Differential Revision: https://secure.phabricator.com/D10580
2014-10-01 07:36:47 -07:00
|
|
|
),
|
|
|
|
self::CONFIG_KEY_SCHEMA => array(
|
|
|
|
'key_phid' => null,
|
|
|
|
'phid' => array(
|
|
|
|
'columns' => array('phid'),
|
|
|
|
'unique' => true,
|
|
|
|
),
|
|
|
|
'userName' => array(
|
|
|
|
'columns' => array('userName'),
|
|
|
|
'unique' => true,
|
|
|
|
),
|
|
|
|
'realName' => array(
|
|
|
|
'columns' => array('realName'),
|
|
|
|
),
|
|
|
|
'key_approved' => array(
|
|
|
|
'columns' => array('isApproved'),
|
|
|
|
),
|
|
|
|
),
|
2015-05-13 09:46:25 -07:00
|
|
|
self::CONFIG_NO_MUTATE => array(
|
|
|
|
'profileImageCache' => true,
|
2015-05-14 11:15:22 -07:00
|
|
|
'availabilityCache' => true,
|
|
|
|
'availabilityCacheTTL' => true,
|
2015-05-13 09:46:25 -07:00
|
|
|
),
|
2011-01-23 18:09:16 -08:00
|
|
|
) + parent::getConfiguration();
|
|
|
|
}
|
|
|
|
|
|
|
|
public function generatePHID() {
|
2011-03-02 18:58:21 -08:00
|
|
|
return PhabricatorPHID::generateNewPHID(
|
2014-07-24 08:05:46 +10:00
|
|
|
PhabricatorPeopleUserPHIDType::TYPECONST);
|
2011-01-23 18:09:16 -08:00
|
|
|
}
|
|
|
|
|
2012-07-17 12:06:33 -07:00
|
|
|
public function setPassword(PhutilOpaqueEnvelope $envelope) {
|
Mask typed passwords as they are entered into 'accountadmin'
Summary:
Currently, we echo the password as the user types it. This turns out to be a bit
of an issue in over-the-shoulder installs. Instead, disable tty echo while the
user is typing their password so nothing is shown (like how 'sudo' works).
Also show a better error message if the user chooses a duplicate email; without
testing for this we just throw a duplicate key exception when saving, which
isn't easy to understand. The other duplicate key exception is duplicate
username, which is impossible (the script updates rather than creating in this
case).
There's currently a bug where creating a user and setting their password at the
same time doesn't work. This is because we hash the PHID into the password hash,
but it's empty if the user hasn't been persisted yet. Make sure the user is
persisted before setting their password.
Finally, fix an issue where $original would have the new username set, creating
a somewhat confusing summary at the end.
I'm also going to improve the password behavior/explanation here once I add
welcome emails ("Hi Joe, epriestley created an account for you on Phabricator,
click here to login...").
Test Plan:
- Typed a password and didn't have it echoed. I also tested this on Ubuntu
without encountering problems.
- Chose a duplicate email, got a useful error message instead of the exception
I'd encountered earlier.
- Created a new user with a password in one pass and logged in as that user,
this worked properly.
- Verified summary table does not contain username for new users.
Reviewed By: jungejason
Reviewers: jungejason, tuomaspelkonen, aran
CC: moskov, jr, aran, jungejason
Differential Revision: 358
2011-05-28 07:17:42 -07:00
|
|
|
if (!$this->getPHID()) {
|
|
|
|
throw new Exception(
|
2015-05-22 17:27:56 +10:00
|
|
|
pht(
|
|
|
|
'You can not set a password for an unsaved user because their PHID '.
|
|
|
|
'is a salt component in the password hash.'));
|
Mask typed passwords as they are entered into 'accountadmin'
Summary:
Currently, we echo the password as the user types it. This turns out to be a bit
of an issue in over-the-shoulder installs. Instead, disable tty echo while the
user is typing their password so nothing is shown (like how 'sudo' works).
Also show a better error message if the user chooses a duplicate email; without
testing for this we just throw a duplicate key exception when saving, which
isn't easy to understand. The other duplicate key exception is duplicate
username, which is impossible (the script updates rather than creating in this
case).
There's currently a bug where creating a user and setting their password at the
same time doesn't work. This is because we hash the PHID into the password hash,
but it's empty if the user hasn't been persisted yet. Make sure the user is
persisted before setting their password.
Finally, fix an issue where $original would have the new username set, creating
a somewhat confusing summary at the end.
I'm also going to improve the password behavior/explanation here once I add
welcome emails ("Hi Joe, epriestley created an account for you on Phabricator,
click here to login...").
Test Plan:
- Typed a password and didn't have it echoed. I also tested this on Ubuntu
without encountering problems.
- Chose a duplicate email, got a useful error message instead of the exception
I'd encountered earlier.
- Created a new user with a password in one pass and logged in as that user,
this worked properly.
- Verified summary table does not contain username for new users.
Reviewed By: jungejason
Reviewers: jungejason, tuomaspelkonen, aran
CC: moskov, jr, aran, jungejason
Differential Revision: 358
2011-05-28 07:17:42 -07:00
|
|
|
}
|
|
|
|
|
2012-07-17 12:06:33 -07:00
|
|
|
if (!strlen($envelope->openEnvelope())) {
|
2011-05-12 10:06:54 -07:00
|
|
|
$this->setPasswordHash('');
|
|
|
|
} else {
|
2014-02-18 09:31:30 -08:00
|
|
|
$this->setPasswordSalt(md5(Filesystem::readRandomBytes(32)));
|
2012-07-17 12:06:33 -07:00
|
|
|
$hash = $this->hashPassword($envelope);
|
2014-02-18 09:31:30 -08:00
|
|
|
$this->setPasswordHash($hash->openEnvelope());
|
2011-05-12 10:06:54 -07:00
|
|
|
}
|
2011-01-26 13:21:12 -08:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-06-14 18:08:06 -07:00
|
|
|
// To satisfy PhutilPerson.
|
|
|
|
public function getSex() {
|
|
|
|
return $this->sex;
|
|
|
|
}
|
|
|
|
|
2014-05-01 18:23:31 -07:00
|
|
|
public function getMonogram() {
|
|
|
|
return '@'.$this->getUsername();
|
|
|
|
}
|
|
|
|
|
2011-10-24 12:27:16 -07:00
|
|
|
public function isLoggedIn() {
|
|
|
|
return !($this->getPHID() === null);
|
|
|
|
}
|
|
|
|
|
2011-02-05 22:36:21 -08:00
|
|
|
public function save() {
|
2011-10-07 15:03:00 -07:00
|
|
|
if (!$this->getConduitCertificate()) {
|
|
|
|
$this->setConduitCertificate($this->generateConduitCertificate());
|
2011-02-05 22:36:21 -08:00
|
|
|
}
|
2014-04-10 11:45:10 -07:00
|
|
|
|
|
|
|
if (!strlen($this->getAccountSecret())) {
|
|
|
|
$this->setAccountSecret(Filesystem::readRandomCharacters(64));
|
|
|
|
}
|
|
|
|
|
2011-06-23 13:31:20 -07:00
|
|
|
$result = parent::save();
|
|
|
|
|
2013-06-07 10:22:45 -07:00
|
|
|
if ($this->profile) {
|
|
|
|
$this->profile->save();
|
|
|
|
}
|
|
|
|
|
2011-10-23 13:25:52 -07:00
|
|
|
$this->updateNameTokens();
|
Improve Search architecture
Summary:
The search indexing API has several problems right now:
- Always runs in-process.
- It would be nice to push this into the task queue for performance. However, the API currently passses an object all the way through (and some indexers depend on preloaded object attributes), so it can't be dumped into the task queue at any stage since we can't serialize it.
- Being able to use the task queue will also make rebuilding indexes faster.
- Instead, make the API phid-oriented.
- No uniform indexing API.
- Each "Editor" currently calls SomeCustomIndexer::indexThing(). This won't work with AbstractTransactions. The API is also just weird.
- Instead, provide a uniform API.
- No uniform CLI.
- We have `scripts/search/reindex_everything.php`, but it doesn't actually index everything. Each new document type needs to be separately added to it, leading to stuff like D3839. Third-party applications can't provide indexers.
- Instead, let indexers expose documents for indexing.
- Not application-oriented.
- All the indexers live in search/ right now, which isn't the right organization in an application-orietned view of the world.
- Instead, move indexers to applications and load them with SymbolLoader.
Test Plan:
- `bin/search index`
- Indexed one revision, one task.
- Indexed `--type TASK`, `--type DREV`, etc., for all types.
- Indexed `--all`.
- Added the word "saboteur" to a revision, task, wiki page, and question and then searched for it.
- Creating users is a pain; searched for a user after indexing.
- Creating commits is a pain; searched for a commit after indexing.
- Mocks aren't currently loadable in the result view, so their indexing is moot.
Reviewers: btrahan, vrana
Reviewed By: btrahan
CC: 20after4, aran
Maniphest Tasks: T1991, T2104
Differential Revision: https://secure.phabricator.com/D4261
2012-12-21 14:21:31 -08:00
|
|
|
|
2015-12-20 08:54:29 -08:00
|
|
|
PhabricatorSearchWorker::queueDocumentForIndexing($this->getPHID());
|
2011-06-23 13:31:20 -07:00
|
|
|
|
|
|
|
return $result;
|
2011-02-05 22:36:21 -08:00
|
|
|
}
|
|
|
|
|
2014-04-27 17:31:11 -07:00
|
|
|
public function attachSession(PhabricatorAuthSession $session) {
|
|
|
|
$this->session = $session;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getSession() {
|
|
|
|
return $this->assertAttached($this->session);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function hasSession() {
|
|
|
|
return ($this->session !== self::ATTACHABLE);
|
|
|
|
}
|
|
|
|
|
2011-02-05 22:36:21 -08:00
|
|
|
private function generateConduitCertificate() {
|
Replace callsites to sha1() that use it to asciify entropy with
Filesystem::readRandomCharacters()
Summary: See T547. To improve auditability of use of crypto-sensitive hash
functions, use Filesystem::readRandomCharacters() in place of
sha1(Filesystem::readRandomBytes()) when we're just generating random ASCII
strings.
Test Plan:
- Generated a new PHID.
- Logged out and logged back in (to test sessions).
- Regenerated Conduit certificate.
- Created a new task, verified mail key generated sensibly.
- Created a new revision, verified mail key generated sensibly.
- Ran "arc list", got blocked, installed new certificate, ran "arc list"
again.
Reviewers: jungejason, nh, tuomaspelkonen, aran, benmathews
Reviewed By: jungejason
CC: aran, epriestley, jungejason
Differential Revision: 1000
2011-10-10 19:22:30 -07:00
|
|
|
return Filesystem::readRandomCharacters(255);
|
2011-02-05 22:36:21 -08:00
|
|
|
}
|
|
|
|
|
2012-07-17 12:06:33 -07:00
|
|
|
public function comparePassword(PhutilOpaqueEnvelope $envelope) {
|
|
|
|
if (!strlen($envelope->openEnvelope())) {
|
2011-05-12 10:06:54 -07:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
if (!strlen($this->getPasswordHash())) {
|
|
|
|
return false;
|
|
|
|
}
|
2014-02-18 09:31:30 -08:00
|
|
|
|
|
|
|
return PhabricatorPasswordHasher::comparePassword(
|
|
|
|
$this->getPasswordHashInput($envelope),
|
2014-02-18 10:12:47 -08:00
|
|
|
new PhutilOpaqueEnvelope($this->getPasswordHash()));
|
2011-01-26 13:21:12 -08:00
|
|
|
}
|
|
|
|
|
2014-02-18 09:31:30 -08:00
|
|
|
private function getPasswordHashInput(PhutilOpaqueEnvelope $password) {
|
|
|
|
$input =
|
|
|
|
$this->getUsername().
|
|
|
|
$password->openEnvelope().
|
|
|
|
$this->getPHID().
|
|
|
|
$this->getPasswordSalt();
|
|
|
|
|
|
|
|
return new PhutilOpaqueEnvelope($input);
|
|
|
|
}
|
|
|
|
|
|
|
|
private function hashPassword(PhutilOpaqueEnvelope $password) {
|
|
|
|
$hasher = PhabricatorPasswordHasher::getBestHasher();
|
|
|
|
|
|
|
|
$input_envelope = $this->getPasswordHashInput($password);
|
2014-02-18 10:12:47 -08:00
|
|
|
return $hasher->getPasswordHashForStorage($input_envelope);
|
2011-01-26 13:21:12 -08:00
|
|
|
}
|
|
|
|
|
2011-01-31 11:55:26 -08:00
|
|
|
const CSRF_CYCLE_FREQUENCY = 3600;
|
2013-08-07 16:09:05 -07:00
|
|
|
const CSRF_SALT_LENGTH = 8;
|
2011-01-31 11:55:26 -08:00
|
|
|
const CSRF_TOKEN_LENGTH = 16;
|
2013-08-07 16:09:05 -07:00
|
|
|
const CSRF_BREACH_PREFIX = 'B@';
|
2011-01-31 11:55:26 -08:00
|
|
|
|
|
|
|
const EMAIL_CYCLE_FREQUENCY = 86400;
|
|
|
|
const EMAIL_TOKEN_LENGTH = 24;
|
|
|
|
|
2013-08-07 16:09:05 -07:00
|
|
|
private function getRawCSRFToken($offset = 0) {
|
2011-01-31 11:55:26 -08:00
|
|
|
return $this->generateToken(
|
|
|
|
time() + (self::CSRF_CYCLE_FREQUENCY * $offset),
|
|
|
|
self::CSRF_CYCLE_FREQUENCY,
|
|
|
|
PhabricatorEnv::getEnvConfig('phabricator.csrf-key'),
|
|
|
|
self::CSRF_TOKEN_LENGTH);
|
2011-01-30 18:52:29 -08:00
|
|
|
}
|
|
|
|
|
2013-08-07 16:09:05 -07:00
|
|
|
public function getCSRFToken() {
|
Don't try to generate a CSRF token for the omnipotent user
Summary:
We can end up here with a stack trace like this, while rendering an embedded Slowvote trying to publish a Feed story:
```
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] [2015-06-08 22:49:57] EXCEPTION: (PhutilProxyException) Error while executing Task ID 830591. {>} (PhabricatorDataNotAttachedException) Attempting to access attached data on PhabricatorUser (via getAlternateCSRFString()), but the data is not actually attached. Before accessing attachable data on an object, you must load and attach it.
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] Data is normally attached by calling the corresponding needX() method on the Query class when the object is loaded. You can also call the corresponding attachX() method explicitly. at [<phabricator>/src/infrastructure/storage/lisk/PhabricatorLiskDAO.php:166]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] arcanist(head=master, ref.master=7d15b85a1bc0), phabricator(head=master, ref.master=929f5f22acef), phutil(head=master, ref.master=92882eb9404d)
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #0 <#2> PhabricatorLiskDAO::assertAttached(string) called at [<phabricator>/src/applications/people/storage/PhabricatorUser.php:556]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #1 <#2> PhabricatorUser::getAlternateCSRFString() called at [<phabricator>/src/applications/people/storage/PhabricatorUser.php:432]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #2 <#2> PhabricatorUser::generateToken(integer, integer, string, integer) called at [<phabricator>/src/applications/people/storage/PhabricatorUser.php:344]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #3 <#2> PhabricatorUser::getRawCSRFToken() called at [<phabricator>/src/applications/people/storage/PhabricatorUser.php:357]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #4 <#2> PhabricatorUser::getCSRFToken() called at [<phabricator>/src/infrastructure/javelin/markup.php:91]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #5 <#2> phabricator_form(PhabricatorUser, array, array) called at [<phabricator>/src/applications/slowvote/view/SlowvoteEmbedView.php:169]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #6 <#2> SlowvoteEmbedView::render() called at [<phabricator>/src/view/AphrontView.php:175]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #7 <#2> AphrontView::producePhutilSafeHTML() called at [<phutil>/src/markup/render.php:133]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #8 <#2> phutil_escape_html(SlowvoteEmbedView)
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #9 <#2> array_map(string, array) called at [<phutil>/src/markup/engine/remarkup/PhutilRemarkupBlockStorage.php:56]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #10 <#2> PhutilRemarkupBlockStorage::restore(PhutilSafeHTML, integer) called at [<phutil>/src/markup/engine/PhutilRemarkupEngine.php:299]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #11 <#2> PhutilRemarkupEngine::restoreText(PhutilSafeHTML, integer) called at [<phutil>/src/markup/engine/PhutilRemarkupEngine.php:295]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #12 <#2> PhutilRemarkupEngine::postprocessText(array) called at [<phabricator>/src/infrastructure/markup/PhabricatorMarkupEngine.php:138]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #13 <#2> PhabricatorMarkupEngine::process() called at [<phabricator>/src/applications/feed/story/PhabricatorFeedStory.php:167]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #14 <#2> PhabricatorFeedStory::loadAllFromRows(array, PhabricatorUser) called at [<phabricator>/src/applications/feed/query/PhabricatorFeedQuery.php:37]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #15 <#2> PhabricatorFeedQuery::willFilterPage(array) called at [<phabricator>/src/infrastructure/query/policy/PhabricatorPolicyAwareQuery.php:237]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #16 <#2> PhabricatorPolicyAwareQuery::execute() called at [<phabricator>/src/infrastructure/query/policy/PhabricatorPolicyAwareQuery.php:168]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #17 <#2> PhabricatorPolicyAwareQuery::executeOne() called at [<phabricator>/src/applications/feed/worker/FeedPushWorker.php:12]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #18 <#2> FeedPushWorker::loadFeedStory() called at [<phabricator>/src/applications/feed/worker/FeedPublisherWorker.php:6]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #19 <#2> FeedPublisherWorker::doWork() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorWorker.php:91]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #20 <#2> PhabricatorWorker::executeTask() called at [<phabricator>/src/infrastructure/daemon/workers/storage/PhabricatorWorkerActiveTask.php:162]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #21 <#2> PhabricatorWorkerActiveTask::executeTask() called at [<phabricator>/src/infrastructure/daemon/workers/PhabricatorTaskmasterDaemon.php:22]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #22 PhabricatorTaskmasterDaemon::run() called at [<phutil>/src/daemon/PhutilDaemon.php:185]
Daemon 43450 STDE [Mon, 08 Jun 2015 22:49:57 +0000] #23 PhutilDaemon::execute() called at [<phutil>/scripts/daemon/exec/exec_daemon.php:125]
```
Just return `null`.
Test Plan: Will check that tasks clear in production.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D13218
2015-06-08 16:07:21 -07:00
|
|
|
if ($this->isOmnipotent()) {
|
|
|
|
// We may end up here when called from the daemons. The omnipotent user
|
|
|
|
// has no meaningful CSRF token, so just return `null`.
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
Make CSRF salt per-user instead of per-request
Summary:
Fixes T8326. This removes calls to PhabricatorStartup from places that daemons may access.
This salt doesn't need to be global; it's embedded in the token we return. It's fine if we use a different salt every time. In practice, we always use the same viewer, so this change causes little or no behavioral change.
Ref T8424. For Spaces, I need a per-request cache for all spaces, because they have unusual access patterns and require repeated access, in some cases by multiple viewers.
We don't currently have a per-request in-process cache that we, e.g., clear in the daemons.
We do have a weak/theoretical/forward-looking attempt at this in `PhabricatorStartup::getGlobal()` but I'm going to throw that away (it's kind of junky, partly because of T8326) and replace it with a more formal mechanism.
Test Plan:
- Submitted some forms.
- Grepped for `csrf.salt`.
- Viewed page source, saw nice CSRF tokens with salt.
- All the salts are still the same on every page I checked, but it doesn't matter if this isn't true everywhere.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T8326, T8424
Differential Revision: https://secure.phabricator.com/D13151
2015-06-04 17:26:23 -07:00
|
|
|
if ($this->csrfSalt === null) {
|
|
|
|
$this->csrfSalt = Filesystem::readRandomCharacters(
|
|
|
|
self::CSRF_SALT_LENGTH);
|
2013-08-07 16:09:05 -07:00
|
|
|
}
|
Fix conservative CSRF token cycling limit
Summary:
We currently cycle CSRF tokens every hour and check for the last two valid ones.
This means that a form could go stale in as little as an hour, and is certainly
stale after two.
When a stale form is submitted, you basically get a terrible heisen-state where
some of your data might persist if you're lucky but more likely it all just
vanishes. The .js file below outlines some more details.
This is a pretty terrible UX and we don't need to be as conservative about CSRF
validation as we're being. Remedy this problem by:
- Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are
valid for at least 6 hours, and for as long as 7).
- Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected
to the internet are valid indefinitely).
- Showing the user an explicit message about what went wrong when CSRF
validation fails so the experience is less bewildering.
They should now only be able to submit with a bad CSRF token if:
- They load a page, disconnect from the internet for 7 hours, reconnect, and
submit the form within 55 minutes; or
- They are actually the victim of a CSRF attack.
We could eventually fix the first one by tracking reconnects, which might be
"free" once the notification server gets built. It will probably never be an
issue in practice.
Test Plan:
- Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15
seconds, got the CSRF exception.
- Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15
seconds, got a clean form post.
- Added debugging code the the csrf refresh to make sure it was doing sensible
things (pulling different tokens, finding all the inputs).
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: aran, epriestley
Differential Revision: 660
2011-07-13 14:05:18 -07:00
|
|
|
|
Make CSRF salt per-user instead of per-request
Summary:
Fixes T8326. This removes calls to PhabricatorStartup from places that daemons may access.
This salt doesn't need to be global; it's embedded in the token we return. It's fine if we use a different salt every time. In practice, we always use the same viewer, so this change causes little or no behavioral change.
Ref T8424. For Spaces, I need a per-request cache for all spaces, because they have unusual access patterns and require repeated access, in some cases by multiple viewers.
We don't currently have a per-request in-process cache that we, e.g., clear in the daemons.
We do have a weak/theoretical/forward-looking attempt at this in `PhabricatorStartup::getGlobal()` but I'm going to throw that away (it's kind of junky, partly because of T8326) and replace it with a more formal mechanism.
Test Plan:
- Submitted some forms.
- Grepped for `csrf.salt`.
- Viewed page source, saw nice CSRF tokens with salt.
- All the salts are still the same on every page I checked, but it doesn't matter if this isn't true everywhere.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T8326, T8424
Differential Revision: https://secure.phabricator.com/D13151
2015-06-04 17:26:23 -07:00
|
|
|
$salt = $this->csrfSalt;
|
|
|
|
|
2013-08-07 16:09:05 -07:00
|
|
|
// Generate a token hash to mitigate BREACH attacks against SSL. See
|
|
|
|
// discussion in T3684.
|
|
|
|
$token = $this->getRawCSRFToken();
|
|
|
|
$hash = PhabricatorHash::digest($token, $salt);
|
2015-06-05 07:27:31 -07:00
|
|
|
return self::CSRF_BREACH_PREFIX.$salt.substr(
|
|
|
|
$hash, 0, self::CSRF_TOKEN_LENGTH);
|
2013-08-07 16:09:05 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
public function validateCSRFToken($token) {
|
2015-09-01 15:52:44 -07:00
|
|
|
// We expect a BREACH-mitigating token. See T3684.
|
2013-08-07 16:09:05 -07:00
|
|
|
$breach_prefix = self::CSRF_BREACH_PREFIX;
|
|
|
|
$breach_prelen = strlen($breach_prefix);
|
2015-09-01 15:52:44 -07:00
|
|
|
if (strncmp($token, $breach_prefix, $breach_prelen) !== 0) {
|
|
|
|
return false;
|
2013-08-07 16:09:05 -07:00
|
|
|
}
|
|
|
|
|
2015-09-01 15:52:44 -07:00
|
|
|
$salt = substr($token, $breach_prelen, self::CSRF_SALT_LENGTH);
|
|
|
|
$token = substr($token, $breach_prelen + self::CSRF_SALT_LENGTH);
|
|
|
|
|
Fix conservative CSRF token cycling limit
Summary:
We currently cycle CSRF tokens every hour and check for the last two valid ones.
This means that a form could go stale in as little as an hour, and is certainly
stale after two.
When a stale form is submitted, you basically get a terrible heisen-state where
some of your data might persist if you're lucky but more likely it all just
vanishes. The .js file below outlines some more details.
This is a pretty terrible UX and we don't need to be as conservative about CSRF
validation as we're being. Remedy this problem by:
- Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are
valid for at least 6 hours, and for as long as 7).
- Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected
to the internet are valid indefinitely).
- Showing the user an explicit message about what went wrong when CSRF
validation fails so the experience is less bewildering.
They should now only be able to submit with a bad CSRF token if:
- They load a page, disconnect from the internet for 7 hours, reconnect, and
submit the form within 55 minutes; or
- They are actually the victim of a CSRF attack.
We could eventually fix the first one by tracking reconnects, which might be
"free" once the notification server gets built. It will probably never be an
issue in practice.
Test Plan:
- Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15
seconds, got the CSRF exception.
- Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15
seconds, got a clean form post.
- Added debugging code the the csrf refresh to make sure it was doing sensible
things (pulling different tokens, finding all the inputs).
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: aran, epriestley
Differential Revision: 660
2011-07-13 14:05:18 -07:00
|
|
|
// When the user posts a form, we check that it contains a valid CSRF token.
|
|
|
|
// Tokens cycle each hour (every CSRF_CYLCE_FREQUENCY seconds) and we accept
|
|
|
|
// either the current token, the next token (users can submit a "future"
|
|
|
|
// token if you have two web frontends that have some clock skew) or any of
|
|
|
|
// the last 6 tokens. This means that pages are valid for up to 7 hours.
|
|
|
|
// There is also some Javascript which periodically refreshes the CSRF
|
|
|
|
// tokens on each page, so theoretically pages should be valid indefinitely.
|
|
|
|
// However, this code may fail to run (if the user loses their internet
|
|
|
|
// connection, or there's a JS problem, or they don't have JS enabled).
|
|
|
|
// Choosing the size of the window in which we accept old CSRF tokens is
|
|
|
|
// an issue of balancing concerns between security and usability. We could
|
|
|
|
// choose a very narrow (e.g., 1-hour) window to reduce vulnerability to
|
|
|
|
// attacks using captured CSRF tokens, but it's also more likely that real
|
|
|
|
// users will be affected by this, e.g. if they close their laptop for an
|
|
|
|
// hour, open it back up, and try to submit a form before the CSRF refresh
|
|
|
|
// can kick in. Since the user experience of submitting a form with expired
|
|
|
|
// CSRF is often quite bad (you basically lose data, or it's a big pain to
|
|
|
|
// recover at least) and I believe we gain little additional protection
|
|
|
|
// by keeping the window very short (the overwhelming value here is in
|
|
|
|
// preventing blind attacks, and most attacks which can capture CSRF tokens
|
|
|
|
// can also just capture authentication information [sniffing networks]
|
|
|
|
// or act as the user [xss]) the 7 hour default seems like a reasonable
|
|
|
|
// balance. Other major platforms have much longer CSRF token lifetimes,
|
|
|
|
// like Rails (session duration) and Django (forever), which suggests this
|
|
|
|
// is a reasonable analysis.
|
|
|
|
$csrf_window = 6;
|
|
|
|
|
|
|
|
for ($ii = -$csrf_window; $ii <= 1; $ii++) {
|
2013-08-07 16:09:05 -07:00
|
|
|
$valid = $this->getRawCSRFToken($ii);
|
2015-09-01 15:52:44 -07:00
|
|
|
|
|
|
|
$digest = PhabricatorHash::digest($valid, $salt);
|
|
|
|
$digest = substr($digest, 0, self::CSRF_TOKEN_LENGTH);
|
|
|
|
if (phutil_hashes_are_identical($digest, $token)) {
|
|
|
|
return true;
|
2011-01-30 18:52:29 -08:00
|
|
|
}
|
|
|
|
}
|
Validate logins, and simplify email password resets
Summary:
- There are some recent reports of login issues, see T755 and T754. I'm not
really sure what's going on, but this is an attempt at getting some more
information.
- When we login a user by setting 'phusr' and 'phsid', send them to
/login/validate/ to validate that the cookies actually got set.
- Do email password resets in two steps: first, log the user in. Redirect them
through validate, then give them the option to reset their password.
- Don't CSRF logged-out users. It technically sort of works most of the time
right now, but is silly. If we need logged-out CSRF we should generate it in
some more reliable way.
Test Plan:
- Logged in with username/password.
- Logged in with OAuth.
- Logged in with email password reset.
- Sent bad values to /login/validate/, got appropriate errors.
- Reset password.
- Verified next_uri still works.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, btrahan, j3kuntz
Maniphest Tasks: T754, T755
Differential Revision: https://secure.phabricator.com/D1353
2012-01-10 14:42:07 -08:00
|
|
|
|
2011-01-30 18:52:29 -08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2011-01-31 11:55:26 -08:00
|
|
|
private function generateToken($epoch, $frequency, $key, $len) {
|
2014-01-23 14:03:54 -08:00
|
|
|
if ($this->getPHID()) {
|
2014-04-10 11:45:10 -07:00
|
|
|
$vec = $this->getPHID().$this->getAccountSecret();
|
2014-01-23 14:03:54 -08:00
|
|
|
} else {
|
|
|
|
$vec = $this->getAlternateCSRFString();
|
|
|
|
}
|
|
|
|
|
2014-08-04 12:04:47 -07:00
|
|
|
if ($this->hasSession()) {
|
|
|
|
$vec = $vec.$this->getSession()->getSessionKey();
|
|
|
|
}
|
|
|
|
|
2011-01-31 11:55:26 -08:00
|
|
|
$time_block = floor($epoch / $frequency);
|
2014-01-23 14:03:54 -08:00
|
|
|
$vec = $vec.$key.$time_block;
|
|
|
|
|
2011-12-18 11:00:39 -08:00
|
|
|
return substr(PhabricatorHash::digest($vec), 0, $len);
|
2011-01-30 18:52:29 -08:00
|
|
|
}
|
|
|
|
|
2015-05-18 15:39:34 -07:00
|
|
|
public function getUserProfile() {
|
|
|
|
return $this->assertAttached($this->profile);
|
|
|
|
}
|
|
|
|
|
2013-03-24 06:42:31 -07:00
|
|
|
public function attachUserProfile(PhabricatorUserProfile $profile) {
|
|
|
|
$this->profile = $profile;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function loadUserProfile() {
|
|
|
|
if ($this->profile) {
|
|
|
|
return $this->profile;
|
|
|
|
}
|
|
|
|
|
|
|
|
$profile_dao = new PhabricatorUserProfile();
|
|
|
|
$this->profile = $profile_dao->loadOneWhere('userPHID = %s',
|
|
|
|
$this->getPHID());
|
|
|
|
|
|
|
|
if (!$this->profile) {
|
2016-01-24 05:43:57 -08:00
|
|
|
$this->profile = PhabricatorUserProfile::initializeNewProfile($this);
|
2013-03-24 06:42:31 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
return $this->profile;
|
|
|
|
}
|
|
|
|
|
2012-05-07 10:29:33 -07:00
|
|
|
public function loadPrimaryEmailAddress() {
|
|
|
|
$email = $this->loadPrimaryEmail();
|
|
|
|
if (!$email) {
|
2015-05-22 17:27:56 +10:00
|
|
|
throw new Exception(pht('User has no primary email address!'));
|
2012-05-07 10:29:33 -07:00
|
|
|
}
|
|
|
|
return $email->getAddress();
|
|
|
|
}
|
|
|
|
|
|
|
|
public function loadPrimaryEmail() {
|
2012-05-25 13:11:33 -07:00
|
|
|
return $this->loadOneRelative(
|
|
|
|
new PhabricatorUserEmail(),
|
|
|
|
'userPHID',
|
|
|
|
'getPHID',
|
|
|
|
'(isPrimary = 1)');
|
Allow installs to require email verification
Summary:
Allow installs to require users to verify email addresses before they can use Phabricator. If a user logs in without a verified email address, they're given instructions to verify their address.
This isn't too useful on its own since we don't actually have arbitrary email registration, but the next step is to allow installs to restrict email to only some domains (e.g., @mycompany.com).
Test Plan:
- Verification
- Set verification requirement to `true`.
- Tried to use Phabricator with an unverified account, was told to verify.
- Tried to use Conduit, was given a verification error.
- Verified account, used Phabricator.
- Unverified account, reset password, verified implicit verification, used Phabricator.
- People Admin Interface
- Viewed as admin. Clicked "Administrate User".
- Viewed as non-admin
- Sanity Checks
- Used Conduit normally from web/CLI with a verified account.
- Logged in/out.
- Sent password reset email.
- Created a new user.
- Logged in with an unverified user but with the configuration set to off.
Reviewers: btrahan, vrana, jungejason
Reviewed By: btrahan
CC: aran, csilvers
Maniphest Tasks: T1184
Differential Revision: https://secure.phabricator.com/D2520
2012-05-21 12:47:38 -07:00
|
|
|
}
|
|
|
|
|
2011-03-30 19:21:09 -07:00
|
|
|
public function loadPreferences() {
|
|
|
|
if ($this->preferences) {
|
|
|
|
return $this->preferences;
|
|
|
|
}
|
|
|
|
|
2013-09-02 12:40:04 -07:00
|
|
|
$preferences = null;
|
|
|
|
if ($this->getPHID()) {
|
|
|
|
$preferences = id(new PhabricatorUserPreferences())->loadOneWhere(
|
|
|
|
'userPHID = %s',
|
|
|
|
$this->getPHID());
|
|
|
|
}
|
2011-03-30 19:21:09 -07:00
|
|
|
|
|
|
|
if (!$preferences) {
|
|
|
|
$preferences = new PhabricatorUserPreferences();
|
|
|
|
$preferences->setUserPHID($this->getPHID());
|
|
|
|
|
|
|
|
$default_dict = array(
|
|
|
|
PhabricatorUserPreferences::PREFERENCE_TITLES => 'glyph',
|
2012-01-16 11:08:54 -08:00
|
|
|
PhabricatorUserPreferences::PREFERENCE_EDITOR => '',
|
2013-01-19 17:40:48 -08:00
|
|
|
PhabricatorUserPreferences::PREFERENCE_MONOSPACED => '',
|
2014-10-08 00:01:04 +11:00
|
|
|
PhabricatorUserPreferences::PREFERENCE_DARK_CONSOLE => 0,
|
|
|
|
);
|
2011-03-30 19:21:09 -07:00
|
|
|
|
|
|
|
$preferences->setPreferences($default_dict);
|
|
|
|
}
|
|
|
|
|
|
|
|
$this->preferences = $preferences;
|
|
|
|
return $preferences;
|
|
|
|
}
|
|
|
|
|
2016-01-02 11:56:19 -08:00
|
|
|
public function loadEditorLink(
|
|
|
|
$path,
|
|
|
|
$line,
|
|
|
|
PhabricatorRepository $repository = null) {
|
|
|
|
|
2012-01-16 11:08:54 -08:00
|
|
|
$editor = $this->loadPreferences()->getPreference(
|
|
|
|
PhabricatorUserPreferences::PREFERENCE_EDITOR);
|
2012-12-03 15:51:18 -08:00
|
|
|
|
|
|
|
if (is_array($path)) {
|
|
|
|
$multiedit = $this->loadPreferences()->getPreference(
|
|
|
|
PhabricatorUserPreferences::PREFERENCE_MULTIEDIT);
|
|
|
|
switch ($multiedit) {
|
|
|
|
case '':
|
|
|
|
$path = implode(' ', $path);
|
|
|
|
break;
|
|
|
|
case 'disable':
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-03-17 13:00:37 -07:00
|
|
|
if (!strlen($editor)) {
|
|
|
|
return null;
|
2012-01-16 11:08:54 -08:00
|
|
|
}
|
2014-03-17 13:00:37 -07:00
|
|
|
|
2016-01-02 11:56:19 -08:00
|
|
|
if ($repository) {
|
|
|
|
$callsign = $repository->getCallsign();
|
|
|
|
} else {
|
|
|
|
$callsign = null;
|
|
|
|
}
|
|
|
|
|
2014-03-17 13:00:37 -07:00
|
|
|
$uri = strtr($editor, array(
|
|
|
|
'%%' => '%',
|
|
|
|
'%f' => phutil_escape_uri($path),
|
|
|
|
'%l' => phutil_escape_uri($line),
|
|
|
|
'%r' => phutil_escape_uri($callsign),
|
|
|
|
));
|
|
|
|
|
|
|
|
// The resulting URI must have an allowed protocol. Otherwise, we'll return
|
|
|
|
// a link to an error page explaining the misconfiguration.
|
|
|
|
|
|
|
|
$ok = PhabricatorHelpEditorProtocolController::hasAllowedProtocol($uri);
|
|
|
|
if (!$ok) {
|
|
|
|
return '/help/editorprotocol/';
|
|
|
|
}
|
|
|
|
|
|
|
|
return (string)$uri;
|
2012-01-16 11:08:54 -08:00
|
|
|
}
|
|
|
|
|
2014-01-23 14:03:54 -08:00
|
|
|
public function getAlternateCSRFString() {
|
|
|
|
return $this->assertAttached($this->alternateCSRFString);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function attachAlternateCSRFString($string) {
|
|
|
|
$this->alternateCSRFString = $string;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2011-10-23 13:25:52 -07:00
|
|
|
/**
|
|
|
|
* Populate the nametoken table, which used to fetch typeahead results. When
|
|
|
|
* a user types "linc", we want to match "Abraham Lincoln" from on-demand
|
|
|
|
* typeahead sources. To do this, we need a separate table of name fragments.
|
|
|
|
*/
|
|
|
|
public function updateNameTokens() {
|
|
|
|
$table = self::NAMETOKEN_TABLE;
|
|
|
|
$conn_w = $this->establishConnection('w');
|
|
|
|
|
2014-07-17 16:35:54 -07:00
|
|
|
$tokens = PhabricatorTypeaheadDatasource::tokenizeString(
|
|
|
|
$this->getUserName().' '.$this->getRealName());
|
|
|
|
|
2011-10-23 13:25:52 -07:00
|
|
|
$sql = array();
|
|
|
|
foreach ($tokens as $token) {
|
|
|
|
$sql[] = qsprintf(
|
|
|
|
$conn_w,
|
|
|
|
'(%d, %s)',
|
|
|
|
$this->getID(),
|
|
|
|
$token);
|
|
|
|
}
|
|
|
|
|
|
|
|
queryfx(
|
|
|
|
$conn_w,
|
|
|
|
'DELETE FROM %T WHERE userID = %d',
|
|
|
|
$table,
|
|
|
|
$this->getID());
|
|
|
|
if ($sql) {
|
|
|
|
queryfx(
|
|
|
|
$conn_w,
|
|
|
|
'INSERT INTO %T (userID, token) VALUES %Q',
|
|
|
|
$table,
|
|
|
|
implode(', ', $sql));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-06 10:44:12 -08:00
|
|
|
public function sendWelcomeEmail(PhabricatorUser $admin) {
|
2015-09-20 04:28:33 -07:00
|
|
|
if (!$this->canEstablishWebSessions()) {
|
|
|
|
throw new Exception(
|
|
|
|
pht(
|
|
|
|
'Can not send welcome mail to users who can not establish '.
|
|
|
|
'web sessions!'));
|
|
|
|
}
|
|
|
|
|
2012-01-06 10:44:12 -08:00
|
|
|
$admin_username = $admin->getUserName();
|
|
|
|
$admin_realname = $admin->getRealName();
|
|
|
|
$user_username = $this->getUserName();
|
|
|
|
$is_serious = PhabricatorEnv::getEnvConfig('phabricator.serious-business');
|
|
|
|
|
|
|
|
$base_uri = PhabricatorEnv::getProductionURI('/');
|
|
|
|
|
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
|
|
|
$engine = new PhabricatorAuthSessionEngine();
|
|
|
|
$uri = $engine->getOneTimeLoginURI(
|
|
|
|
$this,
|
|
|
|
$this->loadPrimaryEmail(),
|
|
|
|
PhabricatorAuthSessionEngine::ONETIME_WELCOME);
|
|
|
|
|
2015-05-22 17:27:56 +10:00
|
|
|
$body = pht(
|
|
|
|
"Welcome to Phabricator!\n\n".
|
|
|
|
"%s (%s) has created an account for you.\n\n".
|
|
|
|
" Username: %s\n\n".
|
|
|
|
"To login to Phabricator, follow this link and set a password:\n\n".
|
|
|
|
" %s\n\n".
|
|
|
|
"After you have set a password, you can login in the future by ".
|
|
|
|
"going here:\n\n".
|
|
|
|
" %s\n",
|
|
|
|
$admin_username,
|
|
|
|
$admin_realname,
|
|
|
|
$user_username,
|
|
|
|
$uri,
|
|
|
|
$base_uri);
|
2012-01-06 10:44:12 -08:00
|
|
|
|
|
|
|
if (!$is_serious) {
|
2015-05-22 17:27:56 +10:00
|
|
|
$body .= sprintf(
|
|
|
|
"\n%s\n",
|
|
|
|
pht("Love,\nPhabricator"));
|
2012-01-06 10:44:12 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
$mail = id(new PhabricatorMetaMTAMail())
|
|
|
|
->addTos(array($this->getPHID()))
|
2014-08-12 12:28:29 -07:00
|
|
|
->setForceDelivery(true)
|
2015-05-22 17:27:56 +10:00
|
|
|
->setSubject(pht('[Phabricator] Welcome to Phabricator'))
|
2012-01-06 10:44:12 -08:00
|
|
|
->setBody($body)
|
|
|
|
->saveAndSend();
|
|
|
|
}
|
|
|
|
|
2012-06-06 07:09:56 -07:00
|
|
|
public function sendUsernameChangeEmail(
|
|
|
|
PhabricatorUser $admin,
|
|
|
|
$old_username) {
|
|
|
|
|
|
|
|
$admin_username = $admin->getUserName();
|
|
|
|
$admin_realname = $admin->getRealName();
|
|
|
|
$new_username = $this->getUserName();
|
|
|
|
|
|
|
|
$password_instructions = null;
|
2014-07-22 21:18:15 +10:00
|
|
|
if (PhabricatorPasswordAuthProvider::getPasswordProvider()) {
|
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
|
|
|
$engine = new PhabricatorAuthSessionEngine();
|
|
|
|
$uri = $engine->getOneTimeLoginURI(
|
|
|
|
$this,
|
|
|
|
null,
|
|
|
|
PhabricatorAuthSessionEngine::ONETIME_USERNAME);
|
2015-05-22 17:27:56 +10:00
|
|
|
$password_instructions = sprintf(
|
|
|
|
"%s\n\n %s\n\n%s\n",
|
|
|
|
pht(
|
|
|
|
"If you use a password to login, you'll need to reset it ".
|
|
|
|
"before you can login again. You can reset your password by ".
|
|
|
|
"following this link:"),
|
|
|
|
$uri,
|
|
|
|
pht(
|
|
|
|
"And, of course, you'll need to use your new username to login ".
|
|
|
|
"from now on. If you use OAuth to login, nothing should change."));
|
2012-06-06 07:09:56 -07:00
|
|
|
}
|
|
|
|
|
2015-05-22 17:27:56 +10:00
|
|
|
$body = sprintf(
|
|
|
|
"%s\n\n %s\n %s\n\n%s",
|
|
|
|
pht(
|
|
|
|
'%s (%s) has changed your Phabricator username.',
|
|
|
|
$admin_username,
|
|
|
|
$admin_realname),
|
|
|
|
pht(
|
|
|
|
'Old Username: %s',
|
|
|
|
$old_username),
|
|
|
|
pht(
|
|
|
|
'New Username: %s',
|
|
|
|
$new_username),
|
|
|
|
$password_instructions);
|
2012-06-06 07:09:56 -07:00
|
|
|
|
|
|
|
$mail = id(new PhabricatorMetaMTAMail())
|
|
|
|
->addTos(array($this->getPHID()))
|
2014-08-12 12:28:29 -07:00
|
|
|
->setForceDelivery(true)
|
2015-05-22 17:27:56 +10:00
|
|
|
->setSubject(pht('[Phabricator] Username Changed'))
|
2012-06-06 07:09:56 -07:00
|
|
|
->setBody($body)
|
|
|
|
->saveAndSend();
|
|
|
|
}
|
|
|
|
|
2012-06-06 07:09:05 -07:00
|
|
|
public static function describeValidUsername() {
|
2013-08-13 14:37:23 -07:00
|
|
|
return pht(
|
|
|
|
'Usernames must contain only numbers, letters, period, underscore and '.
|
|
|
|
'hyphen, and can not end with a period. They must have no more than %d '.
|
|
|
|
'characters.',
|
|
|
|
new PhutilNumber(self::MAXIMUM_USERNAME_LENGTH));
|
2012-06-06 07:09:05 -07:00
|
|
|
}
|
|
|
|
|
2012-01-16 07:30:28 -08:00
|
|
|
public static function validateUsername($username) {
|
2012-06-13 08:39:02 -07:00
|
|
|
// NOTE: If you update this, make sure to update:
|
|
|
|
//
|
|
|
|
// - Remarkup rule for @mentions.
|
|
|
|
// - Routing rule for "/p/username/".
|
|
|
|
// - Unit tests, obviously.
|
|
|
|
// - describeValidUsername() method, above.
|
|
|
|
|
2013-08-13 14:37:23 -07:00
|
|
|
if (strlen($username) > self::MAXIMUM_USERNAME_LENGTH) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-03-13 12:42:41 -07:00
|
|
|
return (bool)preg_match('/^[a-zA-Z0-9._-]*[a-zA-Z0-9_-]\z/', $username);
|
2012-01-16 07:30:28 -08:00
|
|
|
}
|
|
|
|
|
2012-04-27 17:44:10 -07:00
|
|
|
public static function getDefaultProfileImageURI() {
|
|
|
|
return celerity_get_resource_uri('/rsrc/image/avatar.png');
|
|
|
|
}
|
|
|
|
|
2013-03-24 06:42:31 -07:00
|
|
|
public function attachProfileImageURI($uri) {
|
|
|
|
$this->profileImage = $uri;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2014-03-19 19:28:04 -07:00
|
|
|
public function getProfileImageURI() {
|
|
|
|
return $this->assertAttached($this->profileImage);
|
|
|
|
}
|
|
|
|
|
2012-05-17 21:46:45 -07:00
|
|
|
public function getFullName() {
|
2014-05-12 09:51:40 -07:00
|
|
|
if (strlen($this->getRealName())) {
|
|
|
|
return $this->getUsername().' ('.$this->getRealName().')';
|
|
|
|
} else {
|
|
|
|
return $this->getUsername();
|
|
|
|
}
|
2012-05-17 21:46:45 -07:00
|
|
|
}
|
|
|
|
|
2015-05-07 18:57:28 -07:00
|
|
|
public function getTimeZone() {
|
|
|
|
return new DateTimeZone($this->getTimezoneIdentifier());
|
|
|
|
}
|
|
|
|
|
2016-03-18 08:59:21 -07:00
|
|
|
public function formatShortDateTime($when, $now = null) {
|
|
|
|
if ($now === null) {
|
|
|
|
$now = PhabricatorTime::getNow();
|
|
|
|
}
|
|
|
|
|
|
|
|
try {
|
|
|
|
$when = new DateTime('@'.$when);
|
|
|
|
$now = new DateTime('@'.$now);
|
|
|
|
} catch (Exception $ex) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
$zone = $this->getTimeZone();
|
|
|
|
|
|
|
|
$when->setTimeZone($zone);
|
|
|
|
$now->setTimeZone($zone);
|
|
|
|
|
|
|
|
if ($when->format('Y') !== $now->format('Y')) {
|
|
|
|
// Different year, so show "Feb 31 2075".
|
|
|
|
$format = 'M j Y';
|
|
|
|
} else if ($when->format('Ymd') !== $now->format('Ymd')) {
|
|
|
|
// Same year but different month and day, so show "Feb 31".
|
|
|
|
$format = 'M j';
|
|
|
|
} else {
|
|
|
|
// Same year, month and day so show a time of day.
|
|
|
|
$pref_time = PhabricatorUserPreferences::PREFERENCE_TIME_FORMAT;
|
|
|
|
$format = $this->getPreference($pref_time);
|
|
|
|
}
|
|
|
|
|
|
|
|
return $when->format($format);
|
|
|
|
}
|
|
|
|
|
2015-06-18 15:11:01 -07:00
|
|
|
public function getPreference($key) {
|
|
|
|
$preferences = $this->loadPreferences();
|
|
|
|
|
|
|
|
// TODO: After T4103 and T7707 this should eventually be pushed down the
|
|
|
|
// stack into modular preference definitions and role profiles. This is
|
|
|
|
// just fixing T8601 and mildly anticipating those changes.
|
|
|
|
$value = $preferences->getPreference($key);
|
|
|
|
|
|
|
|
$allowed_values = null;
|
|
|
|
switch ($key) {
|
|
|
|
case PhabricatorUserPreferences::PREFERENCE_TIME_FORMAT:
|
|
|
|
$allowed_values = array(
|
|
|
|
'g:i A',
|
|
|
|
'H:i',
|
|
|
|
);
|
|
|
|
break;
|
|
|
|
case PhabricatorUserPreferences::PREFERENCE_DATE_FORMAT:
|
|
|
|
$allowed_values = array(
|
|
|
|
'Y-m-d',
|
|
|
|
'n/j/Y',
|
|
|
|
'd-m-Y',
|
|
|
|
);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($allowed_values !== null) {
|
|
|
|
$allowed_values = array_fuse($allowed_values);
|
|
|
|
if (empty($allowed_values[$value])) {
|
|
|
|
$value = head($allowed_values);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return $value;
|
|
|
|
}
|
|
|
|
|
2012-06-14 18:08:06 -07:00
|
|
|
public function __toString() {
|
|
|
|
return $this->getUsername();
|
|
|
|
}
|
|
|
|
|
2012-05-07 10:29:33 -07:00
|
|
|
public static function loadOneWithEmailAddress($address) {
|
|
|
|
$email = id(new PhabricatorUserEmail())->loadOneWhere(
|
|
|
|
'address = %s',
|
|
|
|
$address);
|
|
|
|
if (!$email) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
return id(new PhabricatorUser())->loadOneWhere(
|
|
|
|
'phid = %s',
|
|
|
|
$email->getUserPHID());
|
|
|
|
}
|
|
|
|
|
2015-06-05 10:42:49 -07:00
|
|
|
public function getDefaultSpacePHID() {
|
|
|
|
// TODO: We might let the user switch which space they're "in" later on;
|
|
|
|
// for now just use the global space if one exists.
|
|
|
|
|
Improve some Spaces behaviors
Summary:
Ref T8449. Try out some more subtle behaviors:
- Make the "Space" control part of the policy control, so the UI shows "Visible To: [Space][Policy]". I think this helps make the role of spaces more clear. It also makes them easier to implement.
- Don't show the default space in headers: instead, show nothing.
- If the user has access to only one space, pretend spaces don't exist (no edit controls, no header stuff).
This might be confusing, but I think most of the time it will all align fairly well with user expectation.
Test Plan:
- Viewed a list of pastes (saw Space with non-default space, no space with default space, no space with user in only one space).
- Viewed a paste (saw Space with non-default space, saw no space with default space, saw no space with user in only one space).
- Edited spaces on objects (control as privileged user, no control as locked user).
- Created a new paste in a space (got space select as privileged user, no select as locked user).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T8449
Differential Revision: https://secure.phabricator.com/D13229
2015-06-10 15:52:18 -07:00
|
|
|
// If the viewer has access to the default space, use that.
|
2015-06-11 10:13:47 -07:00
|
|
|
$spaces = PhabricatorSpacesNamespaceQuery::getViewerActiveSpaces($this);
|
2015-06-05 10:42:49 -07:00
|
|
|
foreach ($spaces as $space) {
|
|
|
|
if ($space->getIsDefaultNamespace()) {
|
|
|
|
return $space->getPHID();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Improve some Spaces behaviors
Summary:
Ref T8449. Try out some more subtle behaviors:
- Make the "Space" control part of the policy control, so the UI shows "Visible To: [Space][Policy]". I think this helps make the role of spaces more clear. It also makes them easier to implement.
- Don't show the default space in headers: instead, show nothing.
- If the user has access to only one space, pretend spaces don't exist (no edit controls, no header stuff).
This might be confusing, but I think most of the time it will all align fairly well with user expectation.
Test Plan:
- Viewed a list of pastes (saw Space with non-default space, no space with default space, no space with user in only one space).
- Viewed a paste (saw Space with non-default space, saw no space with default space, saw no space with user in only one space).
- Edited spaces on objects (control as privileged user, no control as locked user).
- Created a new paste in a space (got space select as privileged user, no select as locked user).
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T8449
Differential Revision: https://secure.phabricator.com/D13229
2015-06-10 15:52:18 -07:00
|
|
|
// Otherwise, use the space with the lowest ID that they have access to.
|
|
|
|
// This just tends to keep the default stable and predictable over time,
|
|
|
|
// so adding a new space won't change behavior for users.
|
|
|
|
if ($spaces) {
|
|
|
|
$spaces = msort($spaces, 'getID');
|
|
|
|
return head($spaces)->getPHID();
|
|
|
|
}
|
|
|
|
|
2015-06-05 10:42:49 -07:00
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
Improve Phortune policy behavior
Summary:
Currently, PhortuneAccounts have a very open default policy to allow merchants to see and interact with them.
This has the undesirable side effect of leaking their names in too many places, because all users are allowed to load the handles for the accounts. Although this information is not super sensitive, we shouldn't expose it.
I went through about 5 really messy diffs trying to fix this. It's very complicated because there are a lot of objects and many of them are related to PhortuneAccounts, but PhortuneAccounts are not bound to a specific merchant. This lead to a lot of threading viewers and merchants all over the place through the call stack and some really sketchy diffs with OmnipotentUsers that weren't going anywhere good.
This is the cleanest approach I came up with, by far:
- Introduce the concept of an "Authority", which gives a user more powers as a viewer. For now, since we only have one use case, this is pretty open-ended.
- When a viewer is acting as a merchant, grant them authority through the merchant.
- Have Accounts check if the viewer is acting with merchant authority. This lets us easily implement the rule "merchants can see this stuff" without being too broad.
Then update the Subscription view to respect Merchant Authority.
I partially updated the Cart views to respect it. I'll finish this up in a separate diff, but this seemed like a good checkpoint that introduced the concept without too much extra baggage.
This feels pretty good/clean to me, overall, even ignoring the series of horrible messes I made on my way here.
Test Plan:
- Verified I can see everything I need to as a merchant (modulo un-updated Cart UIs).
- Verified I can see nothing when acting as a normal user.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Differential Revision: https://secure.phabricator.com/D11945
2015-03-03 10:38:25 -08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Grant a user a source of authority, to let them bypass policy checks they
|
|
|
|
* could not otherwise.
|
|
|
|
*/
|
|
|
|
public function grantAuthority($authority) {
|
|
|
|
$this->authorities[] = $authority;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get authorities granted to the user.
|
|
|
|
*/
|
|
|
|
public function getAuthorities() {
|
|
|
|
return $this->authorities;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-05-14 11:15:04 -07:00
|
|
|
/* -( Availability )------------------------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @task availability
|
|
|
|
*/
|
2015-05-14 11:15:22 -07:00
|
|
|
public function attachAvailability(array $availability) {
|
2015-05-14 11:15:04 -07:00
|
|
|
$this->availability = $availability;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the timestamp the user is away until, if they are currently away.
|
|
|
|
*
|
|
|
|
* @return int|null Epoch timestamp, or `null` if the user is not away.
|
|
|
|
* @task availability
|
|
|
|
*/
|
|
|
|
public function getAwayUntil() {
|
|
|
|
$availability = $this->availability;
|
|
|
|
|
|
|
|
$this->assertAttached($availability);
|
|
|
|
if (!$availability) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
return idx($availability, 'until');
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Describe the user's availability.
|
|
|
|
*
|
|
|
|
* @param PhabricatorUser Viewing user.
|
|
|
|
* @return string Human-readable description of away status.
|
|
|
|
* @task availability
|
|
|
|
*/
|
|
|
|
public function getAvailabilityDescription(PhabricatorUser $viewer) {
|
|
|
|
$until = $this->getAwayUntil();
|
|
|
|
if ($until) {
|
|
|
|
return pht('Away until %s', phabricator_datetime($until, $viewer));
|
|
|
|
} else {
|
|
|
|
return pht('Available');
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-05-14 11:15:22 -07:00
|
|
|
/**
|
|
|
|
* Get cached availability, if present.
|
|
|
|
*
|
|
|
|
* @return wild|null Cache data, or null if no cache is available.
|
|
|
|
* @task availability
|
|
|
|
*/
|
|
|
|
public function getAvailabilityCache() {
|
|
|
|
$now = PhabricatorTime::getNow();
|
|
|
|
if ($this->availabilityCacheTTL <= $now) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
try {
|
|
|
|
return phutil_json_decode($this->availabilityCache);
|
|
|
|
} catch (Exception $ex) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Write to the availability cache.
|
|
|
|
*
|
|
|
|
* @param wild Availability cache data.
|
|
|
|
* @param int|null Cache TTL.
|
|
|
|
* @return this
|
|
|
|
* @task availability
|
|
|
|
*/
|
|
|
|
public function writeAvailabilityCache(array $availability, $ttl) {
|
|
|
|
$unguarded = AphrontWriteGuard::beginScopedUnguardedWrites();
|
|
|
|
queryfx(
|
|
|
|
$this->establishConnection('w'),
|
|
|
|
'UPDATE %T SET availabilityCache = %s, availabilityCacheTTL = %nd
|
|
|
|
WHERE id = %d',
|
|
|
|
$this->getTableName(),
|
|
|
|
json_encode($availability),
|
|
|
|
$ttl,
|
|
|
|
$this->getID());
|
|
|
|
unset($unguarded);
|
|
|
|
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-05-13 09:46:25 -07:00
|
|
|
/* -( Profile Image Cache )------------------------------------------------ */
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get this user's cached profile image URI.
|
|
|
|
*
|
|
|
|
* @return string|null Cached URI, if a URI is cached.
|
|
|
|
* @task image-cache
|
|
|
|
*/
|
|
|
|
public function getProfileImageCache() {
|
|
|
|
$version = $this->getProfileImageVersion();
|
|
|
|
|
|
|
|
$parts = explode(',', $this->profileImageCache, 2);
|
|
|
|
if (count($parts) !== 2) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($parts[0] !== $version) {
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
return $parts[1];
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Generate a new cache value for this user's profile image.
|
|
|
|
*
|
|
|
|
* @return string New cache value.
|
|
|
|
* @task image-cache
|
|
|
|
*/
|
|
|
|
public function writeProfileImageCache($uri) {
|
|
|
|
$version = $this->getProfileImageVersion();
|
|
|
|
$cache = "{$version},{$uri}";
|
|
|
|
|
|
|
|
$unguarded = AphrontWriteGuard::beginScopedUnguardedWrites();
|
|
|
|
queryfx(
|
|
|
|
$this->establishConnection('w'),
|
|
|
|
'UPDATE %T SET profileImageCache = %s WHERE id = %d',
|
|
|
|
$this->getTableName(),
|
|
|
|
$cache,
|
|
|
|
$this->getID());
|
|
|
|
unset($unguarded);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get a version identifier for a user's profile image.
|
|
|
|
*
|
|
|
|
* This version will change if the image changes, or if any of the
|
|
|
|
* environment configuration which goes into generating a URI changes.
|
|
|
|
*
|
|
|
|
* @return string Cache version.
|
|
|
|
* @task image-cache
|
|
|
|
*/
|
|
|
|
private function getProfileImageVersion() {
|
|
|
|
$parts = array(
|
|
|
|
PhabricatorEnv::getCDNURI('/'),
|
|
|
|
PhabricatorEnv::getEnvConfig('cluster.instance'),
|
|
|
|
$this->getProfileImagePHID(),
|
|
|
|
);
|
|
|
|
$parts = serialize($parts);
|
|
|
|
return PhabricatorHash::digestForIndex($parts);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-06-03 16:50:27 -07:00
|
|
|
/* -( Multi-Factor Authentication )---------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Update the flag storing this user's enrollment in multi-factor auth.
|
|
|
|
*
|
|
|
|
* With certain settings, we need to check if a user has MFA on every page,
|
|
|
|
* so we cache MFA enrollment on the user object for performance. Calling this
|
|
|
|
* method synchronizes the cache by examining enrollment records. After
|
|
|
|
* updating the cache, use @{method:getIsEnrolledInMultiFactor} to check if
|
|
|
|
* the user is enrolled.
|
|
|
|
*
|
|
|
|
* This method should be called after any changes are made to a given user's
|
|
|
|
* multi-factor configuration.
|
|
|
|
*
|
|
|
|
* @return void
|
|
|
|
* @task factors
|
|
|
|
*/
|
|
|
|
public function updateMultiFactorEnrollment() {
|
|
|
|
$factors = id(new PhabricatorAuthFactorConfig())->loadAllWhere(
|
|
|
|
'userPHID = %s',
|
|
|
|
$this->getPHID());
|
|
|
|
|
|
|
|
$enrolled = count($factors) ? 1 : 0;
|
|
|
|
if ($enrolled !== $this->isEnrolledInMultiFactor) {
|
|
|
|
$unguarded = AphrontWriteGuard::beginScopedUnguardedWrites();
|
|
|
|
queryfx(
|
|
|
|
$this->establishConnection('w'),
|
|
|
|
'UPDATE %T SET isEnrolledInMultiFactor = %d WHERE id = %d',
|
|
|
|
$this->getTableName(),
|
|
|
|
$enrolled,
|
|
|
|
$this->getID());
|
|
|
|
unset($unguarded);
|
|
|
|
|
|
|
|
$this->isEnrolledInMultiFactor = $enrolled;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Check if the user is enrolled in multi-factor authentication.
|
|
|
|
*
|
|
|
|
* Enrolled users have one or more multi-factor authentication sources
|
|
|
|
* attached to their account. For performance, this value is cached. You
|
|
|
|
* can use @{method:updateMultiFactorEnrollment} to update the cache.
|
|
|
|
*
|
|
|
|
* @return bool True if the user is enrolled.
|
|
|
|
* @task factors
|
|
|
|
*/
|
|
|
|
public function getIsEnrolledInMultiFactor() {
|
|
|
|
return $this->isEnrolledInMultiFactor;
|
|
|
|
}
|
|
|
|
|
2013-02-28 11:01:40 -08:00
|
|
|
|
|
|
|
/* -( Omnipotence )-------------------------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Returns true if this user is omnipotent. Omnipotent users bypass all policy
|
|
|
|
* checks.
|
|
|
|
*
|
|
|
|
* @return bool True if the user bypasses policy checks.
|
|
|
|
*/
|
|
|
|
public function isOmnipotent() {
|
|
|
|
return $this->omnipotent;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get an omnipotent user object for use in contexts where there is no acting
|
|
|
|
* user, notably daemons.
|
|
|
|
*
|
|
|
|
* @return PhabricatorUser An omnipotent user.
|
|
|
|
*/
|
|
|
|
public static function getOmnipotentUser() {
|
|
|
|
static $user = null;
|
|
|
|
if (!$user) {
|
|
|
|
$user = new PhabricatorUser();
|
|
|
|
$user->omnipotent = true;
|
|
|
|
$user->makeEphemeral();
|
|
|
|
}
|
|
|
|
return $user;
|
|
|
|
}
|
|
|
|
|
2013-05-31 10:51:20 -07:00
|
|
|
|
2015-06-30 11:19:41 -07:00
|
|
|
/**
|
|
|
|
* Get a scalar string identifying this user.
|
|
|
|
*
|
|
|
|
* This is similar to using the PHID, but distinguishes between ominpotent
|
|
|
|
* and public users explicitly. This allows safe construction of cache keys
|
|
|
|
* or cache buckets which do not conflate public and omnipotent users.
|
|
|
|
*
|
|
|
|
* @return string Scalar identifier.
|
|
|
|
*/
|
|
|
|
public function getCacheFragment() {
|
|
|
|
if ($this->isOmnipotent()) {
|
|
|
|
return 'u.omnipotent';
|
|
|
|
}
|
|
|
|
|
|
|
|
$phid = $this->getPHID();
|
|
|
|
if ($phid) {
|
|
|
|
return 'u.'.$phid;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 'u.public';
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-03-30 06:35:32 -07:00
|
|
|
/* -( Managing Handles )--------------------------------------------------- */
|
2015-03-29 18:22:27 -07:00
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get a @{class:PhabricatorHandleList} which benefits from this viewer's
|
|
|
|
* internal handle pool.
|
|
|
|
*
|
|
|
|
* @param list<phid> List of PHIDs to load.
|
|
|
|
* @return PhabricatorHandleList Handle list object.
|
2015-03-30 06:35:32 -07:00
|
|
|
* @task handle
|
2015-03-29 18:22:27 -07:00
|
|
|
*/
|
|
|
|
public function loadHandles(array $phids) {
|
|
|
|
if ($this->handlePool === null) {
|
|
|
|
$this->handlePool = id(new PhabricatorHandlePool())
|
|
|
|
->setViewer($this);
|
|
|
|
}
|
|
|
|
|
|
|
|
return $this->handlePool->newHandleList($phids);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2015-03-30 06:35:32 -07:00
|
|
|
/**
|
|
|
|
* Get a @{class:PHUIHandleView} for a single handle.
|
|
|
|
*
|
|
|
|
* This benefits from the viewer's internal handle pool.
|
|
|
|
*
|
|
|
|
* @param phid PHID to render a handle for.
|
|
|
|
* @return PHUIHandleView View of the handle.
|
|
|
|
* @task handle
|
|
|
|
*/
|
|
|
|
public function renderHandle($phid) {
|
|
|
|
return $this->loadHandles(array($phid))->renderHandle($phid);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get a @{class:PHUIHandleListView} for a list of handles.
|
|
|
|
*
|
|
|
|
* This benefits from the viewer's internal handle pool.
|
|
|
|
*
|
|
|
|
* @param list<phid> List of PHIDs to render.
|
|
|
|
* @return PHUIHandleListView View of the handles.
|
|
|
|
* @task handle
|
|
|
|
*/
|
|
|
|
public function renderHandleList(array $phids) {
|
|
|
|
return $this->loadHandles($phids)->renderList();
|
|
|
|
}
|
|
|
|
|
2015-07-23 11:46:34 -07:00
|
|
|
public function attachBadgePHIDs(array $phids) {
|
|
|
|
$this->badgePHIDs = $phids;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getBadgePHIDs() {
|
|
|
|
return $this->assertAttached($this->badgePHIDs);
|
|
|
|
}
|
|
|
|
|
2015-03-30 06:35:32 -07:00
|
|
|
|
2013-05-31 10:51:20 -07:00
|
|
|
/* -( PhabricatorPolicyInterface )----------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
public function getCapabilities() {
|
|
|
|
return array(
|
|
|
|
PhabricatorPolicyCapability::CAN_VIEW,
|
|
|
|
PhabricatorPolicyCapability::CAN_EDIT,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getPolicy($capability) {
|
|
|
|
switch ($capability) {
|
|
|
|
case PhabricatorPolicyCapability::CAN_VIEW:
|
|
|
|
return PhabricatorPolicies::POLICY_PUBLIC;
|
|
|
|
case PhabricatorPolicyCapability::CAN_EDIT:
|
2015-06-02 08:52:00 -07:00
|
|
|
if ($this->getIsSystemAgent() || $this->getIsMailingList()) {
|
2014-04-02 12:05:34 -07:00
|
|
|
return PhabricatorPolicies::POLICY_ADMIN;
|
|
|
|
} else {
|
|
|
|
return PhabricatorPolicies::POLICY_NOONE;
|
|
|
|
}
|
2013-05-31 10:51:20 -07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
public function hasAutomaticCapability($capability, PhabricatorUser $viewer) {
|
|
|
|
return $this->getPHID() && ($viewer->getPHID() === $this->getPHID());
|
|
|
|
}
|
|
|
|
|
2013-09-27 08:43:41 -07:00
|
|
|
public function describeAutomaticCapability($capability) {
|
|
|
|
switch ($capability) {
|
|
|
|
case PhabricatorPolicyCapability::CAN_EDIT:
|
|
|
|
return pht('Only you can edit your information.');
|
|
|
|
default:
|
|
|
|
return null;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-31 10:51:20 -07:00
|
|
|
|
2013-06-07 09:55:55 -07:00
|
|
|
/* -( PhabricatorCustomFieldInterface )------------------------------------ */
|
|
|
|
|
|
|
|
|
|
|
|
public function getCustomFieldSpecificationForRole($role) {
|
2013-06-07 10:22:45 -07:00
|
|
|
return PhabricatorEnv::getEnvConfig('user.fields');
|
2013-06-07 09:55:55 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
public function getCustomFieldBaseClass() {
|
Support configuration-driven custom fields
Summary:
Ref T1702. Ref T3718. There are a couple of things going on here:
**PhabricatorCustomFieldList**: I added `PhabricatorCustomFieldList`, which is just a convenience class for dealing with lists of fields. Often, current field code does something like this inline in a Controller:
foreach ($fields as $field) {
// do some junk
}
Often, that junk has some slightly subtle implications. Move all of it to `$list->doSomeJunk()` methods (like `appendFieldsToForm()`, `loadFieldsFromStorage()`) to reduce code duplication and prevent errors. This additionally moves an existing list-convenience method there, out of `PhabricatorPropertyListView`.
**PhabricatorUserConfiguredCustomFieldStorage**: Adds `PhabricatorUserConfiguredCustomFieldStorage` for storing custom field data (like "ICQ Handle", "Phone Number", "Desk", "Favorite Flower", etc).
**Configuration-Driven Custom Fields**: Previously, I was thinking about doing these with interfaces, but as I thought about it more I started to dislike that approach. Instead, I built proxies into `PhabricatorCustomField`. Basically, this means that fields (like a custom, configuration-driven "Favorite Flower" field) can just use some other Field to actually provide their implementation (like a "standard" field which knows how to render text areas). The previous approach would have involed subclasssing the "standard" field and implementing an interface, but that would mean that every application would have at least two "base" fields and generally just seemed bleh as I worked through it.
The cost of this approach is that we need a bunch of `proxy` junk in the base class, but that's a one-time cost and I think it simplifies all the implementations and makes them a lot less magical (e.g., all of the custom fields now extend the right base field classes).
**Fixed Some Bugs**: Some of this code hadn't really been run yet and had minor bugs.
Test Plan:
{F54240}
{F54241}
{F54242}
Reviewers: btrahan
Reviewed By: btrahan
CC: aran
Maniphest Tasks: T1702, T1703, T3718
Differential Revision: https://secure.phabricator.com/D6749
2013-08-14 08:10:16 -07:00
|
|
|
return 'PhabricatorUserCustomField';
|
2013-06-07 09:55:55 -07:00
|
|
|
}
|
|
|
|
|
2013-08-14 09:53:59 -07:00
|
|
|
public function getCustomFields() {
|
|
|
|
return $this->assertAttached($this->customFields);
|
2013-06-07 09:55:55 -07:00
|
|
|
}
|
|
|
|
|
2013-08-14 09:53:59 -07:00
|
|
|
public function attachCustomFields(PhabricatorCustomFieldAttachment $fields) {
|
|
|
|
$this->customFields = $fields;
|
2013-06-07 09:55:55 -07:00
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2014-05-01 18:23:31 -07:00
|
|
|
|
2014-07-21 23:59:22 +10:00
|
|
|
/* -( PhabricatorDestructibleInterface )----------------------------------- */
|
2014-05-01 18:23:31 -07:00
|
|
|
|
|
|
|
|
|
|
|
public function destroyObjectPermanently(
|
|
|
|
PhabricatorDestructionEngine $engine) {
|
|
|
|
|
|
|
|
$this->openTransaction();
|
|
|
|
$this->delete();
|
|
|
|
|
|
|
|
$externals = id(new PhabricatorExternalAccount())->loadAllWhere(
|
|
|
|
'userPHID = %s',
|
|
|
|
$this->getPHID());
|
|
|
|
foreach ($externals as $external) {
|
|
|
|
$external->delete();
|
|
|
|
}
|
|
|
|
|
|
|
|
$prefs = id(new PhabricatorUserPreferences())->loadAllWhere(
|
|
|
|
'userPHID = %s',
|
|
|
|
$this->getPHID());
|
|
|
|
foreach ($prefs as $pref) {
|
|
|
|
$pref->delete();
|
|
|
|
}
|
|
|
|
|
|
|
|
$profiles = id(new PhabricatorUserProfile())->loadAllWhere(
|
|
|
|
'userPHID = %s',
|
|
|
|
$this->getPHID());
|
|
|
|
foreach ($profiles as $profile) {
|
|
|
|
$profile->delete();
|
|
|
|
}
|
|
|
|
|
Deactivate SSH keys instead of destroying them completely
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
2016-05-18 09:32:50 -07:00
|
|
|
$keys = id(new PhabricatorAuthSSHKeyQuery())
|
|
|
|
->setViewer($engine->getViewer())
|
|
|
|
->withObjectPHIDs(array($this->getPHID()))
|
|
|
|
->execute();
|
2014-05-01 18:23:31 -07:00
|
|
|
foreach ($keys as $key) {
|
Deactivate SSH keys instead of destroying them completely
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
2016-05-18 09:32:50 -07:00
|
|
|
$engine->destroyObject($key);
|
2014-05-01 18:23:31 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
$emails = id(new PhabricatorUserEmail())->loadAllWhere(
|
|
|
|
'userPHID = %s',
|
|
|
|
$this->getPHID());
|
|
|
|
foreach ($emails as $email) {
|
|
|
|
$email->delete();
|
|
|
|
}
|
|
|
|
|
|
|
|
$sessions = id(new PhabricatorAuthSession())->loadAllWhere(
|
|
|
|
'userPHID = %s',
|
|
|
|
$this->getPHID());
|
|
|
|
foreach ($sessions as $session) {
|
|
|
|
$session->delete();
|
|
|
|
}
|
|
|
|
|
|
|
|
$factors = id(new PhabricatorAuthFactorConfig())->loadAllWhere(
|
|
|
|
'userPHID = %s',
|
|
|
|
$this->getPHID());
|
|
|
|
foreach ($factors as $factor) {
|
|
|
|
$factor->delete();
|
|
|
|
}
|
|
|
|
|
|
|
|
$this->saveTransaction();
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-11-11 08:18:26 -08:00
|
|
|
/* -( PhabricatorSSHPublicKeyInterface )----------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
public function getSSHPublicKeyManagementURI(PhabricatorUser $viewer) {
|
|
|
|
if ($viewer->getPHID() == $this->getPHID()) {
|
|
|
|
// If the viewer is managing their own keys, take them to the normal
|
|
|
|
// panel.
|
|
|
|
return '/settings/panel/ssh/';
|
|
|
|
} else {
|
|
|
|
// Otherwise, take them to the administrative panel for this user.
|
|
|
|
return '/settings/'.$this->getID().'/panel/ssh/';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-11-20 17:33:30 -08:00
|
|
|
public function getSSHKeyDefaultName() {
|
|
|
|
return 'id_rsa_phabricator';
|
|
|
|
}
|
|
|
|
|
2015-06-08 13:35:57 -07:00
|
|
|
|
|
|
|
/* -( PhabricatorApplicationTransactionInterface )------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
public function getApplicationTransactionEditor() {
|
|
|
|
return new PhabricatorUserProfileEditor();
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getApplicationTransactionObject() {
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getApplicationTransactionTemplate() {
|
|
|
|
return new PhabricatorUserTransaction();
|
|
|
|
}
|
|
|
|
|
|
|
|
public function willRenderTimeline(
|
|
|
|
PhabricatorApplicationTransactionView $timeline,
|
|
|
|
AphrontRequest $request) {
|
|
|
|
return $timeline;
|
|
|
|
}
|
|
|
|
|
2015-12-21 09:02:55 -08:00
|
|
|
|
|
|
|
/* -( PhabricatorFulltextInterface )--------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
public function newFulltextEngine() {
|
|
|
|
return new PhabricatorUserFulltextEngine();
|
|
|
|
}
|
|
|
|
|
2011-01-23 18:09:16 -08:00
|
|
|
}
|