1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2025-02-26 21:49:08 +01:00
phorge-phorge/src/applications/auth/controller/PhabricatorAuthController.php

306 lines
10 KiB
PHP
Raw Normal View History

2011-01-26 13:21:12 -08:00
<?php
abstract class PhabricatorAuthController extends PhabricatorController {
public function buildStandardPageResponse($view, array $data) {
$page = $this->buildStandardPageView();
$page->setApplicationName(pht('Login'));
2011-01-26 13:21:12 -08:00
$page->setBaseURI('/login/');
$page->setTitle(idx($data, 'title'));
$page->appendChild($view);
$response = new AphrontWebpageResponse();
return $response->setContent($page->render());
}
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 10:13:49 -07:00
protected function renderErrorPage($title, array $messages) {
$view = new PHUIErrorView();
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 10:13:49 -07:00
$view->setTitle($title);
$view->setErrors($messages);
return $this->buildApplicationPage(
$view,
array(
'title' => $title,
));
}
/**
* Returns true if this install is newly setup (i.e., there are no user
* accounts yet). In this case, we enter a special mode to permit creation
* of the first account form the web UI.
*/
protected function isFirstTimeSetup() {
// If there are any auth providers, this isn't first time setup, even if
// we don't have accounts.
if (PhabricatorAuthProvider::getAllEnabledProviders()) {
return false;
}
// Otherwise, check if there are any user accounts. If not, we're in first
// time setup.
$any_users = id(new PhabricatorPeopleQuery())
->setViewer(PhabricatorUser::getOmnipotentUser())
->setLimit(1)
->execute();
return !$any_users;
}
/**
* Log a user into a web session and return an @{class:AphrontResponse} which
* corresponds to continuing the login process.
*
* Normally, this is a redirect to the validation controller which makes sure
* the user's cookies are set. However, event listeners can intercept this
* event and do something else if they prefer.
*
* @param PhabricatorUser User to log the viewer in as.
* @return AphrontResponse Response which continues the login process.
*/
protected function loginUser(PhabricatorUser $user) {
$response = $this->buildLoginValidateResponse($user);
$session_type = PhabricatorAuthSession::TYPE_WEB;
$event_type = PhabricatorEventType::TYPE_AUTH_WILLLOGINUSER;
$event_data = array(
'user' => $user,
'type' => $session_type,
'response' => $response,
'shouldLogin' => true,
);
$event = id(new PhabricatorEvent($event_type, $event_data))
->setUser($user);
PhutilEventEngine::dispatchEvent($event);
$should_login = $event->getValue('shouldLogin');
if ($should_login) {
$session_key = id(new PhabricatorAuthSessionEngine())
->establishSession($session_type, $user->getPHID(), $partial = true);
// NOTE: We allow disabled users to login and roadblock them later, so
// there's no check for users being disabled here.
$request = $this->getRequest();
$request->setCookie(
PhabricatorCookies::COOKIE_USERNAME,
$user->getUsername());
$request->setCookie(
PhabricatorCookies::COOKIE_SESSION,
$session_key);
$this->clearRegistrationCookies();
}
return $event->getValue('response');
}
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 10:13:49 -07:00
protected function clearRegistrationCookies() {
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 10:13:49 -07:00
$request = $this->getRequest();
// Clear the registration key.
$request->clearCookie(PhabricatorCookies::COOKIE_REGISTRATION);
// Clear the client ID / OAuth state key.
$request->clearCookie(PhabricatorCookies::COOKIE_CLIENTID);
// Clear the invite cookie.
$request->clearCookie(PhabricatorCookies::COOKIE_INVITE);
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 10:13:49 -07:00
}
private function buildLoginValidateResponse(PhabricatorUser $user) {
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 10:13:49 -07:00
$validate_uri = new PhutilURI($this->getApplicationURI('validate/'));
$validate_uri->setQueryParam('expect', $user->getUsername());
New Registration Workflow Summary: Currently, registration and authentication are pretty messy. Two concrete problems: - The `PhabricatorLDAPRegistrationController` and `PhabricatorOAuthDefaultRegistrationController` controllers are giant copy/pastes of one another. This is really bad. - We can't practically implement OpenID because we can't reissue the authentication request. Additionally, the OAuth registration controller can be replaced wholesale by config, which is a huge API surface area and a giant mess. Broadly, the problem right now is that registration does too much: we hand it some set of indirect credentials (like OAuth tokens) and expect it to take those the entire way to a registered user. Instead, break registration into smaller steps: - User authenticates with remote service. - Phabricator pulls information (remote account ID, username, email, real name, profile picture, etc) from the remote service and saves it as `PhabricatorUserCredentials`. - Phabricator hands the `PhabricatorUserCredentials` to the registration form, which is agnostic about where they originate from: it can process LDAP credentials, OAuth credentials, plain old email credentials, HTTP basic auth credentials, etc. This doesn't do anything yet -- there is no way to create credentials objects (and no storage patch), but I wanted to get any initial feedback, especially about the event call for T2394. In particular, I think the implementation would look something like this: $profile = $event->getValue('profile') $username = $profile->getDefaultUsername(); $is_employee = is_this_a_facebook_employee($username); if (!$is_employee) { throw new Exception("You are not employed at Facebook."); } $fbid = get_fbid_for_facebook_username($username); $profile->setDefaultEmail($fbid); $profile->setCanEditUsername(false); $profile->setCanEditEmail(false); $profile->setCanEditRealName(false); $profile->setShouldVerifyEmail(true); Seem reasonable? Test Plan: N/A yet, probably fatals. Reviewers: vrana, btrahan, codeblock, chad Reviewed By: btrahan CC: aran, asherkin, nh, wez Maniphest Tasks: T1536, T2394 Differential Revision: https://secure.phabricator.com/D4647
2013-06-16 10:13:49 -07:00
return id(new AphrontRedirectResponse())->setURI((string)$validate_uri);
}
protected function renderError($message) {
return $this->renderErrorPage(
pht('Authentication Error'),
array(
$message,
));
}
protected function loadAccountForRegistrationOrLinking($account_key) {
$request = $this->getRequest();
$viewer = $request->getUser();
$account = null;
$provider = null;
$response = null;
if (!$account_key) {
$response = $this->renderError(
pht('Request did not include account key.'));
return array($account, $provider, $response);
}
// NOTE: We're using the omnipotent user because the actual user may not
// be logged in yet, and because we want to tailor an error message to
// distinguish between "not usable" and "does not exist". We do explicit
// checks later on to make sure this account is valid for the intended
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 10:18:10 -07:00
// operation. This requires edit permission for completeness and consistency
// but it won't actually be meaningfully checked because we're using the
// ominpotent user.
$account = id(new PhabricatorExternalAccountQuery())
->setViewer(PhabricatorUser::getOmnipotentUser())
->withAccountSecrets(array($account_key))
->needImages(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 10:18:10 -07:00
->requireCapabilities(
array(
PhabricatorPolicyCapability::CAN_VIEW,
PhabricatorPolicyCapability::CAN_EDIT,
))
->executeOne();
if (!$account) {
$response = $this->renderError(pht('No valid linkable account.'));
return array($account, $provider, $response);
}
if ($account->getUserPHID()) {
if ($account->getUserPHID() != $viewer->getPHID()) {
$response = $this->renderError(
pht(
'The account you are attempting to register or link is already '.
'linked to another user.'));
} else {
$response = $this->renderError(
pht(
'The account you are attempting to link is already linked '.
'to your account.'));
}
return array($account, $provider, $response);
}
$registration_key = $request->getCookie(
PhabricatorCookies::COOKIE_REGISTRATION);
// NOTE: This registration key check is not strictly necessary, because
// we're only creating new accounts, not linking existing accounts. It
// might be more hassle than it is worth, especially for email.
//
// The attack this prevents is getting to the registration screen, then
// copy/pasting the URL and getting someone else to click it and complete
// the process. They end up with an account bound to credentials you
// control. This doesn't really let you do anything meaningful, though,
// since you could have simply completed the process yourself.
if (!$registration_key) {
$response = $this->renderError(
pht(
'Your browser did not submit a registration key with the request. '.
'You must use the same browser to begin and complete registration. '.
'Check that cookies are enabled and try again.'));
return array($account, $provider, $response);
}
// We store the digest of the key rather than the key itself to prevent a
// theoretical attacker with read-only access to the database from
// hijacking registration sessions.
$actual = $account->getProperty('registrationKey');
$expect = PhabricatorHash::digest($registration_key);
if ($actual !== $expect) {
$response = $this->renderError(
pht(
'Your browser submitted a different registration key than the one '.
'associated with this account. You may need to clear your cookies.'));
return array($account, $provider, $response);
}
$other_account = id(new PhabricatorExternalAccount())->loadAllWhere(
'accountType = %s AND accountDomain = %s AND accountID = %s
AND id != %d',
$account->getAccountType(),
$account->getAccountDomain(),
$account->getAccountID(),
$account->getID());
if ($other_account) {
$response = $this->renderError(
pht(
'The account you are attempting to register with already belongs '.
'to another user.'));
return array($account, $provider, $response);
}
$provider = PhabricatorAuthProvider::getEnabledProviderByKey(
$account->getProviderKey());
if (!$provider) {
$response = $this->renderError(
pht(
'The account you are attempting to register with uses a nonexistent '.
'or disabled authentication provider (with key "%s"). An '.
'administrator may have recently disabled this provider.',
$account->getProviderKey()));
return array($account, $provider, $response);
}
return array($account, $provider, null);
}
protected function loadInvite() {
$invite_cookie = PhabricatorCookies::COOKIE_INVITE;
$invite_code = $this->getRequest()->getCookie($invite_cookie);
if (!$invite_code) {
return null;
}
$engine = id(new PhabricatorAuthInviteEngine())
->setViewer($this->getViewer())
->setUserHasConfirmedVerify(true);
try {
return $engine->processInviteCode($invite_code);
} catch (Exception $ex) {
// If this fails for any reason, just drop the invite. In normal
// circumstances, we gave them a detailed explanation of any error
// before they jumped into this workflow.
return null;
}
}
protected function renderInviteHeader(PhabricatorAuthInvite $invite) {
$viewer = $this->getViewer();
$invite_author = id(new PhabricatorPeopleQuery())
->setViewer($viewer)
->withPHIDs(array($invite->getAuthorPHID()))
->needProfileImage(true)
->executeOne();
// If we can't load the author for some reason, just drop this message.
// We lose the value of contextualizing things without author details.
if (!$invite_author) {
return null;
}
$invite_item = id(new PHUIObjectItemView())
->setHeader(pht('Welcome to Phabricator!'))
->setImageURI($invite_author->getProfileImageURI())
->addAttribute(
pht(
'%s has invited you to join Phabricator.',
$invite_author->getFullName()));
$invite_list = id(new PHUIObjectItemListView())
->addItem($invite_item)
->setFlush(true);
return id(new PHUIBoxView())
->addMargin(PHUI::MARGIN_LARGE)
->appendChild($invite_list);
}
2011-01-26 13:21:12 -08:00
}