2011-01-26 22:21:12 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
abstract class PhabricatorAuthController extends PhabricatorController {
|
|
|
|
|
|
|
|
public function buildStandardPageResponse($view, array $data) {
|
|
|
|
$page = $this->buildStandardPageView();
|
|
|
|
|
2013-01-27 01:17:44 +01:00
|
|
|
$page->setApplicationName(pht('Login'));
|
2011-01-26 22:21:12 +01: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 19:13:49 +02:00
|
|
|
protected function renderErrorPage($title, array $messages) {
|
|
|
|
$view = new AphrontErrorView();
|
|
|
|
$view->setTitle($title);
|
|
|
|
$view->setErrors($messages);
|
|
|
|
|
|
|
|
return $this->buildApplicationPage(
|
|
|
|
$view,
|
|
|
|
array(
|
|
|
|
'title' => $title,
|
|
|
|
'device' => true,
|
|
|
|
'dust' => true,
|
|
|
|
));
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function establishWebSession(PhabricatorUser $user) {
|
|
|
|
$session_key = $user->establishSession('web');
|
|
|
|
|
|
|
|
$request = $this->getRequest();
|
|
|
|
|
|
|
|
// NOTE: We allow disabled users to login and roadblock them later, so
|
|
|
|
// there's no check for users being disabled here.
|
|
|
|
|
|
|
|
$request->setCookie('phusr', $user->getUsername());
|
|
|
|
$request->setCookie('phsid', $session_key);
|
|
|
|
$request->clearCookie('phreg');
|
|
|
|
}
|
|
|
|
|
|
|
|
protected function buildLoginValidateResponse(PhabricatorUser $user) {
|
|
|
|
$validate_uri = new PhutilURI($this->getApplicationURI('validate/'));
|
|
|
|
$validate_uri->setQueryParam('phusr', $user->getUsername());
|
|
|
|
|
|
|
|
return id(new AphrontRedirectResponse())->setURI((string)$validate_uri);
|
|
|
|
}
|
|
|
|
|
2011-01-26 22:21:12 +01:00
|
|
|
}
|