2011-01-31 03:52:29 +01:00
|
|
|
<?php
|
|
|
|
|
2012-03-10 00:46:25 +01:00
|
|
|
final class PhabricatorLogoutController
|
|
|
|
extends PhabricatorAuthController {
|
2011-01-31 03:52:29 +01:00
|
|
|
|
|
|
|
public function shouldRequireLogin() {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
public function shouldRequireEmailVerification() {
|
|
|
|
// Allow unverified users to logout.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2011-05-12 19:06:54 +02:00
|
|
|
public function shouldRequireEnabledUser() {
|
|
|
|
// Allow disabled users to logout.
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2014-05-01 19:23:02 +02:00
|
|
|
public function shouldAllowPartialSessions() {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2011-01-31 03:52:29 +01:00
|
|
|
public function processRequest() {
|
|
|
|
$request = $this->getRequest();
|
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
|
|
|
$user = $request->getUser();
|
2011-01-31 03:52:29 +01:00
|
|
|
|
|
|
|
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
|
|
|
|
2014-01-14 20:05:26 +01:00
|
|
|
$log = PhabricatorUserLog::initializeNewLog(
|
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
|
|
|
$user,
|
2014-01-14 20:05:26 +01:00
|
|
|
$user->getPHID(),
|
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
|
|
|
PhabricatorUserLog::ACTION_LOGOUT);
|
|
|
|
$log->save();
|
|
|
|
|
2011-09-08 23:16:59 +02:00
|
|
|
// Destroy the user's session in the database so logout works even if
|
|
|
|
// their cookies have some issues. We'll detect cookie issues when they
|
|
|
|
// try to login again and tell them to clear any junk.
|
2014-01-23 23:01:35 +01:00
|
|
|
$phsid = $request->getCookie(PhabricatorCookies::COOKIE_SESSION);
|
|
|
|
if (strlen($phsid)) {
|
2014-01-14 22:22:27 +01:00
|
|
|
$session = id(new PhabricatorAuthSessionQuery())
|
|
|
|
->setViewer($user)
|
|
|
|
->withSessionKeys(array($phsid))
|
|
|
|
->executeOne();
|
|
|
|
if ($session) {
|
|
|
|
$session->delete();
|
|
|
|
}
|
2011-09-08 23:16:59 +02:00
|
|
|
}
|
2014-01-23 23:01:35 +01:00
|
|
|
$request->clearCookie(PhabricatorCookies::COOKIE_SESSION);
|
2011-09-08 23:16:59 +02:00
|
|
|
|
2011-01-31 03:52:29 +01:00
|
|
|
return id(new AphrontRedirectResponse())
|
|
|
|
->setURI('/login/');
|
|
|
|
}
|
|
|
|
|
2012-07-25 22:58:49 +02:00
|
|
|
if ($user->getPHID()) {
|
|
|
|
$dialog = id(new AphrontDialogView())
|
|
|
|
->setUser($user)
|
2013-01-27 01:17:44 +01:00
|
|
|
->setTitle(pht('Log out of Phabricator?'))
|
2014-01-23 23:01:35 +01:00
|
|
|
->appendChild(pht('Are you sure you want to log out?'))
|
2013-01-27 01:17:44 +01:00
|
|
|
->addSubmitButton(pht('Logout'))
|
2012-07-25 22:58:49 +02:00
|
|
|
->addCancelButton('/');
|
|
|
|
|
|
|
|
return id(new AphrontDialogResponse())->setDialog($dialog);
|
|
|
|
}
|
|
|
|
|
2011-01-31 03:52:29 +01:00
|
|
|
return id(new AphrontRedirectResponse())->setURI('/');
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|