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
|
|
|
<?php
|
|
|
|
|
2014-04-28 02:31:35 +02:00
|
|
|
final class PhabricatorUserLog extends PhabricatorUserDAO
|
|
|
|
implements PhabricatorPolicyInterface {
|
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
|
|
|
|
|
|
|
const ACTION_LOGIN = 'login';
|
2014-05-01 19:23:02 +02:00
|
|
|
const ACTION_LOGIN_PARTIAL = 'login-partial';
|
|
|
|
const ACTION_LOGIN_FULL = 'login-full';
|
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
|
|
|
const ACTION_LOGOUT = 'logout';
|
|
|
|
const ACTION_LOGIN_FAILURE = 'login-fail';
|
2015-02-13 00:22:56 +01:00
|
|
|
const ACTION_LOGIN_LEGALPAD = 'login-legalpad';
|
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
|
|
|
const ACTION_RESET_PASSWORD = 'reset-pass';
|
|
|
|
|
|
|
|
const ACTION_CREATE = 'create';
|
2012-05-25 16:30:44 +02:00
|
|
|
const ACTION_EDIT = 'edit';
|
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
|
|
|
|
|
|
|
const ACTION_ADMIN = 'admin';
|
2012-08-29 20:07:29 +02:00
|
|
|
const ACTION_SYSTEM_AGENT = 'system-agent';
|
2015-06-02 17:52:00 +02:00
|
|
|
const ACTION_MAILING_LIST = 'mailing-list';
|
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
|
|
|
const ACTION_DISABLE = 'disable';
|
2013-11-13 20:24:18 +01:00
|
|
|
const ACTION_APPROVE = 'approve';
|
2012-06-16 02:02:20 +02:00
|
|
|
const ACTION_DELETE = 'delete';
|
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-06-14 21:17:14 +02:00
|
|
|
const ACTION_CONDUIT_CERTIFICATE = 'conduit-cert';
|
|
|
|
const ACTION_CONDUIT_CERTIFICATE_FAILURE = 'conduit-cert-fail';
|
|
|
|
|
2012-05-25 16:30:44 +02:00
|
|
|
const ACTION_EMAIL_PRIMARY = 'email-primary';
|
|
|
|
const ACTION_EMAIL_REMOVE = 'email-remove';
|
|
|
|
const ACTION_EMAIL_ADD = 'email-add';
|
2014-06-04 01:45:18 +02:00
|
|
|
const ACTION_EMAIL_VERIFY = 'email-verify';
|
Add email invites to Phabricator (logic only)
Summary:
Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests.
There's no UI to create these yet, so users can't actually get invites (and administrators can't send them).
This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere.
The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible.
Test Plan: Unit tests only.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7152
Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
|
|
|
const ACTION_EMAIL_REASSIGN = 'email-reassign';
|
2012-05-25 16:30:44 +02:00
|
|
|
|
|
|
|
const ACTION_CHANGE_PASSWORD = 'change-password';
|
2012-06-06 16:09:56 +02:00
|
|
|
const ACTION_CHANGE_USERNAME = 'change-username';
|
2012-05-25 16:30:44 +02:00
|
|
|
|
2014-04-28 02:32:09 +02:00
|
|
|
const ACTION_ENTER_HISEC = 'hisec-enter';
|
|
|
|
const ACTION_EXIT_HISEC = 'hisec-exit';
|
2014-04-28 19:20:54 +02:00
|
|
|
const ACTION_FAIL_HISEC = 'hisec-fail';
|
2014-04-28 02:32:09 +02:00
|
|
|
|
2014-04-28 18:27:11 +02:00
|
|
|
const ACTION_MULTI_ADD = 'multi-add';
|
|
|
|
const ACTION_MULTI_REMOVE = 'multi-remove';
|
|
|
|
|
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
|
|
|
protected $actorPHID;
|
|
|
|
protected $userPHID;
|
|
|
|
protected $action;
|
|
|
|
protected $oldValue;
|
|
|
|
protected $newValue;
|
|
|
|
protected $details = array();
|
|
|
|
protected $remoteAddr;
|
|
|
|
protected $session;
|
|
|
|
|
2014-04-28 02:31:35 +02:00
|
|
|
public static function getActionTypeMap() {
|
|
|
|
return array(
|
|
|
|
self::ACTION_LOGIN => pht('Login'),
|
2014-05-01 19:23:02 +02:00
|
|
|
self::ACTION_LOGIN_PARTIAL => pht('Login: Partial Login'),
|
|
|
|
self::ACTION_LOGIN_FULL => pht('Login: Upgrade to Full'),
|
|
|
|
self::ACTION_LOGIN_FAILURE => pht('Login: Failure'),
|
2015-02-13 00:22:56 +01:00
|
|
|
self::ACTION_LOGIN_LEGALPAD =>
|
|
|
|
pht('Login: Signed Required Legalpad Documents'),
|
2014-04-28 02:31:35 +02:00
|
|
|
self::ACTION_LOGOUT => pht('Logout'),
|
|
|
|
self::ACTION_RESET_PASSWORD => pht('Reset Password'),
|
|
|
|
self::ACTION_CREATE => pht('Create Account'),
|
|
|
|
self::ACTION_EDIT => pht('Edit Account'),
|
|
|
|
self::ACTION_ADMIN => pht('Add/Remove Administrator'),
|
|
|
|
self::ACTION_SYSTEM_AGENT => pht('Add/Remove System Agent'),
|
2015-06-02 17:52:00 +02:00
|
|
|
self::ACTION_MAILING_LIST => pht('Add/Remove Mailing List'),
|
2014-04-28 02:31:35 +02:00
|
|
|
self::ACTION_DISABLE => pht('Enable/Disable'),
|
|
|
|
self::ACTION_APPROVE => pht('Approve Registration'),
|
|
|
|
self::ACTION_DELETE => pht('Delete User'),
|
|
|
|
self::ACTION_CONDUIT_CERTIFICATE
|
|
|
|
=> pht('Conduit: Read Certificate'),
|
|
|
|
self::ACTION_CONDUIT_CERTIFICATE_FAILURE
|
|
|
|
=> pht('Conduit: Read Certificate Failure'),
|
|
|
|
self::ACTION_EMAIL_PRIMARY => pht('Email: Change Primary'),
|
|
|
|
self::ACTION_EMAIL_ADD => pht('Email: Add Address'),
|
|
|
|
self::ACTION_EMAIL_REMOVE => pht('Email: Remove Address'),
|
2014-06-04 01:45:18 +02:00
|
|
|
self::ACTION_EMAIL_VERIFY => pht('Email: Verify'),
|
Add email invites to Phabricator (logic only)
Summary:
Ref T7152. This builds the core of email invites and implements all the hard logic for them, covering it with a pile of tests.
There's no UI to create these yet, so users can't actually get invites (and administrators can't send them).
This stuff is a complicated mess because there are so many interactions between accounts, email addresses, email verification, email primary-ness, and user verification. However, I think I got it right and got test coverage everwhere.
The degree to which this is exception-driven is a little icky, but I think it's a reasonable way to get the testability we want while still making it hard for callers to get the flow wrong. In particular, I expect there to be at least two callers (one invite flow in the upstream, and one derived invite flow in Instances) so I believe there is merit in burying as much of this logic inside the Engine as is reasonably possible.
Test Plan: Unit tests only.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T7152
Differential Revision: https://secure.phabricator.com/D11723
2015-02-10 01:12:36 +01:00
|
|
|
self::ACTION_EMAIL_REASSIGN => pht('Email: Reassign'),
|
2014-04-28 02:31:35 +02:00
|
|
|
self::ACTION_CHANGE_PASSWORD => pht('Change Password'),
|
|
|
|
self::ACTION_CHANGE_USERNAME => pht('Change Username'),
|
2014-04-28 02:32:09 +02:00
|
|
|
self::ACTION_ENTER_HISEC => pht('Hisec: Enter'),
|
|
|
|
self::ACTION_EXIT_HISEC => pht('Hisec: Exit'),
|
2014-04-28 19:20:54 +02:00
|
|
|
self::ACTION_FAIL_HISEC => pht('Hisec: Failed Attempt'),
|
2014-04-28 18:27:11 +02:00
|
|
|
self::ACTION_MULTI_ADD => pht('Multi-Factor: Add Factor'),
|
|
|
|
self::ACTION_MULTI_REMOVE => pht('Multi-Factor: Remove Factor'),
|
2014-04-28 02:31:35 +02:00
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2014-01-14 20:05:26 +01:00
|
|
|
public static function 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
|
|
|
PhabricatorUser $actor = null,
|
2015-05-18 22:57:21 +02:00
|
|
|
$object_phid = null,
|
|
|
|
$action = null) {
|
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 = new PhabricatorUserLog();
|
|
|
|
|
|
|
|
if ($actor) {
|
|
|
|
$log->setActorPHID($actor->getPHID());
|
2014-04-28 02:31:35 +02:00
|
|
|
if ($actor->hasSession()) {
|
|
|
|
$session = $actor->getSession();
|
|
|
|
|
|
|
|
// NOTE: This is a hash of the real session value, so it's safe to
|
|
|
|
// store it directly in the logs.
|
|
|
|
$log->setSession($session->getSessionKey());
|
|
|
|
}
|
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->setUserPHID((string)$object_phid);
|
|
|
|
$log->setAction($action);
|
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
|
|
|
|
Normalize remote IP addresses when writing to logs, etc
Summary:
Ref T11939. IPv4 addresses can normally only be written in one way, but IPv6 addresses have several formats.
For example, the addresses "FFF::", "FfF::", "fff::", "0ffF::", "0fFf:0::", and "0FfF:0:0:0:0:0:0:0" are all the same address.
Normalize all addresses before writing them to logs, etc, so we store the most-preferred form ("fff::", above).
Test Plan:
Ran an SSH clone over IPv6:
```
$ git fetch ssh://local@::1/diffusion/26/locktopia.git
```
It worked; verified that address read out of `SSH_CLIENT` sensibly.
Faked my remote address as a non-preferred-form IPv6 address using `preamble.php`.
Failed to login, verified that the preferred-form version of the address appeared in the user activity log.
Made IPv6 requests over HTTP:
```
$ curl -H "Host: local.phacility.com" "http://[::1]/"
```
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11939
Differential Revision: https://secure.phabricator.com/D16987
2016-12-05 19:25:18 +01:00
|
|
|
$address = PhabricatorEnv::getRemoteAddress();
|
|
|
|
if ($address) {
|
|
|
|
$log->remoteAddr = $address->getAddress();
|
|
|
|
} else {
|
|
|
|
$log->remoteAddr = '';
|
|
|
|
}
|
2014-04-28 02:31:35 +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
|
|
|
return $log;
|
|
|
|
}
|
|
|
|
|
2011-06-14 21:17:14 +02:00
|
|
|
public static function loadRecentEventsFromThisIP($action, $timespan) {
|
Normalize remote IP addresses when writing to logs, etc
Summary:
Ref T11939. IPv4 addresses can normally only be written in one way, but IPv6 addresses have several formats.
For example, the addresses "FFF::", "FfF::", "fff::", "0ffF::", "0fFf:0::", and "0FfF:0:0:0:0:0:0:0" are all the same address.
Normalize all addresses before writing them to logs, etc, so we store the most-preferred form ("fff::", above).
Test Plan:
Ran an SSH clone over IPv6:
```
$ git fetch ssh://local@::1/diffusion/26/locktopia.git
```
It worked; verified that address read out of `SSH_CLIENT` sensibly.
Faked my remote address as a non-preferred-form IPv6 address using `preamble.php`.
Failed to login, verified that the preferred-form version of the address appeared in the user activity log.
Made IPv6 requests over HTTP:
```
$ curl -H "Host: local.phacility.com" "http://[::1]/"
```
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11939
Differential Revision: https://secure.phabricator.com/D16987
2016-12-05 19:25:18 +01:00
|
|
|
$address = PhabricatorEnv::getRemoteAddress();
|
|
|
|
if (!$address) {
|
|
|
|
return array();
|
|
|
|
}
|
|
|
|
|
2011-06-14 21:17:14 +02:00
|
|
|
return id(new PhabricatorUserLog())->loadAllWhere(
|
|
|
|
'action = %s AND remoteAddr = %s AND dateCreated > %d
|
|
|
|
ORDER BY dateCreated DESC',
|
|
|
|
$action,
|
Normalize remote IP addresses when writing to logs, etc
Summary:
Ref T11939. IPv4 addresses can normally only be written in one way, but IPv6 addresses have several formats.
For example, the addresses "FFF::", "FfF::", "fff::", "0ffF::", "0fFf:0::", and "0FfF:0:0:0:0:0:0:0" are all the same address.
Normalize all addresses before writing them to logs, etc, so we store the most-preferred form ("fff::", above).
Test Plan:
Ran an SSH clone over IPv6:
```
$ git fetch ssh://local@::1/diffusion/26/locktopia.git
```
It worked; verified that address read out of `SSH_CLIENT` sensibly.
Faked my remote address as a non-preferred-form IPv6 address using `preamble.php`.
Failed to login, verified that the preferred-form version of the address appeared in the user activity log.
Made IPv6 requests over HTTP:
```
$ curl -H "Host: local.phacility.com" "http://[::1]/"
```
Reviewers: chad
Reviewed By: chad
Maniphest Tasks: T11939
Differential Revision: https://secure.phabricator.com/D16987
2016-12-05 19:25:18 +01:00
|
|
|
$address->getAddress(),
|
|
|
|
PhabricatorTime::getNow() - $timespan);
|
2011-06-14 21:17:14 +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
|
|
|
public function save() {
|
|
|
|
$this->details['host'] = php_uname('n');
|
2013-02-10 00:01:57 +01:00
|
|
|
$this->details['user_agent'] = AphrontRequest::getHTTPHeader('User-Agent');
|
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
|
|
|
|
|
|
|
return parent::save();
|
|
|
|
}
|
|
|
|
|
2015-01-13 20:47:05 +01:00
|
|
|
protected function getConfiguration() {
|
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
|
|
|
return array(
|
|
|
|
self::CONFIG_SERIALIZATION => array(
|
|
|
|
'oldValue' => self::SERIALIZATION_JSON,
|
|
|
|
'newValue' => self::SERIALIZATION_JSON,
|
|
|
|
'details' => self::SERIALIZATION_JSON,
|
|
|
|
),
|
Generate expected schemata for User/People tables
Summary:
Ref T1191. Some notes here:
- Drops the old LDAP and OAuth info tables. These were migrated to the ExternalAccount table a very long time ago.
- Separates surplus/missing keys from other types of surplus/missing things. In the long run, my plan is to have only two notice levels:
- Error: something we can't fix (missing database, table, or column; overlong key).
- Warning: something we can fix (surplus anything, missing key, bad column type, bad key columns, bad uniqueness, bad collation or charset).
- For now, retaining three levels is helpful in generating all the expected scheamta.
Test Plan:
- Saw ~200 issues resolve, leaving ~1,300.
- Grepped for removed tables.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1191
Differential Revision: https://secure.phabricator.com/D10580
2014-10-01 16:36:47 +02:00
|
|
|
self::CONFIG_COLUMN_SCHEMA => array(
|
|
|
|
'actorPHID' => 'phid?',
|
|
|
|
'action' => 'text64',
|
|
|
|
'remoteAddr' => 'text64',
|
Upgrade sessions digests to HMAC256, retaining compatibility with old digests
Summary:
Ref T13222. Ref T13225. We store a digest of the session key in the session table (not the session key itself) so that users with access to this table can't easily steal sessions by just setting their cookies to values from the table.
Users with access to the database can //probably// do plenty of other bad stuff (e.g., T13134 mentions digesting Conduit tokens) but there's very little cost to storing digests instead of live tokens.
We currently digest session keys with HMAC-SHA1. This is fine, but HMAC-SHA256 is better. Upgrade:
- Always write new digests.
- We still match sessions with either digest.
- When we read a session with an old digest, upgrade it to a new digest.
In a few months we can throw away the old code. When we do, installs that skip upgrades for a long time may suffer a one-time logout, but I'll note this in the changelog.
We could avoid this by storing `hmac256(hmac1(key))` instead and re-hashing in a migration, but I think the cost of a one-time logout for some tiny subset of users is very low, and worth keeping things simpler in the long run.
Test Plan:
- Hit a page with an old session, got a session upgrade.
- Reviewed sessions in Settings.
- Reviewed user logs.
- Logged out.
- Logged in.
- Terminated other sessions individually.
- Terminated all other sessions.
- Spot checked session table for general sanity.
Reviewers: amckinley
Reviewed By: amckinley
Subscribers: PHID-OPKG-gm6ozazyms6q6i22gyam
Maniphest Tasks: T13225, T13222
Differential Revision: https://secure.phabricator.com/D19883
2018-12-13 19:52:54 +01:00
|
|
|
'session' => 'text64?',
|
Generate expected schemata for User/People tables
Summary:
Ref T1191. Some notes here:
- Drops the old LDAP and OAuth info tables. These were migrated to the ExternalAccount table a very long time ago.
- Separates surplus/missing keys from other types of surplus/missing things. In the long run, my plan is to have only two notice levels:
- Error: something we can't fix (missing database, table, or column; overlong key).
- Warning: something we can fix (surplus anything, missing key, bad column type, bad key columns, bad uniqueness, bad collation or charset).
- For now, retaining three levels is helpful in generating all the expected scheamta.
Test Plan:
- Saw ~200 issues resolve, leaving ~1,300.
- Grepped for removed tables.
Reviewers: btrahan
Reviewed By: btrahan
Subscribers: epriestley
Maniphest Tasks: T1191
Differential Revision: https://secure.phabricator.com/D10580
2014-10-01 16:36:47 +02:00
|
|
|
),
|
|
|
|
self::CONFIG_KEY_SCHEMA => array(
|
|
|
|
'actorPHID' => array(
|
|
|
|
'columns' => array('actorPHID', 'dateCreated'),
|
|
|
|
),
|
|
|
|
'userPHID' => array(
|
|
|
|
'columns' => array('userPHID', 'dateCreated'),
|
|
|
|
),
|
|
|
|
'action' => array(
|
|
|
|
'columns' => array('action', 'dateCreated'),
|
|
|
|
),
|
|
|
|
'dateCreated' => array(
|
|
|
|
'columns' => array('dateCreated'),
|
|
|
|
),
|
|
|
|
'remoteAddr' => array(
|
|
|
|
'columns' => array('remoteAddr', 'dateCreated'),
|
|
|
|
),
|
|
|
|
'session' => array(
|
|
|
|
'columns' => array('session', 'dateCreated'),
|
|
|
|
),
|
|
|
|
),
|
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
|
|
|
) + parent::getConfiguration();
|
|
|
|
}
|
|
|
|
|
2014-04-28 02:31:35 +02:00
|
|
|
|
|
|
|
/* -( PhabricatorPolicyInterface )----------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
public function getCapabilities() {
|
|
|
|
return array(
|
|
|
|
PhabricatorPolicyCapability::CAN_VIEW,
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getPolicy($capability) {
|
|
|
|
switch ($capability) {
|
|
|
|
case PhabricatorPolicyCapability::CAN_VIEW:
|
|
|
|
return PhabricatorPolicies::POLICY_NOONE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
public function hasAutomaticCapability($capability, PhabricatorUser $viewer) {
|
|
|
|
if ($viewer->getIsAdmin()) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
$viewer_phid = $viewer->getPHID();
|
|
|
|
if ($viewer_phid) {
|
|
|
|
$user_phid = $this->getUserPHID();
|
|
|
|
if ($viewer_phid == $user_phid) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
$actor_phid = $this->getActorPHID();
|
|
|
|
if ($viewer_phid == $actor_phid) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function describeAutomaticCapability($capability) {
|
|
|
|
return array(
|
|
|
|
pht('Users can view their activity and activity that affects them.'),
|
|
|
|
pht('Administrators can always view all activity.'),
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|