2011-01-24 03:09:16 +01:00
|
|
|
<?php
|
|
|
|
|
2012-03-10 00:46:25 +01:00
|
|
|
final class PhabricatorPeopleEditController
|
|
|
|
extends PhabricatorPeopleController {
|
2011-01-24 03:09:16 +01:00
|
|
|
|
2011-05-12 19:06:54 +02:00
|
|
|
private $id;
|
|
|
|
private $view;
|
2011-01-24 03:09:16 +01:00
|
|
|
|
|
|
|
public function willProcessRequest(array $data) {
|
2011-05-12 19:06:54 +02:00
|
|
|
$this->id = idx($data, 'id');
|
|
|
|
$this->view = idx($data, 'view');
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
public function processRequest() {
|
|
|
|
|
2011-05-12 19:06:54 +02:00
|
|
|
$request = $this->getRequest();
|
|
|
|
$admin = $request->getUser();
|
2011-02-20 01:46:14 +01:00
|
|
|
|
2013-02-21 23:10:22 +01:00
|
|
|
$crumbs = $this->buildApplicationCrumbs($this->buildSideNavView());
|
2011-05-12 19:06:54 +02:00
|
|
|
if ($this->id) {
|
|
|
|
$user = id(new PhabricatorUser())->load($this->id);
|
2011-01-24 03:09:16 +01:00
|
|
|
if (!$user) {
|
|
|
|
return new Aphront404Response();
|
|
|
|
}
|
2012-06-06 16:09:56 +02:00
|
|
|
$base_uri = '/people/edit/'.$user->getID().'/';
|
2013-12-19 02:47:34 +01:00
|
|
|
$crumbs->addTextCrumb(pht('Edit User'), '/people/edit/');
|
|
|
|
$crumbs->addTextCrumb($user->getFullName(), $base_uri);
|
2011-01-24 03:09:16 +01:00
|
|
|
} else {
|
|
|
|
$user = new PhabricatorUser();
|
2012-06-06 16:09:56 +02:00
|
|
|
$base_uri = '/people/edit/';
|
2013-12-19 02:47:34 +01:00
|
|
|
$crumbs->addTextCrumb(pht('Create New User'), $base_uri);
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|
|
|
|
|
2012-06-06 16:09:56 +02:00
|
|
|
$nav = new AphrontSideNavFilterView();
|
|
|
|
$nav->setBaseURI(new PhutilURI($base_uri));
|
2013-02-21 23:10:22 +01:00
|
|
|
$nav->addLabel(pht('User Information'));
|
|
|
|
$nav->addFilter('basic', pht('Basic Information'));
|
|
|
|
$nav->addFilter('profile',
|
|
|
|
pht('View Profile'), '/p/'.$user->getUsername().'/');
|
2011-05-12 19:06:54 +02:00
|
|
|
|
|
|
|
if (!$user->getID()) {
|
2012-06-06 16:09:56 +02:00
|
|
|
$this->view = 'basic';
|
2011-05-12 19:06:54 +02:00
|
|
|
}
|
2012-08-14 00:27:21 +02:00
|
|
|
|
2012-06-06 16:09:56 +02:00
|
|
|
$view = $nav->selectFilter($this->view, 'basic');
|
2011-05-12 19:06:54 +02:00
|
|
|
|
|
|
|
$content = array();
|
|
|
|
|
|
|
|
if ($request->getStr('saved')) {
|
|
|
|
$notice = new AphrontErrorView();
|
|
|
|
$notice->setSeverity(AphrontErrorView::SEVERITY_NOTICE);
|
2013-02-21 23:10:22 +01:00
|
|
|
$notice->setTitle(pht('Changes Saved'));
|
2013-02-07 01:53:49 +01:00
|
|
|
$notice->appendChild(
|
2013-02-21 23:10:22 +01:00
|
|
|
phutil_tag('p', array(), pht('Your changes were saved.')));
|
2011-05-12 19:06:54 +02:00
|
|
|
$content[] = $notice;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch ($view) {
|
|
|
|
case 'basic':
|
|
|
|
$response = $this->processBasicRequest($user);
|
|
|
|
break;
|
2012-06-06 16:09:56 +02:00
|
|
|
default:
|
|
|
|
return new Aphront404Response();
|
2011-05-12 19:06:54 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if ($response instanceof AphrontResponse) {
|
|
|
|
return $response;
|
|
|
|
}
|
|
|
|
|
|
|
|
$content[] = $response;
|
|
|
|
|
|
|
|
if ($user->getID()) {
|
2012-06-06 16:09:56 +02:00
|
|
|
$nav->appendChild($content);
|
2012-08-14 00:27:21 +02:00
|
|
|
} else {
|
|
|
|
$nav = $this->buildSideNavView();
|
|
|
|
$nav->selectFilter('edit');
|
|
|
|
$nav->appendChild($content);
|
2011-05-12 19:06:54 +02:00
|
|
|
}
|
|
|
|
|
2013-02-21 23:10:22 +01:00
|
|
|
$nav->setCrumbs($crumbs);
|
2012-08-14 00:27:21 +02:00
|
|
|
return $this->buildApplicationPage(
|
|
|
|
$nav,
|
2011-05-12 19:06:54 +02:00
|
|
|
array(
|
2013-02-21 23:10:22 +01:00
|
|
|
'title' => pht('Edit User'),
|
|
|
|
'device' => true,
|
2011-05-12 19:06:54 +02:00
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
private function processBasicRequest(PhabricatorUser $user) {
|
|
|
|
$request = $this->getRequest();
|
|
|
|
$admin = $request->getUser();
|
|
|
|
|
2011-01-24 03:09:16 +01:00
|
|
|
$e_username = true;
|
|
|
|
$e_realname = true;
|
|
|
|
$e_email = true;
|
|
|
|
$errors = array();
|
|
|
|
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
$welcome_checked = true;
|
|
|
|
|
2012-05-07 19:29:33 +02:00
|
|
|
$new_email = null;
|
|
|
|
|
2011-01-24 03:09:16 +01:00
|
|
|
$request = $this->getRequest();
|
|
|
|
if ($request->isFormPost()) {
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
$welcome_checked = $request->getInt('welcome');
|
2012-08-29 20:07:29 +02:00
|
|
|
$is_new = !$user->getID();
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
|
2012-08-29 20:07:29 +02:00
|
|
|
if ($is_new) {
|
2011-01-24 03:09:16 +01:00
|
|
|
$user->setUsername($request->getStr('username'));
|
2012-05-07 19:29:33 +02:00
|
|
|
|
|
|
|
$new_email = $request->getStr('email');
|
|
|
|
if (!strlen($new_email)) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$errors[] = pht('Email is required.');
|
|
|
|
$e_email = pht('Required');
|
Allow restriction of permitted email domains
Summary:
Allow allowed email addresses to be restricted to certain domains. This implies email must be verified.
This probably isn't QUITE ready for prime-time without a few other tweaks (better administrative tools, notably) but we're nearly there.
Test Plan:
- With no restrictions:
- Registered with OAuth
- Created an account with accountadmin
- Added an email
- With restrictions:
- Tried to OAuth register with a restricted address, was prompted to provide a valid one.
- Tried to OAuth register with a valid address, worked fine.
- Tried to accountadmin a restricted address, got blocked.
- Tried to accountadmin a valid address, worked fine.
- Tried to add a restricted address, blocked.
- Tried to add a valid address, worked fine.
- Created a user with People with an invalid address, got blocked.
- Created a user with People with a valid address, worked fine.
Reviewers: btrahan, csilvers
Reviewed By: csilvers
CC: aran, joe, csilvers
Maniphest Tasks: T1184
Differential Revision: https://secure.phabricator.com/D2581
2012-05-26 15:04:35 +02:00
|
|
|
} else if (!PhabricatorUserEmail::isAllowedAddress($new_email)) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$e_email = pht('Invalid');
|
Allow restriction of permitted email domains
Summary:
Allow allowed email addresses to be restricted to certain domains. This implies email must be verified.
This probably isn't QUITE ready for prime-time without a few other tweaks (better administrative tools, notably) but we're nearly there.
Test Plan:
- With no restrictions:
- Registered with OAuth
- Created an account with accountadmin
- Added an email
- With restrictions:
- Tried to OAuth register with a restricted address, was prompted to provide a valid one.
- Tried to OAuth register with a valid address, worked fine.
- Tried to accountadmin a restricted address, got blocked.
- Tried to accountadmin a valid address, worked fine.
- Tried to add a restricted address, blocked.
- Tried to add a valid address, worked fine.
- Created a user with People with an invalid address, got blocked.
- Created a user with People with a valid address, worked fine.
Reviewers: btrahan, csilvers
Reviewed By: csilvers
CC: aran, joe, csilvers
Maniphest Tasks: T1184
Differential Revision: https://secure.phabricator.com/D2581
2012-05-26 15:04:35 +02:00
|
|
|
$errors[] = PhabricatorUserEmail::describeAllowedAddresses();
|
Fix transaction handling in PhabricatorUserEditor->createNewUser()
Summary:
See https://github.com/facebook/phabricator/issues/117
- The $user save can hit a duplicate key exception like the email, but we don't handle it correctly.
- When the $user saves but the $email does not, the $user is left with a (rolled-back, invalid) ID. This makes the UI glitch out a bit. Wipe the ID if we abort the transaction.
- We show the "Required" star marker even if the email is filled in.
The ID issue is sort of a general problem, but I think it's fairly rare: you must be doing inserts on related objects and the caller must catch the transaction failure and attempt to handle it in some way.
I can think of three approaches:
- Manually "roll back" the objects inside the transaction, as here. Seems OK if this really is a rare problem.
- Automatically roll back the 'id' and 'phid' columns (if they exist). Seems reasonable but maybe more complicated than necessary. Won't get every case right. For instance, if we inserted a third object here and that failed, $email would still have the userPHID set.
- Automatically roll back the entire object. We can do this by cloning all the writable fields. Seems like it might be way too magical, but maybe the right solution? Might have weird bugs with nonwritable fields and other random stuff.
We can trigger the rollback by storing objects we updated on the transaction, and either throwing them away or rolling them back on saveTransaction() / killTransaction().
These fancier approaches all seem to have some tradeoffs though, and I don't think we need to pick one yet, since this has only caused problems in one case.
Test Plan: Tried to create a new user (via People -> Create New User) with a duplicate username. Got a proper UI message with no exception and no UI glitchiness.
Reviewers: btrahan, vrana, hgrimberg, hgrimberg01
Reviewed By: hgrimberg01
CC: aran
Differential Revision: https://secure.phabricator.com/D2650
2012-06-05 15:46:01 +02:00
|
|
|
} else {
|
|
|
|
$e_email = null;
|
2012-05-07 19:29:33 +02:00
|
|
|
}
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|
|
|
|
$user->setRealName($request->getStr('realname'));
|
|
|
|
|
|
|
|
if (!strlen($user->getUsername())) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$errors[] = pht("Username is required.");
|
|
|
|
$e_username = pht('Required');
|
2012-01-16 16:30:28 +01:00
|
|
|
} else if (!PhabricatorUser::validateUsername($user->getUsername())) {
|
2012-06-06 16:09:05 +02:00
|
|
|
$errors[] = PhabricatorUser::describeValidUsername();
|
2013-02-21 23:10:22 +01:00
|
|
|
$e_username = pht('Invalid');
|
2011-05-12 19:06:54 +02:00
|
|
|
} else {
|
|
|
|
$e_username = null;
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!strlen($user->getRealName())) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$errors[] = pht('Real name is required.');
|
|
|
|
$e_realname = pht('Required');
|
2011-05-12 19:06:54 +02:00
|
|
|
} else {
|
|
|
|
$e_realname = null;
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!$errors) {
|
2011-05-12 19:06:54 +02:00
|
|
|
try {
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
|
2012-05-25 16:30:44 +02:00
|
|
|
if (!$is_new) {
|
|
|
|
id(new PhabricatorUserEditor())
|
|
|
|
->setActor($admin)
|
|
|
|
->updateUser($user);
|
|
|
|
} else {
|
2012-05-07 19:29:33 +02:00
|
|
|
$email = id(new PhabricatorUserEmail())
|
|
|
|
->setAddress($new_email)
|
2012-05-25 16:30:44 +02:00
|
|
|
->setIsVerified(0);
|
2012-05-07 19:29:33 +02:00
|
|
|
|
2013-11-13 20:24:56 +01:00
|
|
|
// Automatically approve the user, since an admin is creating them.
|
|
|
|
$user->setIsApproved(1);
|
|
|
|
|
2012-05-25 16:30:44 +02:00
|
|
|
id(new PhabricatorUserEditor())
|
|
|
|
->setActor($admin)
|
|
|
|
->createNewUser($user, $email);
|
2012-08-29 20:07:29 +02:00
|
|
|
|
|
|
|
if ($request->getStr('role') == 'agent') {
|
|
|
|
id(new PhabricatorUserEditor())
|
|
|
|
->setActor($admin)
|
|
|
|
->makeSystemAgentUser($user, true);
|
|
|
|
}
|
|
|
|
|
2012-07-26 23:41:14 +02:00
|
|
|
}
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
|
2012-07-26 23:41:14 +02:00
|
|
|
if ($welcome_checked) {
|
|
|
|
$user->sendWelcomeEmail($admin);
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
}
|
Provide an activity log for login and administrative actions
Summary: This isn't complete, but I figured I'd ship it for review while it's still smallish.
Provide an activity log for high-level system actions (logins, admin actions). This basically allows two things to happen:
- The log itself is useful if there are shenanigans.
- Password login can check it and start CAPTCHA'ing users after a few failed attempts.
I'm going to change how the admin stuff works a little bit too, since right now you can make someone an agent, grab their certificate, revert them back to a normal user, and then act on their behalf over Conduit. This is a little silly, I'm going to move "agent" to the create workflow instead. I'll also add a confirm/email step to the administrative password reset flow.
Test Plan: Took various administrative and non-administrative actions, they appeared in the logs. Filtered the logs in a bunch of different ways.
Reviewers: jungejason, tuomaspelkonen, aran
CC:
Differential Revision: 302
2011-05-18 03:42:21 +02:00
|
|
|
|
2011-05-12 19:06:54 +02:00
|
|
|
$response = id(new AphrontRedirectResponse())
|
|
|
|
->setURI('/people/edit/'.$user->getID().'/?saved=true');
|
|
|
|
return $response;
|
|
|
|
} catch (AphrontQueryDuplicateKeyException $ex) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$errors[] = pht('Username and email must be unique.');
|
2011-05-12 19:06:54 +02:00
|
|
|
|
|
|
|
$same_username = id(new PhabricatorUser())
|
|
|
|
->loadOneWhere('username = %s', $user->getUsername());
|
2012-05-07 19:29:33 +02:00
|
|
|
$same_email = id(new PhabricatorUserEmail())
|
|
|
|
->loadOneWhere('address = %s', $new_email);
|
2011-05-12 19:06:54 +02:00
|
|
|
|
|
|
|
if ($same_username) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$e_username = pht('Duplicate');
|
2011-05-12 19:06:54 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if ($same_email) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$e_email = pht('Duplicate');
|
2011-05-12 19:06:54 +02:00
|
|
|
}
|
|
|
|
}
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$form = new AphrontFormView();
|
2011-05-12 19:06:54 +02:00
|
|
|
$form->setUser($admin);
|
|
|
|
if ($user->getID()) {
|
|
|
|
$form->setAction('/people/edit/'.$user->getID().'/');
|
2011-01-24 03:09:16 +01:00
|
|
|
} else {
|
|
|
|
$form->setAction('/people/edit/');
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($user->getID()) {
|
|
|
|
$is_immutable = true;
|
|
|
|
} else {
|
|
|
|
$is_immutable = false;
|
|
|
|
}
|
|
|
|
|
|
|
|
$form
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormTextControl())
|
2013-02-21 23:10:22 +01:00
|
|
|
->setLabel(pht('Username'))
|
2011-01-24 03:09:16 +01:00
|
|
|
->setName('username')
|
|
|
|
->setValue($user->getUsername())
|
|
|
|
->setError($e_username)
|
2012-06-16 02:02:20 +02:00
|
|
|
->setDisabled($is_immutable))
|
2011-01-24 03:09:16 +01:00
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormTextControl())
|
2013-02-21 23:10:22 +01:00
|
|
|
->setLabel(pht('Real Name'))
|
2011-01-24 03:09:16 +01:00
|
|
|
->setName('realname')
|
|
|
|
->setValue($user->getRealName())
|
2012-05-07 19:29:33 +02:00
|
|
|
->setError($e_realname));
|
|
|
|
|
|
|
|
if (!$user->getID()) {
|
|
|
|
$form->appendChild(
|
2011-01-24 03:09:16 +01:00
|
|
|
id(new AphrontFormTextControl())
|
2013-02-21 23:10:22 +01:00
|
|
|
->setLabel(pht('Email'))
|
2011-01-24 03:09:16 +01:00
|
|
|
->setName('email')
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
->setDisabled($is_immutable)
|
2012-05-07 19:29:33 +02:00
|
|
|
->setValue($new_email)
|
Allow restriction of permitted email domains
Summary:
Allow allowed email addresses to be restricted to certain domains. This implies email must be verified.
This probably isn't QUITE ready for prime-time without a few other tweaks (better administrative tools, notably) but we're nearly there.
Test Plan:
- With no restrictions:
- Registered with OAuth
- Created an account with accountadmin
- Added an email
- With restrictions:
- Tried to OAuth register with a restricted address, was prompted to provide a valid one.
- Tried to OAuth register with a valid address, worked fine.
- Tried to accountadmin a restricted address, got blocked.
- Tried to accountadmin a valid address, worked fine.
- Tried to add a restricted address, blocked.
- Tried to add a valid address, worked fine.
- Created a user with People with an invalid address, got blocked.
- Created a user with People with a valid address, worked fine.
Reviewers: btrahan, csilvers
Reviewed By: csilvers
CC: aran, joe, csilvers
Maniphest Tasks: T1184
Differential Revision: https://secure.phabricator.com/D2581
2012-05-26 15:04:35 +02:00
|
|
|
->setCaption(PhabricatorUserEmail::describeAllowedAddresses())
|
2012-05-07 19:29:33 +02:00
|
|
|
->setError($e_email));
|
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 21:47:38 +02:00
|
|
|
} else {
|
2012-05-25 16:30:44 +02:00
|
|
|
$email = $user->loadPrimaryEmail();
|
|
|
|
if ($email) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$status = $email->getIsVerified() ?
|
|
|
|
pht('Verified') : pht('Unverified');
|
2012-05-25 16:30:44 +02:00
|
|
|
} else {
|
2013-02-21 23:10:22 +01:00
|
|
|
$status = pht('No Email Address');
|
2012-05-25 16:30:44 +02:00
|
|
|
}
|
|
|
|
|
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 21:47:38 +02:00
|
|
|
$form->appendChild(
|
|
|
|
id(new AphrontFormStaticControl())
|
2013-02-21 23:10:22 +01:00
|
|
|
->setLabel(pht('Email'))
|
2012-05-25 16:30:44 +02:00
|
|
|
->setValue($status));
|
2012-07-26 23:41:14 +02:00
|
|
|
|
|
|
|
$form->appendChild(
|
|
|
|
id(new AphrontFormCheckboxControl())
|
|
|
|
->addCheckbox(
|
|
|
|
'welcome',
|
|
|
|
1,
|
2013-02-21 23:10:22 +01:00
|
|
|
pht('Re-send "Welcome to Phabricator" email.'),
|
2012-07-26 23:41:14 +02:00
|
|
|
false));
|
|
|
|
|
2012-05-07 19:29:33 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
$form->appendChild($this->getRoleInstructions());
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
|
|
|
|
if (!$user->getID()) {
|
|
|
|
$form
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormSelectControl())
|
2013-02-21 23:10:22 +01:00
|
|
|
->setLabel(pht('Role'))
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
->setName('role')
|
|
|
|
->setValue('user')
|
|
|
|
->setOptions(
|
|
|
|
array(
|
2013-02-21 23:10:22 +01:00
|
|
|
'user' => pht('Normal User'),
|
|
|
|
'agent' => pht('System Agent'),
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
))
|
|
|
|
->setCaption(
|
2013-02-21 23:10:22 +01:00
|
|
|
pht('You can create a "system agent" account for bots, '.
|
|
|
|
'scripts, etc.')))
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormCheckboxControl())
|
|
|
|
->addCheckbox(
|
|
|
|
'welcome',
|
|
|
|
1,
|
2013-02-21 23:10:22 +01:00
|
|
|
pht('Send "Welcome to Phabricator" email.'),
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
$welcome_checked));
|
|
|
|
} else {
|
2012-05-07 19:25:36 +02:00
|
|
|
$roles = array();
|
|
|
|
|
|
|
|
if ($user->getIsSystemAgent()) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$roles[] = pht('System Agent');
|
2012-05-07 19:25:36 +02:00
|
|
|
}
|
|
|
|
if ($user->getIsAdmin()) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$roles[] = pht('Admin');
|
2012-05-07 19:25:36 +02:00
|
|
|
}
|
|
|
|
if ($user->getIsDisabled()) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$roles[] = pht('Disabled');
|
2012-05-07 19:25:36 +02: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 23:37:04 +01:00
|
|
|
if (!$user->getIsApproved()) {
|
|
|
|
$roles[] = pht('Not Approved');
|
|
|
|
}
|
2012-05-07 19:25:36 +02:00
|
|
|
if (!$roles) {
|
2013-02-21 23:10:22 +01:00
|
|
|
$roles[] = pht('Normal User');
|
2012-05-07 19:25:36 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
$roles = implode(', ', $roles);
|
|
|
|
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
$form->appendChild(
|
|
|
|
id(new AphrontFormStaticControl())
|
2013-03-26 20:47:25 +01:00
|
|
|
->setLabel(pht('Roles'))
|
2012-05-07 19:25:36 +02:00
|
|
|
->setValue($roles));
|
Revise administrative workflow for user creation
Summary:
- When an administrator creates a user, provide an option to send a welcome
email. Right now this workflow kind of dead-ends.
- Prevent administrators from changing the "System Agent" flag. If they can
change it, they can grab another user's certificate and then act as them. This
is a vaguely weaker security policy than is exhibited elsewhere in the
application. Instead, make user accounts immutably normal users or system agents
at creation time.
- Prevent administrators from changing email addresses after account creation.
Same deal as conduit certs. The 'bin/accountadmin' script can still do this if a
user has a real problem.
- Prevent administrators from resetting passwords. There's no need for this
anymore with welcome emails plus email login and it raises the same issues.
Test Plan:
- Created a new account, selected "send welcome email", got a welcome email,
logged in with the link inside it.
- Created a new system agent.
- Reset an account's password.
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: anjali, aran, epriestley
Differential Revision: 379
2011-05-30 23:59:17 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
$form
|
2011-01-24 03:09:16 +01:00
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormSubmitControl())
|
2013-02-21 23:10:22 +01:00
|
|
|
->setValue(pht('Save')));
|
2011-01-24 03:09:16 +01:00
|
|
|
|
|
|
|
if ($user->getID()) {
|
2013-08-26 20:53:11 +02:00
|
|
|
$title = pht('Edit User');
|
2011-01-24 03:09:16 +01:00
|
|
|
} else {
|
2013-08-26 20:53:11 +02:00
|
|
|
$title = pht('Create New User');
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|
|
|
|
|
2013-09-25 20:23:29 +02:00
|
|
|
$form_box = id(new PHUIObjectBoxView())
|
2013-08-26 20:53:11 +02:00
|
|
|
->setHeaderText($title)
|
2014-01-10 18:17:37 +01:00
|
|
|
->setFormErrors($errors)
|
2013-08-26 20:53:11 +02:00
|
|
|
->setForm($form);
|
|
|
|
|
|
|
|
return array($form_box);
|
2011-05-12 19:06:54 +02:00
|
|
|
}
|
|
|
|
|
2012-04-09 00:10:00 +02:00
|
|
|
private function getRoleInstructions() {
|
2013-01-18 03:57:09 +01:00
|
|
|
$roles_link = phutil_tag(
|
2012-04-09 00:10:00 +02:00
|
|
|
'a',
|
|
|
|
array(
|
|
|
|
'href' => PhabricatorEnv::getDoclink(
|
2012-04-10 19:15:40 +02:00
|
|
|
'article/User_Guide_Account_Roles.html'),
|
2012-04-09 00:10:00 +02:00
|
|
|
'target' => '_blank',
|
|
|
|
),
|
2013-02-21 23:10:22 +01:00
|
|
|
pht('User Guide: Account Roles'));
|
2012-04-09 00:10:00 +02:00
|
|
|
|
2013-11-11 18:23:23 +01:00
|
|
|
return phutil_tag(
|
|
|
|
'p',
|
|
|
|
array('class' => 'aphront-form-instructions'),
|
|
|
|
pht('For a detailed explanation of account roles, see %s.', $roles_link));
|
2012-04-09 00:10:00 +02:00
|
|
|
}
|
|
|
|
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|