2013-04-19 20:40:13 +02:00
|
|
|
<?php
|
|
|
|
|
2013-06-17 21:14:00 +02:00
|
|
|
final class PhabricatorExternalAccount extends PhabricatorUserDAO
|
|
|
|
implements PhabricatorPolicyInterface {
|
2013-04-19 20:40:13 +02:00
|
|
|
|
2013-04-28 22:22:05 +02:00
|
|
|
protected $userPHID;
|
|
|
|
protected $accountType;
|
|
|
|
protected $accountDomain;
|
|
|
|
protected $accountSecret;
|
|
|
|
protected $accountID;
|
|
|
|
protected $displayName;
|
2013-06-14 15:55:18 +02:00
|
|
|
protected $username;
|
|
|
|
protected $realName;
|
|
|
|
protected $email;
|
|
|
|
protected $emailVerified = 0;
|
|
|
|
protected $accountURI;
|
|
|
|
protected $profileImagePHID;
|
|
|
|
protected $properties = array();
|
2013-04-19 20:40:13 +02:00
|
|
|
|
2013-09-03 15:02:14 +02:00
|
|
|
private $profileImageFile = self::ATTACHABLE;
|
2013-06-17 21:14:00 +02:00
|
|
|
|
|
|
|
public function getProfileImageFile() {
|
2013-09-03 15:02:14 +02:00
|
|
|
return $this->assertAttached($this->profileImageFile);
|
2013-06-17 21:14:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
public function attachProfileImageFile(PhabricatorFile $file) {
|
|
|
|
$this->profileImageFile = $file;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2013-04-20 04:50:21 +02:00
|
|
|
public function generatePHID() {
|
2013-04-19 20:40:13 +02:00
|
|
|
return PhabricatorPHID::generateNewPHID(
|
2014-07-24 00:05:46 +02:00
|
|
|
PhabricatorPeopleExternalPHIDType::TYPECONST);
|
2013-04-20 04:50:21 +02:00
|
|
|
}
|
2013-04-28 22:22:05 +02:00
|
|
|
|
2015-01-13 20:47:05 +01:00
|
|
|
protected function getConfiguration() {
|
2013-04-28 22:22:05 +02:00
|
|
|
return array(
|
|
|
|
self::CONFIG_AUX_PHID => true,
|
2013-06-14 15:55:18 +02:00
|
|
|
self::CONFIG_SERIALIZATION => array(
|
|
|
|
'properties' => self::SERIALIZATION_JSON,
|
|
|
|
),
|
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 16:36:47 +02:00
|
|
|
self::CONFIG_COLUMN_SCHEMA => array(
|
|
|
|
'userPHID' => 'phid?',
|
|
|
|
'accountType' => 'text16',
|
|
|
|
'accountDomain' => 'text64',
|
|
|
|
'accountSecret' => 'text?',
|
Fix almost all remaining schemata issues
Summary:
Ref T1191. This fixes nearly every remaining blocker for utf8mb4 -- primarily, overlong keys.
Remaining issue is https://secure.phabricator.com/T1191#77467
Test Plan: I'll annotate inline.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley, hach-que
Maniphest Tasks: T6099, T6129, T6133, T6134, T6150, T6148, T6147, T6146, T6105, T1191
Differential Revision: https://secure.phabricator.com/D10601
2014-10-01 17:18:36 +02:00
|
|
|
'accountID' => 'text64',
|
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 16:36:47 +02:00
|
|
|
'displayName' => 'text255?',
|
|
|
|
'username' => 'text255?',
|
|
|
|
'realName' => 'text255?',
|
|
|
|
'email' => 'text255?',
|
|
|
|
'emailVerified' => 'bool',
|
|
|
|
'profileImagePHID' => 'phid?',
|
|
|
|
'accountURI' => 'text255?',
|
|
|
|
),
|
|
|
|
self::CONFIG_KEY_SCHEMA => array(
|
|
|
|
'account_details' => array(
|
|
|
|
'columns' => array('accountType', 'accountDomain', 'accountID'),
|
|
|
|
'unique' => true,
|
|
|
|
),
|
2016-04-03 19:04:10 +02:00
|
|
|
'key_user' => array(
|
|
|
|
'columns' => array('userPHID'),
|
|
|
|
),
|
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 16:36:47 +02:00
|
|
|
),
|
2013-04-28 22:22:05 +02:00
|
|
|
) + parent::getConfiguration();
|
|
|
|
}
|
|
|
|
|
2013-05-06 20:34:48 +02:00
|
|
|
public function getPhabricatorUser() {
|
|
|
|
$tmp_usr = id(new PhabricatorUser())
|
|
|
|
->makeEphemeral()
|
|
|
|
->setPHID($this->getPHID());
|
|
|
|
return $tmp_usr;
|
|
|
|
}
|
|
|
|
|
2013-06-16 19:14:07 +02:00
|
|
|
public function getProviderKey() {
|
2013-06-16 19:15:16 +02:00
|
|
|
return $this->getAccountType().':'.$this->getAccountDomain();
|
2013-06-16 19:14:07 +02:00
|
|
|
}
|
|
|
|
|
2013-06-14 15:55:18 +02:00
|
|
|
public function save() {
|
|
|
|
if (!$this->getAccountSecret()) {
|
|
|
|
$this->setAccountSecret(Filesystem::readRandomCharacters(32));
|
|
|
|
}
|
|
|
|
return parent::save();
|
|
|
|
}
|
|
|
|
|
2013-06-16 19:14:07 +02:00
|
|
|
public function setProperty($key, $value) {
|
|
|
|
$this->properties[$key] = $value;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getProperty($key, $default = null) {
|
|
|
|
return idx($this->properties, $key, $default);
|
|
|
|
}
|
|
|
|
|
2013-06-17 15:12:45 +02:00
|
|
|
public function isUsableForLogin() {
|
|
|
|
$key = $this->getProviderKey();
|
|
|
|
$provider = PhabricatorAuthProvider::getEnabledProviderByKey($key);
|
|
|
|
|
|
|
|
if (!$provider) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!$provider->shouldAllowLogin()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
public function getDisplayName() {
|
|
|
|
if (strlen($this->displayName)) {
|
|
|
|
return $this->displayName;
|
|
|
|
}
|
|
|
|
|
|
|
|
// TODO: Figure out how much identifying information we're going to show
|
|
|
|
// to users about external accounts. For now, just show a string which is
|
|
|
|
// clearly not an error, but don't disclose any identifying information.
|
|
|
|
|
|
|
|
$map = array(
|
|
|
|
'email' => pht('Email User'),
|
|
|
|
);
|
|
|
|
|
|
|
|
$type = $this->getAccountType();
|
|
|
|
|
|
|
|
return idx($map, $type, pht('"%s" User', $type));
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2013-06-17 21:14:00 +02:00
|
|
|
|
|
|
|
/* -( PhabricatorPolicyInterface )----------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
public function getCapabilities() {
|
|
|
|
return array(
|
|
|
|
PhabricatorPolicyCapability::CAN_VIEW,
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
PhabricatorPolicyCapability::CAN_EDIT,
|
2013-06-17 21:14:00 +02:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getPolicy($capability) {
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
switch ($capability) {
|
|
|
|
case PhabricatorPolicyCapability::CAN_VIEW:
|
|
|
|
return PhabricatorPolicies::getMostOpenPolicy();
|
|
|
|
case PhabricatorPolicyCapability::CAN_EDIT:
|
|
|
|
return PhabricatorPolicies::POLICY_NOONE;
|
|
|
|
}
|
2013-06-17 21:14:00 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
public function hasAutomaticCapability($capability, PhabricatorUser $viewer) {
|
|
|
|
return ($viewer->getPHID() == $this->getUserPHID());
|
|
|
|
}
|
|
|
|
|
2013-09-27 17:43:41 +02:00
|
|
|
public function describeAutomaticCapability($capability) {
|
Introduce CAN_EDIT for ExternalAccount, and make CAN_VIEW more liberal
Summary:
Fixes T3732. Ref T1205. Ref T3116.
External accounts (like emails used as identities, Facebook accounts, LDAP accounts, etc.) are stored in "ExternalAccount" objects.
Currently, we have a very restrictive `CAN_VIEW` policy for ExternalAccounts, to add an extra layer of protection to make sure users can't use them in unintended ways. For example, it would be bad if a user could link their Phabricator account to a Facebook account without proper authentication. All of the controllers which do sensitive things have checks anyway, but a restrictive CAN_VIEW provided an extra layer of protection. Se T3116 for some discussion.
However, this means that when grey/external users take actions (via email, or via applications like Legalpad) other users can't load the account handles and can't see anything about the actor (they just see "Restricted External Account" or similar).
Balancing these concerns is mostly about not making a huge mess while doing it. This seems like a reasonable approach:
- Add `CAN_EDIT` on these objects.
- Make that very restricted, but open up `CAN_VIEW`.
- Require `CAN_EDIT` any time we're going to do something authentication/identity related.
This is slightly easier to get wrong (forget CAN_EDIT) than other approaches, but pretty simple, and we always have extra checks in place anyway -- this is just a safety net.
I'm not quite sure how we should identify external accounts, so for now we're just rendering "Email User" or similar -- clearly not a bug, but not identifying. We can figure out what to render in the long term elsewhere.
Test Plan:
- Viewed external accounts.
- Linked an external account.
- Refreshed an external account.
- Edited profile picture.
- Viewed sessions panel.
- Published a bunch of stuff to Asana/JIRA.
- Legalpad signature page now shows external accounts.
{F171595}
Reviewers: chad, btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T3732, T1205, T3116
Differential Revision: https://secure.phabricator.com/D9767
2014-07-10 19:18:10 +02:00
|
|
|
switch ($capability) {
|
|
|
|
case PhabricatorPolicyCapability::CAN_VIEW:
|
|
|
|
return null;
|
|
|
|
case PhabricatorPolicyCapability::CAN_EDIT:
|
|
|
|
return pht(
|
|
|
|
'External accounts can only be edited by the account owner.');
|
|
|
|
}
|
2013-09-27 17:43:41 +02:00
|
|
|
}
|
|
|
|
|
2013-04-19 20:40:13 +02:00
|
|
|
}
|