1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-27 09:12:41 +01:00
phorge-phorge/scripts/user/account_admin.php

176 lines
4.5 KiB
PHP
Raw Normal View History

#!/usr/bin/env php
<?php
/*
* Copyright 2012 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.
*/
$root = dirname(dirname(dirname(__FILE__)));
require_once $root.'/scripts/__init_script__.php';
echo "Enter a username to create a new account or edit an existing account.";
$username = phutil_console_prompt("Enter a username:");
if (!strlen($username)) {
echo "Cancelled.\n";
exit(1);
}
if (!PhabricatorUser::validateUsername($username)) {
$valid = PhabricatorUser::describeValidUsername();
echo "The username '{$username}' is invalid. {$valid}\n";
exit(1);
}
$user = id(new PhabricatorUser())->loadOneWhere(
'username = %s',
$username);
if (!$user) {
Mask typed passwords as they are entered into 'accountadmin' Summary: Currently, we echo the password as the user types it. This turns out to be a bit of an issue in over-the-shoulder installs. Instead, disable tty echo while the user is typing their password so nothing is shown (like how 'sudo' works). Also show a better error message if the user chooses a duplicate email; without testing for this we just throw a duplicate key exception when saving, which isn't easy to understand. The other duplicate key exception is duplicate username, which is impossible (the script updates rather than creating in this case). There's currently a bug where creating a user and setting their password at the same time doesn't work. This is because we hash the PHID into the password hash, but it's empty if the user hasn't been persisted yet. Make sure the user is persisted before setting their password. Finally, fix an issue where $original would have the new username set, creating a somewhat confusing summary at the end. I'm also going to improve the password behavior/explanation here once I add welcome emails ("Hi Joe, epriestley created an account for you on Phabricator, click here to login..."). Test Plan: - Typed a password and didn't have it echoed. I also tested this on Ubuntu without encountering problems. - Chose a duplicate email, got a useful error message instead of the exception I'd encountered earlier. - Created a new user with a password in one pass and logged in as that user, this worked properly. - Verified summary table does not contain username for new users. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: moskov, jr, aran, jungejason Differential Revision: 358
2011-05-28 16:17:42 +02:00
$original = new PhabricatorUser();
echo "There is no existing user account '{$username}'.\n";
$ok = phutil_console_confirm(
"Do you want to create a new '{$username}' account?",
$default_no = false);
if (!$ok) {
echo "Cancelled.\n";
exit(1);
}
$user = new PhabricatorUser();
$user->setUsername($username);
Allow users to have multiple email addresses, and verify emails Summary: - Move email to a separate table. - Migrate existing email to new storage. - Allow users to add and remove email addresses. - Allow users to verify email addresses. - Allow users to change their primary email address. - Convert all the registration/reset/login code to understand these changes. - There are a few security considerations here but I think I've addressed them. Principally, it is important to never let a user acquire a verified email address they don't actually own. We ensure this by tightening the scoping of token generation rules to be (user, email) specific. - This should have essentially zero impact on Facebook, but may require some minor changes in the registration code -- I don't exactly remember how it is set up. Not included here (next steps): - Allow configuration to restrict email to certain domains. - Allow configuration to require validated email. Test Plan: This is a fairly extensive, difficult-to-test change. - From "Email Addresses" interface: - Added new email (verified email verifications sent). - Changed primary email (verified old/new notificactions sent). - Resent verification emails (verified they sent). - Removed email. - Tried to add already-owned email. - Created new users with "accountadmin". Edited existing users with "accountadmin". - Created new users with "add_user.php". - Created new users with web interface. - Clicked welcome email link, verified it verified email. - Reset password. - Linked/unlinked oauth accounts. - Logged in with oauth account. - Logged in with email. - Registered with Oauth account. - Tried to register with OAuth account with duplicate email. - Verified errors for email verification with bad tokens, etc. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2393
2012-05-07 19:29:33 +02:00
$is_new = true;
} else {
Mask typed passwords as they are entered into 'accountadmin' Summary: Currently, we echo the password as the user types it. This turns out to be a bit of an issue in over-the-shoulder installs. Instead, disable tty echo while the user is typing their password so nothing is shown (like how 'sudo' works). Also show a better error message if the user chooses a duplicate email; without testing for this we just throw a duplicate key exception when saving, which isn't easy to understand. The other duplicate key exception is duplicate username, which is impossible (the script updates rather than creating in this case). There's currently a bug where creating a user and setting their password at the same time doesn't work. This is because we hash the PHID into the password hash, but it's empty if the user hasn't been persisted yet. Make sure the user is persisted before setting their password. Finally, fix an issue where $original would have the new username set, creating a somewhat confusing summary at the end. I'm also going to improve the password behavior/explanation here once I add welcome emails ("Hi Joe, epriestley created an account for you on Phabricator, click here to login..."). Test Plan: - Typed a password and didn't have it echoed. I also tested this on Ubuntu without encountering problems. - Chose a duplicate email, got a useful error message instead of the exception I'd encountered earlier. - Created a new user with a password in one pass and logged in as that user, this worked properly. - Verified summary table does not contain username for new users. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: moskov, jr, aran, jungejason Differential Revision: 358
2011-05-28 16:17:42 +02:00
$original = clone $user;
echo "There is an existing user account '{$username}'.\n";
$ok = phutil_console_confirm(
"Do you want to edit the existing '{$username}' account?",
$default_no = false);
if (!$ok) {
echo "Cancelled.\n";
exit(1);
}
Allow users to have multiple email addresses, and verify emails Summary: - Move email to a separate table. - Migrate existing email to new storage. - Allow users to add and remove email addresses. - Allow users to verify email addresses. - Allow users to change their primary email address. - Convert all the registration/reset/login code to understand these changes. - There are a few security considerations here but I think I've addressed them. Principally, it is important to never let a user acquire a verified email address they don't actually own. We ensure this by tightening the scoping of token generation rules to be (user, email) specific. - This should have essentially zero impact on Facebook, but may require some minor changes in the registration code -- I don't exactly remember how it is set up. Not included here (next steps): - Allow configuration to restrict email to certain domains. - Allow configuration to require validated email. Test Plan: This is a fairly extensive, difficult-to-test change. - From "Email Addresses" interface: - Added new email (verified email verifications sent). - Changed primary email (verified old/new notificactions sent). - Resent verification emails (verified they sent). - Removed email. - Tried to add already-owned email. - Created new users with "accountadmin". Edited existing users with "accountadmin". - Created new users with "add_user.php". - Created new users with web interface. - Clicked welcome email link, verified it verified email. - Reset password. - Linked/unlinked oauth accounts. - Logged in with oauth account. - Logged in with email. - Registered with Oauth account. - Tried to register with OAuth account with duplicate email. - Verified errors for email verification with bad tokens, etc. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2393
2012-05-07 19:29:33 +02:00
$is_new = false;
}
$user_realname = $user->getRealName();
if (strlen($user_realname)) {
$realname_prompt = ' ['.$user_realname.']';
} else {
$realname_prompt = '';
}
$realname = nonempty(
phutil_console_prompt("Enter user real name{$realname_prompt}:"),
$user_realname);
$user->setRealName($realname);
Allow users to have multiple email addresses, and verify emails Summary: - Move email to a separate table. - Migrate existing email to new storage. - Allow users to add and remove email addresses. - Allow users to verify email addresses. - Allow users to change their primary email address. - Convert all the registration/reset/login code to understand these changes. - There are a few security considerations here but I think I've addressed them. Principally, it is important to never let a user acquire a verified email address they don't actually own. We ensure this by tightening the scoping of token generation rules to be (user, email) specific. - This should have essentially zero impact on Facebook, but may require some minor changes in the registration code -- I don't exactly remember how it is set up. Not included here (next steps): - Allow configuration to restrict email to certain domains. - Allow configuration to require validated email. Test Plan: This is a fairly extensive, difficult-to-test change. - From "Email Addresses" interface: - Added new email (verified email verifications sent). - Changed primary email (verified old/new notificactions sent). - Resent verification emails (verified they sent). - Removed email. - Tried to add already-owned email. - Created new users with "accountadmin". Edited existing users with "accountadmin". - Created new users with "add_user.php". - Created new users with web interface. - Clicked welcome email link, verified it verified email. - Reset password. - Linked/unlinked oauth accounts. - Logged in with oauth account. - Logged in with email. - Registered with Oauth account. - Tried to register with OAuth account with duplicate email. - Verified errors for email verification with bad tokens, etc. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2393
2012-05-07 19:29:33 +02:00
// When creating a new user we prompt for an email address; when editing an
// existing user we just skip this because it would be quite involved to provide
// a reasonable CLI interface for editing multiple addresses and managing email
// verification and primary addresses.
$new_email = null;
if ($is_new) {
do {
$email = phutil_console_prompt("Enter user email address:");
$duplicate = id(new PhabricatorUserEmail())->loadOneWhere(
'address = %s',
$email);
if ($duplicate) {
echo "ERROR: There is already a user with that email address. ".
"Each user must have a unique email address.\n";
} else {
break;
}
} while (true);
$new_email = $email;
}
Mask typed passwords as they are entered into 'accountadmin' Summary: Currently, we echo the password as the user types it. This turns out to be a bit of an issue in over-the-shoulder installs. Instead, disable tty echo while the user is typing their password so nothing is shown (like how 'sudo' works). Also show a better error message if the user chooses a duplicate email; without testing for this we just throw a duplicate key exception when saving, which isn't easy to understand. The other duplicate key exception is duplicate username, which is impossible (the script updates rather than creating in this case). There's currently a bug where creating a user and setting their password at the same time doesn't work. This is because we hash the PHID into the password hash, but it's empty if the user hasn't been persisted yet. Make sure the user is persisted before setting their password. Finally, fix an issue where $original would have the new username set, creating a somewhat confusing summary at the end. I'm also going to improve the password behavior/explanation here once I add welcome emails ("Hi Joe, epriestley created an account for you on Phabricator, click here to login..."). Test Plan: - Typed a password and didn't have it echoed. I also tested this on Ubuntu without encountering problems. - Chose a duplicate email, got a useful error message instead of the exception I'd encountered earlier. - Created a new user with a password in one pass and logged in as that user, this worked properly. - Verified summary table does not contain username for new users. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: moskov, jr, aran, jungejason Differential Revision: 358
2011-05-28 16:17:42 +02:00
$changed_pass = false;
Mask typed passwords as they are entered into 'accountadmin' Summary: Currently, we echo the password as the user types it. This turns out to be a bit of an issue in over-the-shoulder installs. Instead, disable tty echo while the user is typing their password so nothing is shown (like how 'sudo' works). Also show a better error message if the user chooses a duplicate email; without testing for this we just throw a duplicate key exception when saving, which isn't easy to understand. The other duplicate key exception is duplicate username, which is impossible (the script updates rather than creating in this case). There's currently a bug where creating a user and setting their password at the same time doesn't work. This is because we hash the PHID into the password hash, but it's empty if the user hasn't been persisted yet. Make sure the user is persisted before setting their password. Finally, fix an issue where $original would have the new username set, creating a somewhat confusing summary at the end. I'm also going to improve the password behavior/explanation here once I add welcome emails ("Hi Joe, epriestley created an account for you on Phabricator, click here to login..."). Test Plan: - Typed a password and didn't have it echoed. I also tested this on Ubuntu without encountering problems. - Chose a duplicate email, got a useful error message instead of the exception I'd encountered earlier. - Created a new user with a password in one pass and logged in as that user, this worked properly. - Verified summary table does not contain username for new users. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: moskov, jr, aran, jungejason Differential Revision: 358
2011-05-28 16:17:42 +02:00
// This disables local echo, so the user's password is not shown as they type
// it.
phutil_passthru('stty -echo');
$password = phutil_console_prompt(
"Enter a password for this user [blank to leave unchanged]:");
Mask typed passwords as they are entered into 'accountadmin' Summary: Currently, we echo the password as the user types it. This turns out to be a bit of an issue in over-the-shoulder installs. Instead, disable tty echo while the user is typing their password so nothing is shown (like how 'sudo' works). Also show a better error message if the user chooses a duplicate email; without testing for this we just throw a duplicate key exception when saving, which isn't easy to understand. The other duplicate key exception is duplicate username, which is impossible (the script updates rather than creating in this case). There's currently a bug where creating a user and setting their password at the same time doesn't work. This is because we hash the PHID into the password hash, but it's empty if the user hasn't been persisted yet. Make sure the user is persisted before setting their password. Finally, fix an issue where $original would have the new username set, creating a somewhat confusing summary at the end. I'm also going to improve the password behavior/explanation here once I add welcome emails ("Hi Joe, epriestley created an account for you on Phabricator, click here to login..."). Test Plan: - Typed a password and didn't have it echoed. I also tested this on Ubuntu without encountering problems. - Chose a duplicate email, got a useful error message instead of the exception I'd encountered earlier. - Created a new user with a password in one pass and logged in as that user, this worked properly. - Verified summary table does not contain username for new users. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: moskov, jr, aran, jungejason Differential Revision: 358
2011-05-28 16:17:42 +02:00
phutil_passthru('stty echo');
if (strlen($password)) {
Mask typed passwords as they are entered into 'accountadmin' Summary: Currently, we echo the password as the user types it. This turns out to be a bit of an issue in over-the-shoulder installs. Instead, disable tty echo while the user is typing their password so nothing is shown (like how 'sudo' works). Also show a better error message if the user chooses a duplicate email; without testing for this we just throw a duplicate key exception when saving, which isn't easy to understand. The other duplicate key exception is duplicate username, which is impossible (the script updates rather than creating in this case). There's currently a bug where creating a user and setting their password at the same time doesn't work. This is because we hash the PHID into the password hash, but it's empty if the user hasn't been persisted yet. Make sure the user is persisted before setting their password. Finally, fix an issue where $original would have the new username set, creating a somewhat confusing summary at the end. I'm also going to improve the password behavior/explanation here once I add welcome emails ("Hi Joe, epriestley created an account for you on Phabricator, click here to login..."). Test Plan: - Typed a password and didn't have it echoed. I also tested this on Ubuntu without encountering problems. - Chose a duplicate email, got a useful error message instead of the exception I'd encountered earlier. - Created a new user with a password in one pass and logged in as that user, this worked properly. - Verified summary table does not contain username for new users. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: moskov, jr, aran, jungejason Differential Revision: 358
2011-05-28 16:17:42 +02:00
$changed_pass = $password;
}
$is_admin = $user->getIsAdmin();
$set_admin = phutil_console_confirm(
'Should this user be an administrator?',
$default_no = !$is_admin);
echo "\n\nACCOUNT SUMMARY\n\n";
$tpl = "%12s %-30s %-30s\n";
printf($tpl, null, 'OLD VALUE', 'NEW VALUE');
printf($tpl, 'Username', $original->getUsername(), $user->getUsername());
printf($tpl, 'Real Name', $original->getRealName(), $user->getRealName());
Allow users to have multiple email addresses, and verify emails Summary: - Move email to a separate table. - Migrate existing email to new storage. - Allow users to add and remove email addresses. - Allow users to verify email addresses. - Allow users to change their primary email address. - Convert all the registration/reset/login code to understand these changes. - There are a few security considerations here but I think I've addressed them. Principally, it is important to never let a user acquire a verified email address they don't actually own. We ensure this by tightening the scoping of token generation rules to be (user, email) specific. - This should have essentially zero impact on Facebook, but may require some minor changes in the registration code -- I don't exactly remember how it is set up. Not included here (next steps): - Allow configuration to restrict email to certain domains. - Allow configuration to require validated email. Test Plan: This is a fairly extensive, difficult-to-test change. - From "Email Addresses" interface: - Added new email (verified email verifications sent). - Changed primary email (verified old/new notificactions sent). - Resent verification emails (verified they sent). - Removed email. - Tried to add already-owned email. - Created new users with "accountadmin". Edited existing users with "accountadmin". - Created new users with "add_user.php". - Created new users with web interface. - Clicked welcome email link, verified it verified email. - Reset password. - Linked/unlinked oauth accounts. - Logged in with oauth account. - Logged in with email. - Registered with Oauth account. - Tried to register with OAuth account with duplicate email. - Verified errors for email verification with bad tokens, etc. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2393
2012-05-07 19:29:33 +02:00
if ($new_email) {
printf($tpl, 'Email', '', $new_email);
}
Mask typed passwords as they are entered into 'accountadmin' Summary: Currently, we echo the password as the user types it. This turns out to be a bit of an issue in over-the-shoulder installs. Instead, disable tty echo while the user is typing their password so nothing is shown (like how 'sudo' works). Also show a better error message if the user chooses a duplicate email; without testing for this we just throw a duplicate key exception when saving, which isn't easy to understand. The other duplicate key exception is duplicate username, which is impossible (the script updates rather than creating in this case). There's currently a bug where creating a user and setting their password at the same time doesn't work. This is because we hash the PHID into the password hash, but it's empty if the user hasn't been persisted yet. Make sure the user is persisted before setting their password. Finally, fix an issue where $original would have the new username set, creating a somewhat confusing summary at the end. I'm also going to improve the password behavior/explanation here once I add welcome emails ("Hi Joe, epriestley created an account for you on Phabricator, click here to login..."). Test Plan: - Typed a password and didn't have it echoed. I also tested this on Ubuntu without encountering problems. - Chose a duplicate email, got a useful error message instead of the exception I'd encountered earlier. - Created a new user with a password in one pass and logged in as that user, this worked properly. - Verified summary table does not contain username for new users. Reviewed By: jungejason Reviewers: jungejason, tuomaspelkonen, aran CC: moskov, jr, aran, jungejason Differential Revision: 358
2011-05-28 16:17:42 +02:00
printf($tpl, 'Password', null,
($changed_pass !== false)
? 'Updated'
: 'Unchanged');
printf(
$tpl,
'Admin',
$original->getIsAdmin() ? 'Y' : 'N',
$set_admin ? 'Y' : 'N');
echo "\n";
if (!phutil_console_confirm("Save these changes?", $default_no = false)) {
echo "Cancelled.\n";
exit(1);
}
$user->openTransaction();
$editor = new PhabricatorUserEditor();
// TODO: This is wrong, but we have a chicken-and-egg problem when you use
// this script to create the first user.
$editor->setActor($user);
if ($new_email) {
$email = id(new PhabricatorUserEmail())
->setAddress($new_email)
->setIsVerified(1);
$editor->createNewUser($user, $email);
} else {
$editor->updateUser($user);
}
$editor->makeAdminUser($user, $set_admin);
if ($changed_pass !== false) {
$envelope = new PhutilOpaqueEnvelope($changed_pass);
$editor->changePassword($user, $envelope);
}
$user->saveTransaction();
Allow users to have multiple email addresses, and verify emails Summary: - Move email to a separate table. - Migrate existing email to new storage. - Allow users to add and remove email addresses. - Allow users to verify email addresses. - Allow users to change their primary email address. - Convert all the registration/reset/login code to understand these changes. - There are a few security considerations here but I think I've addressed them. Principally, it is important to never let a user acquire a verified email address they don't actually own. We ensure this by tightening the scoping of token generation rules to be (user, email) specific. - This should have essentially zero impact on Facebook, but may require some minor changes in the registration code -- I don't exactly remember how it is set up. Not included here (next steps): - Allow configuration to restrict email to certain domains. - Allow configuration to require validated email. Test Plan: This is a fairly extensive, difficult-to-test change. - From "Email Addresses" interface: - Added new email (verified email verifications sent). - Changed primary email (verified old/new notificactions sent). - Resent verification emails (verified they sent). - Removed email. - Tried to add already-owned email. - Created new users with "accountadmin". Edited existing users with "accountadmin". - Created new users with "add_user.php". - Created new users with web interface. - Clicked welcome email link, verified it verified email. - Reset password. - Linked/unlinked oauth accounts. - Logged in with oauth account. - Logged in with email. - Registered with Oauth account. - Tried to register with OAuth account with duplicate email. - Verified errors for email verification with bad tokens, etc. Reviewers: btrahan, vrana, jungejason Reviewed By: btrahan CC: aran Maniphest Tasks: T1184 Differential Revision: https://secure.phabricator.com/D2393
2012-05-07 19:29:33 +02:00
echo "Saved changes.\n";