2011-01-31 20:55:26 +01:00
|
|
|
<?php
|
|
|
|
|
2012-03-10 00:46:25 +01:00
|
|
|
final class PhabricatorEmailTokenController
|
|
|
|
extends PhabricatorAuthController {
|
2011-01-31 20:55:26 +01:00
|
|
|
|
|
|
|
private $token;
|
|
|
|
|
|
|
|
public function shouldRequireLogin() {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function willProcessRequest(array $data) {
|
|
|
|
$this->token = $data['token'];
|
|
|
|
}
|
|
|
|
|
|
|
|
public function processRequest() {
|
|
|
|
$request = $this->getRequest();
|
|
|
|
|
2011-02-28 04:47:22 +01:00
|
|
|
if (!PhabricatorEnv::getEnvConfig('auth.password-auth-enabled')) {
|
|
|
|
return new Aphront400Response();
|
|
|
|
}
|
|
|
|
|
2011-01-31 20:55:26 +01:00
|
|
|
$token = $this->token;
|
|
|
|
$email = $request->getStr('email');
|
|
|
|
|
2012-05-07 19:29:33 +02:00
|
|
|
// NOTE: We need to bind verification to **addresses**, not **users**,
|
|
|
|
// because we verify addresses when they're used to login this way, and if
|
|
|
|
// we have a user-based verification you can:
|
|
|
|
//
|
|
|
|
// - Add some address you do not own;
|
|
|
|
// - request a password reset;
|
|
|
|
// - change the URI in the email to the address you don't own;
|
|
|
|
// - login via the email link; and
|
|
|
|
// - get a "verified" address you don't control.
|
|
|
|
|
|
|
|
$target_email = id(new PhabricatorUserEmail())->loadOneWhere(
|
|
|
|
'address = %s',
|
2011-01-31 20:55:26 +01:00
|
|
|
$email);
|
|
|
|
|
2012-05-07 19:29:33 +02:00
|
|
|
$target_user = null;
|
|
|
|
if ($target_email) {
|
|
|
|
$target_user = id(new PhabricatorUser())->loadOneWhere(
|
|
|
|
'phid = %s',
|
|
|
|
$target_email->getUserPHID());
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!$target_email ||
|
|
|
|
!$target_user ||
|
|
|
|
!$target_user->validateEmailToken($target_email, $token)) {
|
|
|
|
|
2011-01-31 20:55:26 +01:00
|
|
|
$view = new AphrontRequestFailureView();
|
2013-01-27 01:17:44 +01:00
|
|
|
$view->setHeader(pht('Unable to Login'));
|
2013-02-13 23:08:57 +01:00
|
|
|
$view->appendChild(
|
|
|
|
'<p>'.pht('The authentication information in the link you clicked is '.
|
2011-01-31 20:55:26 +01:00
|
|
|
'invalid or out of date. Make sure you are copy-and-pasting the '.
|
|
|
|
'entire link into your browser. You can try again, or request '.
|
2013-02-13 23:08:57 +01:00
|
|
|
'a new email.').'</p>');
|
|
|
|
$view->appendChild(
|
2011-01-31 20:55:26 +01:00
|
|
|
'<div class="aphront-failure-continue">'.
|
2013-02-13 23:08:57 +01:00
|
|
|
'<a class="button" href="/login/email/">'.
|
|
|
|
pht('Send Another Email').
|
|
|
|
'</a>'.
|
|
|
|
'</div>');
|
2012-05-07 19:29:33 +02:00
|
|
|
|
2011-01-31 20:55:26 +01:00
|
|
|
return $this->buildStandardPageResponse(
|
|
|
|
$view,
|
|
|
|
array(
|
2013-01-27 01:17:44 +01:00
|
|
|
'title' => pht('Login Failure'),
|
2011-01-31 20:55:26 +01:00
|
|
|
));
|
|
|
|
}
|
|
|
|
|
2012-05-07 19:29:33 +02:00
|
|
|
// Verify email so that clicking the link in the "Welcome" email is good
|
|
|
|
// enough, without requiring users to go through a second round of email
|
|
|
|
// verification.
|
|
|
|
|
2012-06-06 16:09:56 +02:00
|
|
|
$unguarded = AphrontWriteGuard::beginScopedUnguardedWrites();
|
|
|
|
$target_email->setIsVerified(1);
|
|
|
|
$target_email->save();
|
|
|
|
$session_key = $target_user->establishSession('web');
|
|
|
|
unset($unguarded);
|
2012-05-07 19:29:33 +02:00
|
|
|
|
Validate logins, and simplify email password resets
Summary:
- There are some recent reports of login issues, see T755 and T754. I'm not
really sure what's going on, but this is an attempt at getting some more
information.
- When we login a user by setting 'phusr' and 'phsid', send them to
/login/validate/ to validate that the cookies actually got set.
- Do email password resets in two steps: first, log the user in. Redirect them
through validate, then give them the option to reset their password.
- Don't CSRF logged-out users. It technically sort of works most of the time
right now, but is silly. If we need logged-out CSRF we should generate it in
some more reliable way.
Test Plan:
- Logged in with username/password.
- Logged in with OAuth.
- Logged in with email password reset.
- Sent bad values to /login/validate/, got appropriate errors.
- Reset password.
- Verified next_uri still works.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, btrahan, j3kuntz
Maniphest Tasks: T754, T755
Differential Revision: https://secure.phabricator.com/D1353
2012-01-10 23:42:07 +01:00
|
|
|
$request->setCookie('phusr', $target_user->getUsername());
|
|
|
|
$request->setCookie('phsid', $session_key);
|
2011-01-31 20:55:26 +01:00
|
|
|
|
Allow configuration of a minimum password length, unify password reset
interfaces
Summary:
- We have a hard-coded minimum length of 3 right now (and 1 in the other
interface), which is sort of silly.
- Provide a more reasonable default, and allow it to be configured.
- We have two password reset interfaces, one of which no longer actually
requires you to verify you own the account. This is more than a bit derp.
- Merge the interfaces into one, using either an email token or the account's
current password to let you change the password.
Test Plan:
- Reset password on an account.
- Changed password on an account.
- Created a new account, logged in, set the password.
- Tried to set a too-short password, got an error.
Reviewers: btrahan, jungejason, nh
Reviewed By: jungejason
CC: aran, jungejason
Maniphest Tasks: T766
Differential Revision: https://secure.phabricator.com/D1374
2012-01-12 05:26:38 +01:00
|
|
|
if (PhabricatorEnv::getEnvConfig('account.editable')) {
|
2012-08-13 21:37:26 +02:00
|
|
|
$next = (string)id(new PhutilURI('/settings/panel/password/'))
|
2012-05-07 19:29:33 +02:00
|
|
|
->setQueryParams(
|
|
|
|
array(
|
|
|
|
'token' => $token,
|
|
|
|
'email' => $email,
|
|
|
|
));
|
Allow configuration of a minimum password length, unify password reset
interfaces
Summary:
- We have a hard-coded minimum length of 3 right now (and 1 in the other
interface), which is sort of silly.
- Provide a more reasonable default, and allow it to be configured.
- We have two password reset interfaces, one of which no longer actually
requires you to verify you own the account. This is more than a bit derp.
- Merge the interfaces into one, using either an email token or the account's
current password to let you change the password.
Test Plan:
- Reset password on an account.
- Changed password on an account.
- Created a new account, logged in, set the password.
- Tried to set a too-short password, got an error.
Reviewers: btrahan, jungejason, nh
Reviewed By: jungejason
CC: aran, jungejason
Maniphest Tasks: T766
Differential Revision: https://secure.phabricator.com/D1374
2012-01-12 05:26:38 +01:00
|
|
|
} else {
|
|
|
|
$next = '/';
|
|
|
|
}
|
|
|
|
|
Validate logins, and simplify email password resets
Summary:
- There are some recent reports of login issues, see T755 and T754. I'm not
really sure what's going on, but this is an attempt at getting some more
information.
- When we login a user by setting 'phusr' and 'phsid', send them to
/login/validate/ to validate that the cookies actually got set.
- Do email password resets in two steps: first, log the user in. Redirect them
through validate, then give them the option to reset their password.
- Don't CSRF logged-out users. It technically sort of works most of the time
right now, but is silly. If we need logged-out CSRF we should generate it in
some more reliable way.
Test Plan:
- Logged in with username/password.
- Logged in with OAuth.
- Logged in with email password reset.
- Sent bad values to /login/validate/, got appropriate errors.
- Reset password.
- Verified next_uri still works.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, btrahan, j3kuntz
Maniphest Tasks: T754, T755
Differential Revision: https://secure.phabricator.com/D1353
2012-01-10 23:42:07 +01:00
|
|
|
$uri = new PhutilURI('/login/validate/');
|
|
|
|
$uri->setQueryParams(
|
2011-01-31 20:55:26 +01:00
|
|
|
array(
|
Validate logins, and simplify email password resets
Summary:
- There are some recent reports of login issues, see T755 and T754. I'm not
really sure what's going on, but this is an attempt at getting some more
information.
- When we login a user by setting 'phusr' and 'phsid', send them to
/login/validate/ to validate that the cookies actually got set.
- Do email password resets in two steps: first, log the user in. Redirect them
through validate, then give them the option to reset their password.
- Don't CSRF logged-out users. It technically sort of works most of the time
right now, but is silly. If we need logged-out CSRF we should generate it in
some more reliable way.
Test Plan:
- Logged in with username/password.
- Logged in with OAuth.
- Logged in with email password reset.
- Sent bad values to /login/validate/, got appropriate errors.
- Reset password.
- Verified next_uri still works.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, btrahan, j3kuntz
Maniphest Tasks: T754, T755
Differential Revision: https://secure.phabricator.com/D1353
2012-01-10 23:42:07 +01:00
|
|
|
'phusr' => $target_user->getUsername(),
|
Allow configuration of a minimum password length, unify password reset
interfaces
Summary:
- We have a hard-coded minimum length of 3 right now (and 1 in the other
interface), which is sort of silly.
- Provide a more reasonable default, and allow it to be configured.
- We have two password reset interfaces, one of which no longer actually
requires you to verify you own the account. This is more than a bit derp.
- Merge the interfaces into one, using either an email token or the account's
current password to let you change the password.
Test Plan:
- Reset password on an account.
- Changed password on an account.
- Created a new account, logged in, set the password.
- Tried to set a too-short password, got an error.
Reviewers: btrahan, jungejason, nh
Reviewed By: jungejason
CC: aran, jungejason
Maniphest Tasks: T766
Differential Revision: https://secure.phabricator.com/D1374
2012-01-12 05:26:38 +01:00
|
|
|
'next' => $next,
|
2011-01-31 20:55:26 +01:00
|
|
|
));
|
|
|
|
|
Validate logins, and simplify email password resets
Summary:
- There are some recent reports of login issues, see T755 and T754. I'm not
really sure what's going on, but this is an attempt at getting some more
information.
- When we login a user by setting 'phusr' and 'phsid', send them to
/login/validate/ to validate that the cookies actually got set.
- Do email password resets in two steps: first, log the user in. Redirect them
through validate, then give them the option to reset their password.
- Don't CSRF logged-out users. It technically sort of works most of the time
right now, but is silly. If we need logged-out CSRF we should generate it in
some more reliable way.
Test Plan:
- Logged in with username/password.
- Logged in with OAuth.
- Logged in with email password reset.
- Sent bad values to /login/validate/, got appropriate errors.
- Reset password.
- Verified next_uri still works.
Reviewers: btrahan, jungejason
Reviewed By: btrahan
CC: aran, btrahan, j3kuntz
Maniphest Tasks: T754, T755
Differential Revision: https://secure.phabricator.com/D1353
2012-01-10 23:42:07 +01:00
|
|
|
return id(new AphrontRedirectResponse())
|
|
|
|
->setURI((string)$uri);
|
|
|
|
}
|
2011-01-31 20:55:26 +01:00
|
|
|
}
|