1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-12-25 23:10:57 +01:00
phorge-phorge/src/applications/people/storage/PhabricatorExternalAccount.php

141 lines
3.5 KiB
PHP
Raw Normal View History

<?php
final class PhabricatorExternalAccount extends PhabricatorUserDAO
implements PhabricatorPolicyInterface {
protected $userPHID;
protected $accountType;
protected $accountDomain;
protected $accountSecret;
protected $accountID;
protected $displayName;
protected $username;
protected $realName;
protected $email;
protected $emailVerified = 0;
protected $accountURI;
protected $profileImagePHID;
protected $properties = array();
private $profileImageFile = self::ATTACHABLE;
public function getProfileImageFile() {
return $this->assertAttached($this->profileImageFile);
}
public function attachProfileImageFile(PhabricatorFile $file) {
$this->profileImageFile = $file;
return $this;
}
public function generatePHID() {
return PhabricatorPHID::generateNewPHID(
PhabricatorPeopleExternalPHIDType::TYPECONST);
}
public function getConfiguration() {
return array(
self::CONFIG_AUX_PHID => true,
self::CONFIG_SERIALIZATION => array(
'properties' => self::SERIALIZATION_JSON,
),
) + parent::getConfiguration();
}
public function getPhabricatorUser() {
$tmp_usr = id(new PhabricatorUser())
->makeEphemeral()
->setPHID($this->getPHID());
return $tmp_usr;
}
public function getProviderKey() {
return $this->getAccountType().':'.$this->getAccountDomain();
}
public function save() {
if (!$this->getAccountSecret()) {
$this->setAccountSecret(Filesystem::readRandomCharacters(32));
}
return parent::save();
}
public function setProperty($key, $value) {
$this->properties[$key] = $value;
return $this;
}
public function getProperty($key, $default = null) {
return idx($this->properties, $key, $default);
}
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));
}
/* -( 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,
);
}
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;
}
}
public function hasAutomaticCapability($capability, PhabricatorUser $viewer) {
return ($viewer->getPHID() == $this->getUserPHID());
}
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.');
}
}
}