1
0
Fork 0
mirror of https://we.phorge.it/source/phorge.git synced 2024-11-14 10:52:41 +01:00
phorge-phorge/src/applications/oauthserver/server/PhabricatorOAuthServer.php

209 lines
5.9 KiB
PHP
Raw Normal View History

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-04 01:21:40 +01:00
<?php
/*
* Copyright 2012 Facebook, Inc.
*
* 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.
*/
/**
* Implements core OAuth 2.0 Server logic.
*
* This class should be used behind business logic that parses input to
* determine pertinent @{class:PhabricatorUser} $user,
* @{class:PhabricatorOAuthServerClient} $client(s),
* @{class:PhabricatorOAuthServerAuthorizationCode} $code(s), and.
* @{class:PhabricatorOAuthServerAccessToken} $token(s).
*
* For an OAuth 2.0 server, there are two main steps:
*
* 1) Authorization - the user authorizes a given client to access the data
* the OAuth 2.0 server protects. Once this is achieved / if it has
* been achived already, the OAuth server sends the client an authorization
* code.
* 2) Access Token - the client should send the authorization code received in
* step 1 along with its id and secret to the OAuth server to receive an
* access token. This access token can later be used to access Phabricator
* data on behalf of the user.
*
* @task auth Authorizing @{class:PhabricatorOAuthServerClient}s and
* generating @{class:PhabricatorOAuthServerAuthorizationCode}s
* @task token Validating @{class:PhabricatorOAuthServerAuthorizationCode}s
* and generating @{class:PhabricatorOAuthServerAccessToken}s
* @task internal Internals
*
* @group oauthserver
*/
final class PhabricatorOAuthServer {
const AUTHORIZATION_CODE_TIMEOUT = 300;
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
const ACCESS_TOKEN_TIMEOUT = 3600;
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-04 01:21:40 +01:00
private $user;
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
private $client;
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-04 01:21:40 +01:00
/**
* @group internal
*/
private function getUser() {
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
if (!$this->user) {
throw new Exception('You must setUser before you can getUser!');
}
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-04 01:21:40 +01:00
return $this->user;
}
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
public function setUser(PhabricatorUser $user) {
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-04 01:21:40 +01:00
$this->user = $user;
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
return $this;
}
/**
* @group internal
*/
private function getClient() {
if (!$this->client) {
throw new Exception('You must setClient before you can getClient!');
}
return $this->client;
}
public function setClient(PhabricatorOAuthServerClient $client) {
$this->client = $client;
return $this;
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-04 01:21:40 +01:00
}
/**
* @task auth
*/
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
public function userHasAuthorizedClient() {
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-04 01:21:40 +01:00
$authorization = id(new PhabricatorOAuthClientAuthorization())->
loadOneWhere('userPHID = %s AND clientPHID = %s',
$this->getUser()->getPHID(),
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
$this->getClient->getPHID());
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-04 01:21:40 +01:00
if (empty($authorization)) {
return false;
}
return true;
}
/**
* @task auth
*/
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
public function authorizeClient(array $scope) {
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-04 01:21:40 +01:00
$authorization = new PhabricatorOAuthClientAuthorization();
$authorization->setUserPHID($this->getUser()->getPHID());
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
$authorization->setClientPHID($this->getClient()->getPHID());
$authorization->setScope($scope);
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-04 01:21:40 +01:00
$authorization->save();
return $authorization;
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-04 01:21:40 +01:00
}
/**
* @task auth
*/
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
public function generateAuthorizationCode() {
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-04 01:21:40 +01:00
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
$code = Filesystem::readRandomCharacters(32);
$client = $this->getClient();
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-04 01:21:40 +01:00
$authorization_code = new PhabricatorOAuthServerAuthorizationCode();
$authorization_code->setCode($code);
$authorization_code->setClientPHID($client->getPHID());
$authorization_code->setClientSecret($client->getSecret());
$authorization_code->setUserPHID($this->getUser()->getPHID());
$authorization_code->save();
return $authorization_code;
}
/**
* @task token
*/
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
public function generateAccessToken() {
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-04 01:21:40 +01:00
$token = Filesystem::readRandomCharacters(32);
$access_token = new PhabricatorOAuthServerAccessToken();
$access_token->setToken($token);
$access_token->setUserPHID($this->getUser()->getPHID());
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
$access_token->setClientPHID($this->getClient()->getPHID());
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-04 01:21:40 +01:00
$access_token->save();
return $access_token;
}
/**
* @task token
*/
public function validateAuthorizationCode(
PhabricatorOAuthServerAuthorizationCode $test_code,
PhabricatorOAuthServerAuthorizationCode $valid_code) {
// check that all the meta data matches
if ($test_code->getClientPHID() != $valid_code->getClientPHID()) {
return false;
}
if ($test_code->getClientSecret() != $valid_code->getClientSecret()) {
return false;
}
// check that the authorization code hasn't timed out
$created_time = $test_code->getDateCreated();
$must_be_used_by = $created_time + self::AUTHORIZATION_CODE_TIMEOUT;
return (time() < $must_be_used_by);
}
OAuth Server enhancements -- more complete access token response and groundwork for scope Summary: this patch makes the access token response "complete" relative to spec by returning when it expires AND that the token_type is in fact 'Bearer'. This patch also lays the groundwork for scope by fixing the underlying data model and adding the first scope checks for "offline_access" relative to expires and the "whoami" method. Further, conduit is augmented to open up individual methods for access via OAuth generally to enable "whoami" access. There's also a tidy little scope class to keep track of all the various scopes we plan to have as well as strings for display (T849 - work undone) Somewhat of a hack but Conduit methods by default have SCOPE_NOT_ACCESSIBLE. We then don't even bother with the OAuth stuff within conduit if we're not supposed to be accessing the method via Conduit. Felt relatively clean to me in terms of additional code complexity, etc. Next up ends up being T848 (scope in OAuth) and T849 (let user's authorize clients for specific scopes which kinds of needs T850). There's also a bunch of work that needs to be done to return the appropriate, well-formatted error codes. All in due time...! Test Plan: verified that an access_token with no scope doesn't let me see anything anymore. :( verified that access_tokens made awhile ago expire. :( Reviewers: epriestley Reviewed By: epriestley CC: aran, epriestley Maniphest Tasks: T888, T848 Differential Revision: https://secure.phabricator.com/D1657
2012-02-21 23:28:05 +01:00
/**
* @task token
*/
public function validateAccessToken(
PhabricatorOAuthServerAccessToken $token,
$required_scope) {
$created_time = $token->getDateCreated();
$must_be_used_by = $created_time + self::ACCESS_TOKEN_TIMEOUT;
$expired = time() > $must_be_used_by;
$authorization = id(new PhabricatorOAuthClientAuthorization())
->loadOneWhere(
'userPHID = %s AND clientPHID = %s',
$token->getUserPHID(),
$token->getClientPHID());
if (!$authorization) {
return false;
}
$token_scope = $authorization->getScope();
if (!isset($token_scope[$required_scope])) {
return false;
}
if ($expired) {
$valid = false;
// check if the scope includes "offline_access", which makes the
// token valid despite being expired
if (isset(
$token_scope[PhabricatorOAuthServerScope::SCOPE_OFFLINE_ACCESS]
)) {
$valid = true;
}
}
return $valid;
}
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-04 01:21:40 +01:00
}