2011-01-24 03:09:16 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Copyright 2011 Facebook, Inc.
|
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
class PhabricatorPeopleEditController extends PhabricatorPeopleController {
|
|
|
|
|
2011-05-12 19:06:54 +02:00
|
|
|
public function shouldRequireAdmin() {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
|
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();
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
$user = new PhabricatorUser();
|
|
|
|
}
|
|
|
|
|
2011-05-12 19:06:54 +02:00
|
|
|
$views = array(
|
|
|
|
'basic' => 'Basic Information',
|
|
|
|
'role' => 'Edit Role',
|
2011-05-17 22:15:19 +02:00
|
|
|
'cert' => 'Conduit Certificate',
|
2011-05-12 19:06:54 +02:00
|
|
|
);
|
|
|
|
|
|
|
|
if (!$user->getID()) {
|
|
|
|
$view = 'basic';
|
|
|
|
} else if (isset($views[$this->view])) {
|
|
|
|
$view = $this->view;
|
|
|
|
} else {
|
|
|
|
$view = 'basic';
|
|
|
|
}
|
|
|
|
|
|
|
|
$content = array();
|
|
|
|
|
|
|
|
if ($request->getStr('saved')) {
|
|
|
|
$notice = new AphrontErrorView();
|
|
|
|
$notice->setSeverity(AphrontErrorView::SEVERITY_NOTICE);
|
2011-06-29 18:59:50 +02:00
|
|
|
$notice->setTitle('Changes Saved');
|
2011-05-12 19:06:54 +02:00
|
|
|
$notice->appendChild('<p>Your changes were saved.</p>');
|
|
|
|
$content[] = $notice;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch ($view) {
|
|
|
|
case 'basic':
|
|
|
|
$response = $this->processBasicRequest($user);
|
|
|
|
break;
|
|
|
|
case 'role':
|
|
|
|
$response = $this->processRoleRequest($user);
|
|
|
|
break;
|
2011-05-17 22:15:19 +02:00
|
|
|
case 'cert':
|
|
|
|
$response = $this->processCertificateRequest($user);
|
|
|
|
break;
|
2011-05-12 19:06:54 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if ($response instanceof AphrontResponse) {
|
|
|
|
return $response;
|
|
|
|
}
|
|
|
|
|
|
|
|
$content[] = $response;
|
|
|
|
|
|
|
|
if ($user->getID()) {
|
|
|
|
$side_nav = new AphrontSideNavView();
|
|
|
|
$side_nav->appendChild($content);
|
|
|
|
foreach ($views as $key => $name) {
|
|
|
|
$side_nav->addNavItem(
|
|
|
|
phutil_render_tag(
|
|
|
|
'a',
|
|
|
|
array(
|
|
|
|
'href' => '/people/edit/'.$user->getID().'/'.$key.'/',
|
|
|
|
'class' => ($key == $view)
|
|
|
|
? 'aphront-side-nav-selected'
|
|
|
|
: null,
|
|
|
|
),
|
|
|
|
phutil_escape_html($name)));
|
|
|
|
}
|
|
|
|
$content = $side_nav;
|
|
|
|
}
|
|
|
|
|
|
|
|
return $this->buildStandardPageResponse(
|
|
|
|
$content,
|
|
|
|
array(
|
|
|
|
'title' => 'Edit User',
|
|
|
|
));
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
Provide a configuration flag to disable silliness in the UI
Summary: See comments. A few installs have remarked that their organizations
would prefer buttons labled "Submit" to buttons labeled "Clowncopterize".
Test Plan:
- In "serious" mode, verified Differential and Maniphest have serious strings,
tasks can not be closed out of spite, and reset/welcome emails are extremely
serious.
- In unserious mode, verified Differential and Maniphest have normal strings,
tasks can be closed out of spite, and reset/welcome emails are silly.
- This does not disable the "fax these changes" message in Arcanist (no
reasonable way for it to read the config value) or the rainbow syntax
highlighter (already removable though configuration).
Reviewers: moskov, jungejason, nh, tuomaspelkonen, aran
Reviewed By: moskov
CC: aran, moskov
Differential Revision: 1081
2011-11-04 23:16:34 +01:00
|
|
|
$is_serious = PhabricatorEnv::getEnvConfig('phabricator.serious-business');
|
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
|
|
|
$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');
|
|
|
|
|
2011-01-24 03:09:16 +01:00
|
|
|
if (!$user->getID()) {
|
|
|
|
$user->setUsername($request->getStr('username'));
|
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
|
|
|
$user->setEmail($request->getStr('email'));
|
|
|
|
|
|
|
|
if ($request->getStr('role') == 'agent') {
|
|
|
|
$user->setIsSystemAgent(true);
|
|
|
|
}
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|
|
|
|
$user->setRealName($request->getStr('realname'));
|
|
|
|
|
|
|
|
if (!strlen($user->getUsername())) {
|
|
|
|
$errors[] = "Username is required.";
|
|
|
|
$e_username = 'Required';
|
|
|
|
} else if (!preg_match('/^[a-z0-9]+$/', $user->getUsername())) {
|
|
|
|
$errors[] = "Username must consist of only numbers and letters.";
|
|
|
|
$e_username = '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())) {
|
|
|
|
$errors[] = 'Real name is required.';
|
|
|
|
$e_realname = 'Required';
|
2011-05-12 19:06:54 +02:00
|
|
|
} else {
|
|
|
|
$e_realname = null;
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!strlen($user->getEmail())) {
|
|
|
|
$errors[] = 'Email is required.';
|
|
|
|
$e_email = 'Required';
|
2011-05-12 19:06:54 +02:00
|
|
|
} else {
|
|
|
|
$e_email = 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
|
|
|
$is_new = !$user->getID();
|
|
|
|
|
2011-05-12 19:06:54 +02:00
|
|
|
$user->save();
|
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
|
|
|
|
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 ($is_new) {
|
|
|
|
$log = PhabricatorUserLog::newLog(
|
|
|
|
$admin,
|
|
|
|
$user,
|
|
|
|
PhabricatorUserLog::ACTION_CREATE);
|
|
|
|
$log->save();
|
|
|
|
|
|
|
|
if ($welcome_checked) {
|
|
|
|
$admin_username = $admin->getUserName();
|
|
|
|
$admin_realname = $admin->getRealName();
|
|
|
|
$user_username = $user->getUserName();
|
|
|
|
|
|
|
|
$base_uri = PhabricatorEnv::getProductionURI('/');
|
|
|
|
|
|
|
|
$uri = $user->getEmailLoginURI();
|
|
|
|
$body = <<<EOBODY
|
|
|
|
Welcome to Phabricator!
|
|
|
|
|
|
|
|
{$admin_username} ({$admin_realname}) has created an account for you.
|
|
|
|
|
|
|
|
Username: {$user_username}
|
|
|
|
|
|
|
|
To login to Phabricator, follow this link and set a password:
|
|
|
|
|
|
|
|
{$uri}
|
|
|
|
|
|
|
|
After you have set a password, you can login in the future by going here:
|
|
|
|
|
|
|
|
{$base_uri}
|
|
|
|
|
Provide a configuration flag to disable silliness in the UI
Summary: See comments. A few installs have remarked that their organizations
would prefer buttons labled "Submit" to buttons labeled "Clowncopterize".
Test Plan:
- In "serious" mode, verified Differential and Maniphest have serious strings,
tasks can not be closed out of spite, and reset/welcome emails are extremely
serious.
- In unserious mode, verified Differential and Maniphest have normal strings,
tasks can be closed out of spite, and reset/welcome emails are silly.
- This does not disable the "fax these changes" message in Arcanist (no
reasonable way for it to read the config value) or the rainbow syntax
highlighter (already removable though configuration).
Reviewers: moskov, jungejason, nh, tuomaspelkonen, aran
Reviewed By: moskov
CC: aran, moskov
Differential Revision: 1081
2011-11-04 23:16:34 +01:00
|
|
|
EOBODY;
|
|
|
|
|
|
|
|
if (!$is_serious) {
|
|
|
|
$body .= <<<EOBODY
|
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
|
|
|
Love,
|
|
|
|
Phabricator
|
|
|
|
|
|
|
|
EOBODY;
|
Provide a configuration flag to disable silliness in the UI
Summary: See comments. A few installs have remarked that their organizations
would prefer buttons labled "Submit" to buttons labeled "Clowncopterize".
Test Plan:
- In "serious" mode, verified Differential and Maniphest have serious strings,
tasks can not be closed out of spite, and reset/welcome emails are extremely
serious.
- In unserious mode, verified Differential and Maniphest have normal strings,
tasks can be closed out of spite, and reset/welcome emails are silly.
- This does not disable the "fax these changes" message in Arcanist (no
reasonable way for it to read the config value) or the rainbow syntax
highlighter (already removable though configuration).
Reviewers: moskov, jungejason, nh, tuomaspelkonen, aran
Reviewed By: moskov
CC: aran, moskov
Differential Revision: 1081
2011-11-04 23:16:34 +01: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
|
|
|
$mail = id(new PhabricatorMetaMTAMail())
|
|
|
|
->addTos(array($user->getPHID()))
|
|
|
|
->setSubject('[Phabricator] Welcome to Phabricator')
|
|
|
|
->setBody($body)
|
|
|
|
->setFrom($admin->getPHID())
|
|
|
|
->saveAndSend();
|
|
|
|
}
|
|
|
|
}
|
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) {
|
|
|
|
$errors[] = 'Username and email must be unique.';
|
|
|
|
|
|
|
|
$same_username = id(new PhabricatorUser())
|
|
|
|
->loadOneWhere('username = %s', $user->getUsername());
|
|
|
|
$same_email = id(new PhabricatorUser())
|
|
|
|
->loadOneWhere('email = %s', $user->getEmail());
|
|
|
|
|
|
|
|
if ($same_username) {
|
|
|
|
$e_username = 'Duplicate';
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($same_email) {
|
|
|
|
$e_email = 'Duplicate';
|
|
|
|
}
|
|
|
|
}
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$error_view = null;
|
|
|
|
if ($errors) {
|
|
|
|
$error_view = id(new AphrontErrorView())
|
|
|
|
->setTitle('Form Errors')
|
|
|
|
->setErrors($errors);
|
|
|
|
}
|
|
|
|
|
|
|
|
$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())
|
|
|
|
->setLabel('Username')
|
|
|
|
->setName('username')
|
|
|
|
->setValue($user->getUsername())
|
|
|
|
->setError($e_username)
|
|
|
|
->setDisabled($is_immutable)
|
|
|
|
->setCaption('Usernames are permanent and can not be changed later!'))
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormTextControl())
|
|
|
|
->setLabel('Real Name')
|
|
|
|
->setName('realname')
|
|
|
|
->setValue($user->getRealName())
|
|
|
|
->setError($e_realname))
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormTextControl())
|
|
|
|
->setLabel('Email')
|
|
|
|
->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)
|
2011-01-24 03:09:16 +01:00
|
|
|
->setValue($user->getEmail())
|
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
|
|
|
->setError($e_email));
|
|
|
|
|
|
|
|
if (!$user->getID()) {
|
|
|
|
$form
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormSelectControl())
|
|
|
|
->setLabel('Role')
|
|
|
|
->setName('role')
|
|
|
|
->setValue('user')
|
|
|
|
->setOptions(
|
|
|
|
array(
|
|
|
|
'user' => 'Normal User',
|
|
|
|
'agent' => 'System Agent',
|
|
|
|
))
|
|
|
|
->setCaption(
|
|
|
|
'You can create a "system agent" account for bots, scripts, '.
|
|
|
|
'etc.'))
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormCheckboxControl())
|
|
|
|
->addCheckbox(
|
|
|
|
'welcome',
|
|
|
|
1,
|
|
|
|
'Send "Welcome to Phabricator" email.',
|
|
|
|
$welcome_checked));
|
|
|
|
} else {
|
|
|
|
$form->appendChild(
|
|
|
|
id(new AphrontFormStaticControl())
|
|
|
|
->setLabel('Role')
|
|
|
|
->setValue(
|
|
|
|
$user->getIsSystemAgent()
|
|
|
|
? 'System Agent'
|
|
|
|
: 'Normal User'));
|
|
|
|
}
|
|
|
|
|
|
|
|
$form
|
2011-01-24 03:09:16 +01:00
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormSubmitControl())
|
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
|
|
|
->setValue('Save'));
|
2011-01-24 03:09:16 +01:00
|
|
|
|
|
|
|
$panel = new AphrontPanelView();
|
|
|
|
if ($user->getID()) {
|
|
|
|
$panel->setHeader('Edit User');
|
|
|
|
} else {
|
|
|
|
$panel->setHeader('Create New User');
|
|
|
|
}
|
|
|
|
|
|
|
|
$panel->appendChild($form);
|
|
|
|
$panel->setWidth(AphrontPanelView::WIDTH_FORM);
|
|
|
|
|
2011-05-12 19:06:54 +02:00
|
|
|
return array($error_view, $panel);
|
|
|
|
}
|
|
|
|
|
|
|
|
private function processRoleRequest(PhabricatorUser $user) {
|
|
|
|
$request = $this->getRequest();
|
|
|
|
$admin = $request->getUser();
|
|
|
|
|
|
|
|
$is_self = ($user->getID() == $admin->getID());
|
|
|
|
|
|
|
|
$errors = array();
|
|
|
|
|
|
|
|
if ($request->isFormPost()) {
|
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
|
|
|
|
|
|
|
$log_template = PhabricatorUserLog::newLog(
|
|
|
|
$admin,
|
|
|
|
$user,
|
|
|
|
null);
|
|
|
|
|
|
|
|
$logs = array();
|
|
|
|
|
2011-05-12 19:06:54 +02:00
|
|
|
if ($is_self) {
|
|
|
|
$errors[] = "You can not edit your own role.";
|
|
|
|
} else {
|
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
|
|
|
$new_admin = (bool)$request->getBool('is_admin');
|
|
|
|
$old_admin = (bool)$user->getIsAdmin();
|
|
|
|
if ($new_admin != $old_admin) {
|
|
|
|
$log = clone $log_template;
|
|
|
|
$log->setAction(PhabricatorUserLog::ACTION_ADMIN);
|
|
|
|
$log->setOldValue($old_admin);
|
|
|
|
$log->setNewValue($new_admin);
|
|
|
|
$user->setIsAdmin($new_admin);
|
|
|
|
$logs[] = $log;
|
|
|
|
}
|
|
|
|
|
|
|
|
$new_disabled = (bool)$request->getBool('is_disabled');
|
|
|
|
$old_disabled = (bool)$user->getIsDisabled();
|
|
|
|
if ($new_disabled != $old_disabled) {
|
|
|
|
$log = clone $log_template;
|
|
|
|
$log->setAction(PhabricatorUserLog::ACTION_DISABLE);
|
|
|
|
$log->setOldValue($old_disabled);
|
|
|
|
$log->setNewValue($new_disabled);
|
|
|
|
$user->setIsDisabled($new_disabled);
|
|
|
|
$logs[] = $log;
|
|
|
|
}
|
2011-05-12 19:06:54 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!$errors) {
|
|
|
|
$user->save();
|
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
|
|
|
foreach ($logs as $log) {
|
|
|
|
$log->save();
|
|
|
|
}
|
2011-05-12 19:06:54 +02:00
|
|
|
return id(new AphrontRedirectResponse())
|
|
|
|
->setURI($request->getRequestURI()->alter('saved', 'true'));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
$error_view = null;
|
|
|
|
if ($errors) {
|
|
|
|
$error_view = id(new AphrontErrorView())
|
|
|
|
->setTitle('Form Errors')
|
|
|
|
->setErrors($errors);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
$form = id(new AphrontFormView())
|
|
|
|
->setUser($admin)
|
|
|
|
->setAction($request->getRequestURI()->alter('saved', null));
|
|
|
|
|
|
|
|
if ($is_self) {
|
|
|
|
$form->appendChild(
|
|
|
|
'<p class="aphront-form-instructions">NOTE: You can not edit your own '.
|
|
|
|
'role.</p>');
|
|
|
|
}
|
|
|
|
|
|
|
|
$form
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormCheckboxControl())
|
|
|
|
->addCheckbox(
|
|
|
|
'is_admin',
|
|
|
|
1,
|
|
|
|
'Admin: wields absolute power.',
|
|
|
|
$user->getIsAdmin())
|
|
|
|
->setDisabled($is_self))
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormCheckboxControl())
|
|
|
|
->addCheckbox(
|
|
|
|
'is_disabled',
|
|
|
|
1,
|
|
|
|
'Disabled: can not login.',
|
|
|
|
$user->getIsDisabled())
|
|
|
|
->setDisabled($is_self));
|
|
|
|
|
|
|
|
if (!$is_self) {
|
|
|
|
$form
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormSubmitControl())
|
|
|
|
->setValue('Edit Role'));
|
|
|
|
}
|
|
|
|
|
|
|
|
$panel = new AphrontPanelView();
|
|
|
|
$panel->setHeader('Edit Role');
|
|
|
|
$panel->setWidth(AphrontPanelView::WIDTH_FORM);
|
|
|
|
$panel->appendChild($form);
|
|
|
|
|
|
|
|
return array($error_view, $panel);
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|
|
|
|
|
2011-05-17 22:15:19 +02:00
|
|
|
private function processCertificateRequest($user) {
|
|
|
|
$request = $this->getRequest();
|
|
|
|
$admin = $request->getUser();
|
|
|
|
|
|
|
|
|
|
|
|
$form = new AphrontFormView();
|
|
|
|
$form
|
|
|
|
->setUser($admin)
|
|
|
|
->setAction($request->getRequestURI())
|
|
|
|
->appendChild(
|
|
|
|
'<p class="aphront-form-instructions">You can use this certificate '.
|
|
|
|
'to write scripts or bots which interface with Phabricator over '.
|
|
|
|
'Conduit.</p>');
|
|
|
|
|
|
|
|
if ($user->getIsSystemAgent()) {
|
|
|
|
$form
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormTextControl())
|
|
|
|
->setLabel('Username')
|
|
|
|
->setValue($user->getUsername()))
|
|
|
|
->appendChild(
|
|
|
|
id(new AphrontFormTextAreaControl())
|
|
|
|
->setLabel('Certificate')
|
|
|
|
->setValue($user->getConduitCertificate()));
|
|
|
|
} else {
|
|
|
|
$form->appendChild(
|
|
|
|
id(new AphrontFormStaticControl())
|
|
|
|
->setLabel('Certificate')
|
|
|
|
->setValue(
|
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
|
|
|
'You may only view the certificates of System Agents.'));
|
2011-05-17 22:15:19 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
$panel = new AphrontPanelView();
|
|
|
|
$panel->setHeader('Conduit Certificate');
|
|
|
|
$panel->setWidth(AphrontPanelView::WIDTH_FORM);
|
|
|
|
|
|
|
|
$panel->appendChild($form);
|
|
|
|
|
|
|
|
return array($panel);
|
|
|
|
}
|
|
|
|
|
2011-01-24 03:09:16 +01:00
|
|
|
}
|