2011-01-16 22:51:39 +01:00
|
|
|
<?php
|
|
|
|
|
|
|
|
/*
|
2012-01-04 06:57:45 +01:00
|
|
|
* Copyright 2012 Facebook, Inc.
|
2011-01-16 22:51:39 +01:00
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
2012-01-04 06:57:45 +01:00
|
|
|
*
|
|
|
|
* @task data Accessing Request Data
|
|
|
|
*
|
2011-01-16 22:51:39 +01:00
|
|
|
* @group aphront
|
|
|
|
*/
|
2012-03-13 19:18:11 +01:00
|
|
|
final class AphrontRequest {
|
2011-01-16 22:51:39 +01:00
|
|
|
|
|
|
|
const TYPE_AJAX = '__ajax__';
|
|
|
|
const TYPE_FORM = '__form__';
|
2012-01-15 20:06:13 +01:00
|
|
|
const TYPE_CONDUIT = '__conduit__';
|
2011-01-16 22:51:39 +01:00
|
|
|
|
|
|
|
private $host;
|
|
|
|
private $path;
|
|
|
|
private $requestData;
|
2011-01-26 22:21:12 +01:00
|
|
|
private $user;
|
2011-01-31 20:55:26 +01:00
|
|
|
private $env;
|
2011-02-02 22:48:52 +01:00
|
|
|
private $applicationConfiguration;
|
2011-01-31 20:55:26 +01:00
|
|
|
|
2011-02-02 22:48:52 +01:00
|
|
|
final public function __construct($host, $path) {
|
|
|
|
$this->host = $host;
|
|
|
|
$this->path = $path;
|
2011-01-31 20:55:26 +01:00
|
|
|
}
|
|
|
|
|
2011-02-02 22:48:52 +01:00
|
|
|
final public function setApplicationConfiguration(
|
|
|
|
$application_configuration) {
|
|
|
|
$this->applicationConfiguration = $application_configuration;
|
|
|
|
return $this;
|
2011-01-31 20:55:26 +01:00
|
|
|
}
|
2011-01-16 22:51:39 +01:00
|
|
|
|
2011-02-02 22:48:52 +01:00
|
|
|
final public function getApplicationConfiguration() {
|
|
|
|
return $this->applicationConfiguration;
|
2011-01-16 22:51:39 +01:00
|
|
|
}
|
|
|
|
|
2012-01-04 06:57:45 +01:00
|
|
|
final public function getPath() {
|
|
|
|
return $this->path;
|
|
|
|
}
|
|
|
|
|
|
|
|
final public function getHost() {
|
|
|
|
return $this->host;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* -( Accessing Request Data )--------------------------------------------- */
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @task data
|
|
|
|
*/
|
2011-01-16 22:51:39 +01:00
|
|
|
final public function setRequestData(array $request_data) {
|
|
|
|
$this->requestData = $request_data;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2012-01-04 06:57:45 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @task data
|
|
|
|
*/
|
2011-12-08 06:41:33 +01:00
|
|
|
final public function getRequestData() {
|
|
|
|
return $this->requestData;
|
|
|
|
}
|
|
|
|
|
2011-01-16 22:51:39 +01:00
|
|
|
|
2012-01-04 06:57:45 +01:00
|
|
|
/**
|
|
|
|
* @task data
|
|
|
|
*/
|
2011-01-16 22:51:39 +01:00
|
|
|
final public function getInt($name, $default = null) {
|
|
|
|
if (isset($this->requestData[$name])) {
|
|
|
|
return (int)$this->requestData[$name];
|
|
|
|
} else {
|
|
|
|
return $default;
|
Fix "reply" link in Differential
Summary:
Fixes the issue caused by rPa0af5b66437719dba6136579c051982ab275e6a0. Prior to
that patch, isCommentInNewFile() returned $comment->getIsNewFile(). While this
was often the wrong value, it came from the database and was the integer 1 if
true.
After the patch, the function returns 'true' as a boolean, which is passed to JS
and then back to PHP, interpreted as an integer, and evaluates to 0.
To avoid this issue in general, provide an isBool() method on AphrontRequest
which interprets this correctly.
I will also revert the revert of rPa0af5b66437719dba6136579c051982ab275e6a0 when
I land this.
Test Plan:
Clicked "reply" on the right hand side of a diff, got a right-hand-side inline
comment.
Reviewed By: rm
Reviewers: tuomaspelkonen, jungejason, aran, rm
CC: simpkins, aran, epriestley, rm
Differential Revision: 250
2011-05-07 19:42:40 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-04 06:57:45 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @task data
|
|
|
|
*/
|
Fix "reply" link in Differential
Summary:
Fixes the issue caused by rPa0af5b66437719dba6136579c051982ab275e6a0. Prior to
that patch, isCommentInNewFile() returned $comment->getIsNewFile(). While this
was often the wrong value, it came from the database and was the integer 1 if
true.
After the patch, the function returns 'true' as a boolean, which is passed to JS
and then back to PHP, interpreted as an integer, and evaluates to 0.
To avoid this issue in general, provide an isBool() method on AphrontRequest
which interprets this correctly.
I will also revert the revert of rPa0af5b66437719dba6136579c051982ab275e6a0 when
I land this.
Test Plan:
Clicked "reply" on the right hand side of a diff, got a right-hand-side inline
comment.
Reviewed By: rm
Reviewers: tuomaspelkonen, jungejason, aran, rm
CC: simpkins, aran, epriestley, rm
Differential Revision: 250
2011-05-07 19:42:40 +02:00
|
|
|
final public function getBool($name, $default = null) {
|
|
|
|
if (isset($this->requestData[$name])) {
|
|
|
|
if ($this->requestData[$name] === 'true') {
|
|
|
|
return true;
|
|
|
|
} else if ($this->requestData[$name] === 'false') {
|
|
|
|
return false;
|
|
|
|
} else {
|
|
|
|
return (bool)$this->requestData[$name];
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
return $default;
|
2011-01-16 22:51:39 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-04 06:57:45 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @task data
|
|
|
|
*/
|
2011-01-16 22:51:39 +01:00
|
|
|
final public function getStr($name, $default = null) {
|
|
|
|
if (isset($this->requestData[$name])) {
|
2011-02-05 21:20:18 +01:00
|
|
|
$str = (string)$this->requestData[$name];
|
|
|
|
// Normalize newline craziness.
|
|
|
|
$str = str_replace(
|
|
|
|
array("\r\n", "\r"),
|
|
|
|
array("\n", "\n"),
|
|
|
|
$str);
|
|
|
|
return $str;
|
2011-01-16 22:51:39 +01:00
|
|
|
} else {
|
|
|
|
return $default;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-04 06:57:45 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @task data
|
|
|
|
*/
|
2011-01-26 02:40:21 +01:00
|
|
|
final public function getArr($name, $default = array()) {
|
2011-01-16 22:51:39 +01:00
|
|
|
if (isset($this->requestData[$name]) &&
|
|
|
|
is_array($this->requestData[$name])) {
|
|
|
|
return $this->requestData[$name];
|
|
|
|
} else {
|
|
|
|
return $default;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-04 06:57:45 +01:00
|
|
|
|
|
|
|
/**
|
|
|
|
* @task data
|
|
|
|
*/
|
|
|
|
final public function getStrList($name, $default = array()) {
|
|
|
|
if (!isset($this->requestData[$name])) {
|
|
|
|
return $default;
|
|
|
|
}
|
|
|
|
$list = $this->getStr($name);
|
|
|
|
$list = preg_split('/[,\n]/', $list);
|
|
|
|
$list = array_map('trim', $list);
|
|
|
|
$list = array_filter($list, 'strlen');
|
|
|
|
$list = array_values($list);
|
|
|
|
return $list;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @task data
|
|
|
|
*/
|
2011-01-16 22:51:39 +01:00
|
|
|
final public function getExists($name) {
|
|
|
|
return array_key_exists($name, $this->requestData);
|
|
|
|
}
|
|
|
|
|
|
|
|
final public function isHTTPPost() {
|
|
|
|
return ($_SERVER['REQUEST_METHOD'] == 'POST');
|
|
|
|
}
|
|
|
|
|
|
|
|
final public function isAjax() {
|
|
|
|
return $this->getExists(self::TYPE_AJAX);
|
|
|
|
}
|
|
|
|
|
2012-01-15 20:06:13 +01:00
|
|
|
final public function isConduit() {
|
|
|
|
return $this->getExists(self::TYPE_CONDUIT);
|
|
|
|
}
|
|
|
|
|
Prevent CSRF uploads via /file/dropupload/
Summary:
We don't currently validate CSRF tokens on this workflow. This allows an
attacker to upload arbitrary files on the user's behalf. Although I believe the
tight list of servable mime-types means that's more or less the end of the
attack, this is still a vulnerability.
In the long term, the right solution is probably to pass CSRF tokens on all Ajax
requests in an HTTP header (or just a GET param) or something like that.
However, this endpoint is unique and this is the quickest and most direct way to
close the hole.
Test Plan:
- Drop-uploaded files to Files, Maniphest, Phriction and Differential.
- Modified CSRF vaidator to use __csrf__.'x' and verified uploads and form
submissions don't work.
Reviewers: andrewjcg, aran, jungejason, tuomaspelkonen, erling
Commenters: andrewjcg, pedram
CC: aran, epriestley, andrewjcg, pedram
Differential Revision: 758
2011-08-02 05:23:01 +02:00
|
|
|
public static function getCSRFTokenName() {
|
|
|
|
return '__csrf__';
|
|
|
|
}
|
Fix conservative CSRF token cycling limit
Summary:
We currently cycle CSRF tokens every hour and check for the last two valid ones.
This means that a form could go stale in as little as an hour, and is certainly
stale after two.
When a stale form is submitted, you basically get a terrible heisen-state where
some of your data might persist if you're lucky but more likely it all just
vanishes. The .js file below outlines some more details.
This is a pretty terrible UX and we don't need to be as conservative about CSRF
validation as we're being. Remedy this problem by:
- Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are
valid for at least 6 hours, and for as long as 7).
- Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected
to the internet are valid indefinitely).
- Showing the user an explicit message about what went wrong when CSRF
validation fails so the experience is less bewildering.
They should now only be able to submit with a bad CSRF token if:
- They load a page, disconnect from the internet for 7 hours, reconnect, and
submit the form within 55 minutes; or
- They are actually the victim of a CSRF attack.
We could eventually fix the first one by tracking reconnects, which might be
"free" once the notification server gets built. It will probably never be an
issue in practice.
Test Plan:
- Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15
seconds, got the CSRF exception.
- Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15
seconds, got a clean form post.
- Added debugging code the the csrf refresh to make sure it was doing sensible
things (pulling different tokens, finding all the inputs).
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: aran, epriestley
Differential Revision: 660
2011-07-13 23:05:18 +02:00
|
|
|
|
Prevent CSRF uploads via /file/dropupload/
Summary:
We don't currently validate CSRF tokens on this workflow. This allows an
attacker to upload arbitrary files on the user's behalf. Although I believe the
tight list of servable mime-types means that's more or less the end of the
attack, this is still a vulnerability.
In the long term, the right solution is probably to pass CSRF tokens on all Ajax
requests in an HTTP header (or just a GET param) or something like that.
However, this endpoint is unique and this is the quickest and most direct way to
close the hole.
Test Plan:
- Drop-uploaded files to Files, Maniphest, Phriction and Differential.
- Modified CSRF vaidator to use __csrf__.'x' and verified uploads and form
submissions don't work.
Reviewers: andrewjcg, aran, jungejason, tuomaspelkonen, erling
Commenters: andrewjcg, pedram
CC: aran, epriestley, andrewjcg, pedram
Differential Revision: 758
2011-08-02 05:23:01 +02:00
|
|
|
public static function getCSRFHeaderName() {
|
|
|
|
return 'X-Phabricator-Csrf';
|
|
|
|
}
|
|
|
|
|
|
|
|
final public function validateCSRF() {
|
|
|
|
$token_name = self::getCSRFTokenName();
|
|
|
|
$token = $this->getStr($token_name);
|
|
|
|
|
|
|
|
// No token in the request, check the HTTP header which is added for Ajax
|
|
|
|
// requests.
|
|
|
|
if (empty($token)) {
|
|
|
|
|
|
|
|
// PHP mangles HTTP headers by uppercasing them and replacing hyphens with
|
|
|
|
// underscores, then prepending 'HTTP_'.
|
|
|
|
$php_index = self::getCSRFHeaderName();
|
|
|
|
$php_index = strtoupper($php_index);
|
|
|
|
$php_index = str_replace('-', '_', $php_index);
|
|
|
|
$php_index = 'HTTP_'.$php_index;
|
|
|
|
|
|
|
|
$token = idx($_SERVER, $php_index);
|
Fix conservative CSRF token cycling limit
Summary:
We currently cycle CSRF tokens every hour and check for the last two valid ones.
This means that a form could go stale in as little as an hour, and is certainly
stale after two.
When a stale form is submitted, you basically get a terrible heisen-state where
some of your data might persist if you're lucky but more likely it all just
vanishes. The .js file below outlines some more details.
This is a pretty terrible UX and we don't need to be as conservative about CSRF
validation as we're being. Remedy this problem by:
- Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are
valid for at least 6 hours, and for as long as 7).
- Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected
to the internet are valid indefinitely).
- Showing the user an explicit message about what went wrong when CSRF
validation fails so the experience is less bewildering.
They should now only be able to submit with a bad CSRF token if:
- They load a page, disconnect from the internet for 7 hours, reconnect, and
submit the form within 55 minutes; or
- They are actually the victim of a CSRF attack.
We could eventually fix the first one by tracking reconnects, which might be
"free" once the notification server gets built. It will probably never be an
issue in practice.
Test Plan:
- Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15
seconds, got the CSRF exception.
- Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15
seconds, got a clean form post.
- Added debugging code the the csrf refresh to make sure it was doing sensible
things (pulling different tokens, finding all the inputs).
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: aran, epriestley
Differential Revision: 660
2011-07-13 23:05:18 +02:00
|
|
|
}
|
|
|
|
|
Prevent CSRF uploads via /file/dropupload/
Summary:
We don't currently validate CSRF tokens on this workflow. This allows an
attacker to upload arbitrary files on the user's behalf. Although I believe the
tight list of servable mime-types means that's more or less the end of the
attack, this is still a vulnerability.
In the long term, the right solution is probably to pass CSRF tokens on all Ajax
requests in an HTTP header (or just a GET param) or something like that.
However, this endpoint is unique and this is the quickest and most direct way to
close the hole.
Test Plan:
- Drop-uploaded files to Files, Maniphest, Phriction and Differential.
- Modified CSRF vaidator to use __csrf__.'x' and verified uploads and form
submissions don't work.
Reviewers: andrewjcg, aran, jungejason, tuomaspelkonen, erling
Commenters: andrewjcg, pedram
CC: aran, epriestley, andrewjcg, pedram
Differential Revision: 758
2011-08-02 05:23:01 +02:00
|
|
|
$valid = $this->getUser()->validateCSRFToken($token);
|
Fix conservative CSRF token cycling limit
Summary:
We currently cycle CSRF tokens every hour and check for the last two valid ones.
This means that a form could go stale in as little as an hour, and is certainly
stale after two.
When a stale form is submitted, you basically get a terrible heisen-state where
some of your data might persist if you're lucky but more likely it all just
vanishes. The .js file below outlines some more details.
This is a pretty terrible UX and we don't need to be as conservative about CSRF
validation as we're being. Remedy this problem by:
- Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are
valid for at least 6 hours, and for as long as 7).
- Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected
to the internet are valid indefinitely).
- Showing the user an explicit message about what went wrong when CSRF
validation fails so the experience is less bewildering.
They should now only be able to submit with a bad CSRF token if:
- They load a page, disconnect from the internet for 7 hours, reconnect, and
submit the form within 55 minutes; or
- They are actually the victim of a CSRF attack.
We could eventually fix the first one by tracking reconnects, which might be
"free" once the notification server gets built. It will probably never be an
issue in practice.
Test Plan:
- Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15
seconds, got the CSRF exception.
- Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15
seconds, got a clean form post.
- Added debugging code the the csrf refresh to make sure it was doing sensible
things (pulling different tokens, finding all the inputs).
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: aran, epriestley
Differential Revision: 660
2011-07-13 23:05:18 +02:00
|
|
|
if (!$valid) {
|
2011-09-01 18:29:33 +02:00
|
|
|
|
|
|
|
// Add some diagnostic details so we can figure out if some CSRF issues
|
|
|
|
// are JS problems or people accessing Ajax URIs directly with their
|
|
|
|
// browsers.
|
|
|
|
if ($token) {
|
|
|
|
$token_info = "with an invalid CSRF token";
|
|
|
|
} else {
|
|
|
|
$token_info = "without a CSRF token";
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($this->isAjax()) {
|
|
|
|
$more_info = "(This was an Ajax request, {$token_info}.)";
|
|
|
|
} else {
|
|
|
|
$more_info = "(This was a web request, {$token_info}.)";
|
|
|
|
}
|
|
|
|
|
Fix conservative CSRF token cycling limit
Summary:
We currently cycle CSRF tokens every hour and check for the last two valid ones.
This means that a form could go stale in as little as an hour, and is certainly
stale after two.
When a stale form is submitted, you basically get a terrible heisen-state where
some of your data might persist if you're lucky but more likely it all just
vanishes. The .js file below outlines some more details.
This is a pretty terrible UX and we don't need to be as conservative about CSRF
validation as we're being. Remedy this problem by:
- Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are
valid for at least 6 hours, and for as long as 7).
- Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected
to the internet are valid indefinitely).
- Showing the user an explicit message about what went wrong when CSRF
validation fails so the experience is less bewildering.
They should now only be able to submit with a bad CSRF token if:
- They load a page, disconnect from the internet for 7 hours, reconnect, and
submit the form within 55 minutes; or
- They are actually the victim of a CSRF attack.
We could eventually fix the first one by tracking reconnects, which might be
"free" once the notification server gets built. It will probably never be an
issue in practice.
Test Plan:
- Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15
seconds, got the CSRF exception.
- Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15
seconds, got a clean form post.
- Added debugging code the the csrf refresh to make sure it was doing sensible
things (pulling different tokens, finding all the inputs).
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: aran, epriestley
Differential Revision: 660
2011-07-13 23:05:18 +02:00
|
|
|
// This should only be able to happen if you load a form, pull your
|
|
|
|
// internet for 6 hours, and then reconnect and immediately submit,
|
|
|
|
// but give the user some indication of what happened since the workflow
|
|
|
|
// is incredibly confusing otherwise.
|
|
|
|
throw new AphrontCSRFException(
|
|
|
|
"The form you just submitted did not include a valid CSRF token. ".
|
|
|
|
"This token is a technical security measure which prevents a ".
|
|
|
|
"certain type of login hijacking attack. However, the token can ".
|
|
|
|
"become invalid if you leave a page open for more than six hours ".
|
|
|
|
"without a connection to the internet. To fix this problem: reload ".
|
2011-09-01 18:29:33 +02:00
|
|
|
"the page, and then resubmit it.\n\n".
|
|
|
|
$more_info);
|
Fix conservative CSRF token cycling limit
Summary:
We currently cycle CSRF tokens every hour and check for the last two valid ones.
This means that a form could go stale in as little as an hour, and is certainly
stale after two.
When a stale form is submitted, you basically get a terrible heisen-state where
some of your data might persist if you're lucky but more likely it all just
vanishes. The .js file below outlines some more details.
This is a pretty terrible UX and we don't need to be as conservative about CSRF
validation as we're being. Remedy this problem by:
- Accepting the last 6 CSRF tokens instead of the last 1 (i.e., pages are
valid for at least 6 hours, and for as long as 7).
- Using JS to refresh the CSRF token every 55 minutes (i.e., pages connected
to the internet are valid indefinitely).
- Showing the user an explicit message about what went wrong when CSRF
validation fails so the experience is less bewildering.
They should now only be able to submit with a bad CSRF token if:
- They load a page, disconnect from the internet for 7 hours, reconnect, and
submit the form within 55 minutes; or
- They are actually the victim of a CSRF attack.
We could eventually fix the first one by tracking reconnects, which might be
"free" once the notification server gets built. It will probably never be an
issue in practice.
Test Plan:
- Reduced CSRF cycle frequency to 2 seconds, submitted a form after 15
seconds, got the CSRF exception.
- Reduced csrf-refresh cycle frequency to 3 seconds, submitted a form after 15
seconds, got a clean form post.
- Added debugging code the the csrf refresh to make sure it was doing sensible
things (pulling different tokens, finding all the inputs).
Reviewed By: aran
Reviewers: tuomaspelkonen, jungejason, aran
CC: aran, epriestley
Differential Revision: 660
2011-07-13 23:05:18 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
2011-01-16 22:51:39 +01:00
|
|
|
}
|
|
|
|
|
Prevent CSRF uploads via /file/dropupload/
Summary:
We don't currently validate CSRF tokens on this workflow. This allows an
attacker to upload arbitrary files on the user's behalf. Although I believe the
tight list of servable mime-types means that's more or less the end of the
attack, this is still a vulnerability.
In the long term, the right solution is probably to pass CSRF tokens on all Ajax
requests in an HTTP header (or just a GET param) or something like that.
However, this endpoint is unique and this is the quickest and most direct way to
close the hole.
Test Plan:
- Drop-uploaded files to Files, Maniphest, Phriction and Differential.
- Modified CSRF vaidator to use __csrf__.'x' and verified uploads and form
submissions don't work.
Reviewers: andrewjcg, aran, jungejason, tuomaspelkonen, erling
Commenters: andrewjcg, pedram
CC: aran, epriestley, andrewjcg, pedram
Differential Revision: 758
2011-08-02 05:23:01 +02:00
|
|
|
final public function isFormPost() {
|
|
|
|
$post = $this->getExists(self::TYPE_FORM) &&
|
|
|
|
$this->isHTTPPost();
|
|
|
|
|
|
|
|
if (!$post) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return $this->validateCSRF();
|
|
|
|
}
|
|
|
|
|
2011-01-26 22:21:12 +01:00
|
|
|
final public function getCookie($name, $default = null) {
|
|
|
|
return idx($_COOKIE, $name, $default);
|
|
|
|
}
|
|
|
|
|
|
|
|
final public function clearCookie($name) {
|
|
|
|
$this->setCookie($name, '', time() - (60 * 60 * 24 * 30));
|
|
|
|
}
|
|
|
|
|
|
|
|
final public function setCookie($name, $value, $expire = null) {
|
Provide a setting which forces all file views to be served from an alternate
domain
Summary:
See D758, D759.
- Provide a strongly recommended setting which permits configuration of an
alternate domain.
- Lock cookies down better: set them on the exact domain, and use SSL-only if
the configuration is HTTPS.
- Prevent Phabriator from setting cookies on other domains.
This assumes D759 will land, it is not effective without that change.
Test Plan:
- Attempted to login from a different domain and was rejected.
- Logged out, logged back in normally.
- Put install in setup mode and verified it revealed a warning.
- Configured an alterate domain.
- Tried to view an image with an old URI, got a 400.
- Went to /files/ and verified links rendered to the alternate domain.
- Viewed an alternate domain file.
- Tried to view an alternate domain file without the secret key, got a 404.
Reviewers: andrewjcg, erling, aran, tuomaspelkonen, jungejason, codeblock
CC: aran
Differential Revision: 760
2011-08-02 07:24:00 +02:00
|
|
|
|
|
|
|
// Ensure cookies are only set on the configured domain.
|
|
|
|
|
|
|
|
$base_uri = PhabricatorEnv::getEnvConfig('phabricator.base-uri');
|
|
|
|
$base_uri = new PhutilURI($base_uri);
|
|
|
|
|
|
|
|
$base_domain = $base_uri->getDomain();
|
|
|
|
$base_protocol = $base_uri->getProtocol();
|
|
|
|
|
2011-08-20 22:55:17 +02:00
|
|
|
// The "Host" header may include a port number; if so, ignore it. We can't
|
|
|
|
// use PhutilURI since there's no URI scheme.
|
|
|
|
list($actual_host) = explode(':', $this->getHost(), 2);
|
Provide a setting which forces all file views to be served from an alternate
domain
Summary:
See D758, D759.
- Provide a strongly recommended setting which permits configuration of an
alternate domain.
- Lock cookies down better: set them on the exact domain, and use SSL-only if
the configuration is HTTPS.
- Prevent Phabriator from setting cookies on other domains.
This assumes D759 will land, it is not effective without that change.
Test Plan:
- Attempted to login from a different domain and was rejected.
- Logged out, logged back in normally.
- Put install in setup mode and verified it revealed a warning.
- Configured an alterate domain.
- Tried to view an image with an old URI, got a 400.
- Went to /files/ and verified links rendered to the alternate domain.
- Viewed an alternate domain file.
- Tried to view an alternate domain file without the secret key, got a 404.
Reviewers: andrewjcg, erling, aran, tuomaspelkonen, jungejason, codeblock
CC: aran
Differential Revision: 760
2011-08-02 07:24:00 +02:00
|
|
|
if ($base_domain != $actual_host) {
|
|
|
|
throw new Exception(
|
|
|
|
"This install of Phabricator is configured as '{$base_domain}' but ".
|
|
|
|
"you are accessing it via '{$actual_host}'. Access Phabricator via ".
|
|
|
|
"the primary configured domain.");
|
|
|
|
}
|
|
|
|
|
2011-01-26 22:21:12 +01:00
|
|
|
if ($expire === null) {
|
|
|
|
$expire = time() + (60 * 60 * 24 * 365 * 5);
|
|
|
|
}
|
Provide a setting which forces all file views to be served from an alternate
domain
Summary:
See D758, D759.
- Provide a strongly recommended setting which permits configuration of an
alternate domain.
- Lock cookies down better: set them on the exact domain, and use SSL-only if
the configuration is HTTPS.
- Prevent Phabriator from setting cookies on other domains.
This assumes D759 will land, it is not effective without that change.
Test Plan:
- Attempted to login from a different domain and was rejected.
- Logged out, logged back in normally.
- Put install in setup mode and verified it revealed a warning.
- Configured an alterate domain.
- Tried to view an image with an old URI, got a 400.
- Went to /files/ and verified links rendered to the alternate domain.
- Viewed an alternate domain file.
- Tried to view an alternate domain file without the secret key, got a 404.
Reviewers: andrewjcg, erling, aran, tuomaspelkonen, jungejason, codeblock
CC: aran
Differential Revision: 760
2011-08-02 07:24:00 +02:00
|
|
|
|
2011-08-31 01:41:18 +02:00
|
|
|
$is_secure = ($base_protocol == 'https');
|
|
|
|
|
|
|
|
setcookie(
|
|
|
|
$name,
|
|
|
|
$value,
|
|
|
|
$expire,
|
|
|
|
$path = '/',
|
|
|
|
$base_domain,
|
|
|
|
$is_secure,
|
|
|
|
$http_only = true);
|
2011-01-26 22:21:12 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
final public function setUser($user) {
|
|
|
|
$this->user = $user;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
final public function getUser() {
|
|
|
|
return $this->user;
|
|
|
|
}
|
|
|
|
|
2011-02-06 01:43:28 +01:00
|
|
|
final public function getRequestURI() {
|
|
|
|
$get = $_GET;
|
|
|
|
unset($get['__path__']);
|
|
|
|
return id(new PhutilURI($this->getPath()))->setQueryParams($get);
|
|
|
|
}
|
|
|
|
|
2011-02-06 07:36:21 +01:00
|
|
|
final public function isDialogFormPost() {
|
|
|
|
return $this->isFormPost() && $this->getStr('__dialog__');
|
|
|
|
}
|
|
|
|
|
Track content sources (email, web, conduit, mobile) for replies
Summary:
When an object is updated, record the content source for the update. This mostly
isn't terribly useful but one concrete thing I want to do with it is let admins
audit via-email replies more easily since there are a bunch of options which let
you do hyjinx if you intentionally configure them insecurely. I think having a
little more auditability around this feature is generally good. At some point
I'm going to turn this into a link admins can click to see details.
It also allows us to see how frequently different mechanisms are used, and lets
you see if someone is at their desk or on a mobile or whatever, at least
indirectly.
The "tablet" and "mobile" sources are currently unused but I figured I'd throw
them in anyway. SMS support should definitely happen at some point.
Not 100% sure about the design for this, I might change it to plain text at some
point.
Test Plan: Updated objects and saw update sources rendered.
Reviewers: jungejason, tuomaspelkonen, aran
Reviewed By: jungejason
CC: aran, epriestley, jungejason
Differential Revision: 844
2011-08-22 19:25:45 +02:00
|
|
|
final public function getRemoteAddr() {
|
|
|
|
return $_SERVER['REMOTE_ADDR'];
|
|
|
|
}
|
|
|
|
|
2011-01-16 22:51:39 +01:00
|
|
|
}
|