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',
|
|
|
|
'session' => 'bytes40?',
|
|
|
|
),
|
|
|
|
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
|
|
|
}
|