2011-01-16 13:51:39 -08:00
|
|
|
<?php
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @group aphront
|
|
|
|
*/
|
|
|
|
abstract class AphrontResponse {
|
|
|
|
|
|
|
|
private $request;
|
2011-01-27 11:35:04 -08:00
|
|
|
private $cacheable = false;
|
2011-01-30 08:44:28 -08:00
|
|
|
private $responseCode = 200;
|
2011-05-09 01:10:40 -07:00
|
|
|
private $lastModified = null;
|
2011-01-16 13:51:39 -08:00
|
|
|
|
2011-09-13 16:38:28 -07:00
|
|
|
protected $frameable;
|
|
|
|
|
2011-01-16 13:51:39 -08:00
|
|
|
public function setRequest($request) {
|
|
|
|
$this->request = $request;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getRequest() {
|
|
|
|
return $this->request;
|
|
|
|
}
|
|
|
|
|
|
|
|
public function getHeaders() {
|
2011-09-13 16:38:28 -07:00
|
|
|
$headers = array();
|
|
|
|
if (!$this->frameable) {
|
|
|
|
$headers[] = array('X-Frame-Options', 'Deny');
|
|
|
|
}
|
|
|
|
|
|
|
|
return $headers;
|
2011-01-16 13:51:39 -08:00
|
|
|
}
|
2011-01-30 09:15:01 -08:00
|
|
|
|
2011-01-27 11:35:04 -08:00
|
|
|
public function setCacheDurationInSeconds($duration) {
|
|
|
|
$this->cacheable = $duration;
|
|
|
|
return $this;
|
|
|
|
}
|
2011-01-30 09:15:01 -08:00
|
|
|
|
2011-05-09 01:10:40 -07:00
|
|
|
public function setLastModified($epoch_timestamp) {
|
|
|
|
$this->lastModified = $epoch_timestamp;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2011-01-30 08:44:28 -08:00
|
|
|
public function setHTTPResponseCode($code) {
|
|
|
|
$this->responseCode = $code;
|
|
|
|
return $this;
|
|
|
|
}
|
2011-01-30 09:15:01 -08:00
|
|
|
|
2011-01-30 08:44:28 -08:00
|
|
|
public function getHTTPResponseCode() {
|
|
|
|
return $this->responseCode;
|
|
|
|
}
|
2011-01-16 13:51:39 -08:00
|
|
|
|
2011-09-13 16:38:28 -07:00
|
|
|
public function setFrameable($frameable) {
|
|
|
|
$this->frameable = $frameable;
|
|
|
|
return $this;
|
|
|
|
}
|
|
|
|
|
2013-01-28 18:11:27 -08:00
|
|
|
public static function processValueForJSONEncoding(&$value, $key) {
|
|
|
|
if ($value instanceof PhutilSafeHTML) {
|
|
|
|
// TODO: Javelin supports implicity conversion of '__html' objects to
|
|
|
|
// JX.HTML, but only for Ajax responses, not behaviors. Just leave things
|
|
|
|
// as they are for now (where behaviors treat responses as HTML or plain
|
|
|
|
// text at their discretion).
|
|
|
|
$value = $value->getHTMLContent();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
public static function encodeJSONForHTTPResponse(array $object) {
|
|
|
|
|
|
|
|
array_walk_recursive(
|
|
|
|
$object,
|
|
|
|
array('AphrontResponse', 'processValueForJSONEncoding'));
|
2012-02-14 14:51:51 -08:00
|
|
|
|
|
|
|
$response = json_encode($object);
|
|
|
|
|
|
|
|
// Prevent content sniffing attacks by encoding "<" and ">", so browsers
|
|
|
|
// won't try to execute the document as HTML even if they ignore
|
|
|
|
// Content-Type and X-Content-Type-Options. See T865.
|
|
|
|
$response = str_replace(
|
|
|
|
array('<', '>'),
|
|
|
|
array('\u003c', '\u003e'),
|
|
|
|
$response);
|
|
|
|
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-03 16:21:40 -08:00
|
|
|
return $response;
|
|
|
|
}
|
|
|
|
|
2012-08-13 16:05:56 -07:00
|
|
|
protected function addJSONShield($json_response) {
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-03 16:21:40 -08:00
|
|
|
|
2012-02-14 14:51:51 -08:00
|
|
|
// Add a shield to prevent "JSON Hijacking" attacks where an attacker
|
|
|
|
// requests a JSON response using a normal <script /> tag and then uses
|
|
|
|
// Object.prototype.__defineSetter__() or similar to read response data.
|
|
|
|
// This header causes the browser to loop infinitely instead of handing over
|
|
|
|
// sensitive data.
|
|
|
|
|
2012-08-13 16:05:56 -07:00
|
|
|
$shield = 'for (;;);';
|
2012-02-14 14:51:51 -08:00
|
|
|
|
OAuth - Phabricator OAuth server and Phabricator client for new Phabricator OAuth Server
Summary:
adds a Phabricator OAuth server, which has three big commands:
- auth - allows $user to authorize a given client or application. if $user has already authorized, it hands an authoization code back to $redirect_uri
- token - given a valid authorization code, this command returns an authorization token
- whoami - Conduit.whoami, all nice and purdy relative to the oauth server.
Also has a "test" handler, which I used to create some test data. T850 will
delete this as it adds the ability to create this data in the Phabricator
product.
This diff also adds the corresponding client in Phabricator for the Phabricator
OAuth Server. (Note that clients are known as "providers" in the Phabricator
codebase but client makes more sense relative to the server nomenclature)
Also, related to make this work well
- clean up the diagnostics page by variabilizing the provider-specific
information and extending the provider classes as appropriate.
- augment Conduit.whoami for more full-featured OAuth support, at least where
the Phabricator client is concerned
What's missing here... See T844, T848, T849, T850, and T852.
Test Plan:
- created a dummy client via the test handler. setup development.conf to have
have proper variables for this dummy client. went through authorization and
de-authorization flows
- viewed the diagnostics page for all known oauth providers and saw
provider-specific debugging information
Reviewers: epriestley
CC: aran, epriestley
Maniphest Tasks: T44, T797
Differential Revision: https://secure.phabricator.com/D1595
2012-02-03 16:21:40 -08:00
|
|
|
$response = $shield.$json_response;
|
2012-02-14 14:51:51 -08:00
|
|
|
|
|
|
|
return $response;
|
|
|
|
}
|
|
|
|
|
2011-01-16 13:51:39 -08:00
|
|
|
public function getCacheHeaders() {
|
2011-05-09 01:10:40 -07:00
|
|
|
$headers = array();
|
2011-01-27 11:35:04 -08:00
|
|
|
if ($this->cacheable) {
|
2011-05-09 01:10:40 -07:00
|
|
|
$headers[] = array(
|
|
|
|
'Expires',
|
|
|
|
$this->formatEpochTimestampForHTTPHeader(time() + $this->cacheable));
|
2011-01-27 11:35:04 -08:00
|
|
|
} else {
|
2011-05-09 01:10:40 -07:00
|
|
|
$headers[] = array(
|
|
|
|
'Cache-Control',
|
|
|
|
'private, no-cache, no-store, must-revalidate');
|
OAuthServer polish and random sauce
Summary:
This diff makes the OAuthServer more compliant with the spec by
- making it return well-formatted error codes with error types from the spec.
- making it respect the "state" variable, which is a transparent variable the
client passes and the server passes back
- making it be super, duper compliant with respect to redirect uris
-- if specified in authorization step, check if its valid relative to the client
registered URI and if so save it
-- if specified in authorization step, check if its been specified in the access
step and error if it doesn't match or doesn't exist
-- note we don't make any use of it in the access step which seems strange but
hey, that's what the spec says!
This diff makes the OAuthServer suck less by
- making the "cancel" button do something in the user authorization flow
- making the client list view and client edit view be a bit more usable around
client secrets
- fixing a few bugs I managed to introduce along the way
Test Plan:
- create a test phabricator client, updated my conf, and then linked and
unlinked phabricator to itself
- wrote some tests for PhabricatorOAuthServer -- they pass!
-- these validate the various validate URI checks
- tried a few important authorization calls
--
http://phabricator.dev/oauthserver/auth/?client_id=X&state=test&redirect_uri=http://www.evil.com
--- verified error'd from mismatching redirect uri's
--- verified state parameter in response
--- verified did not redirect to client redirect uri
-- http://phabricator.dev/oauthserver/auth/?client_id=X w/ existing
authorization
--- got redirected to proper client url with error that response_type not
specified
-- http://phabricator.dev/oauthserver/auth/?client_id=X&response_type=code w/
existing authorization
--- got redirected to proper client url with pertinent code!
- tried a few important access calls
-- verified appropriate errors if missing any required parameters
-- verified good access code with appropriate other variables resulted in an
access token
- verified that if redirect_uri set correctly in authorization required for
access and errors if differs at all / only succeeds if exactly the same
Reviewers: epriestley
Reviewed By: epriestley
CC: aran, epriestley, ajtrichards
Maniphest Tasks: T889, T906, T897
Differential Revision: https://secure.phabricator.com/D1727
2012-03-01 14:46:18 -08:00
|
|
|
$headers[] = array(
|
|
|
|
'Pragma',
|
|
|
|
'no-cache');
|
2011-05-09 01:10:40 -07:00
|
|
|
$headers[] = array(
|
|
|
|
'Expires',
|
|
|
|
'Sat, 01 Jan 2000 00:00:00 GMT');
|
|
|
|
}
|
|
|
|
|
|
|
|
if ($this->lastModified) {
|
|
|
|
$headers[] = array(
|
|
|
|
'Last-Modified',
|
|
|
|
$this->formatEpochTimestampForHTTPHeader($this->lastModified));
|
2011-01-27 11:35:04 -08:00
|
|
|
}
|
2011-05-09 01:10:40 -07:00
|
|
|
|
2012-01-16 16:54:05 -08:00
|
|
|
// IE has a feature where it may override an explicit Content-Type
|
|
|
|
// declaration by inferring a content type. This can be a security risk
|
|
|
|
// and we always explicitly transmit the correct Content-Type header, so
|
2012-02-14 14:51:51 -08:00
|
|
|
// prevent IE from using inferred content types. This only offers protection
|
|
|
|
// on recent versions of IE; IE6/7 and Opera currently ignore this header.
|
2012-01-16 16:54:05 -08:00
|
|
|
$headers[] = array('X-Content-Type-Options', 'nosniff');
|
2012-01-15 11:06:13 -08:00
|
|
|
|
2011-05-09 01:10:40 -07:00
|
|
|
return $headers;
|
|
|
|
}
|
|
|
|
|
|
|
|
private function formatEpochTimestampForHTTPHeader($epoch_timestamp) {
|
|
|
|
return gmdate('D, d M Y H:i:s', $epoch_timestamp).' GMT';
|
2011-01-16 13:51:39 -08:00
|
|
|
}
|
|
|
|
|
|
|
|
abstract public function buildResponseString();
|
|
|
|
|
|
|
|
}
|