pyramid_oauthlib_lowlevel
=========================
This is a package designed to create oAuth servers with Pyramid through a lowlevel interface that allows for more customization.
Before using this package I suggest you consider the package `pyramid-oauthlib`, it is possibly better suited to your needs as it offers a highlevel interface.
Seriously. This package provides a very lowlevel interface to customizing the `oauthlib` package within Pyramid. Most people will want to use the higher level abstractions with a more simplified package.
What do I mean by highlevel vs lowlevel?
highlevel: `pyramid-oauthlib` makes a lot of hard decisions for you, and gives you a handful of hooks to easily implement oAuth flows into your Pyramid application. You don't need to know much about oAuth to utilize it.
lowlevel: `pyramid-oauthlib-lowlevel` provides a very basic integration scheme for leveraging the oauthlib library in Pyramid applications. You generally need to know quote a bit about oAuth to handle this.
Some use-cases for this package are situations where:
1. You need to support oAuth1. (`pyramid-oauthlib` only supports oAuth2)
2. You need more fine-grained control over the oAuth2 integration or to host multiple oAuth2 servers. `pyramid-oauthlib` expects you to be doing things a certain way (which is very common and the status-quo).
3. You need to support/create broken oAuth servers.*
* Broken oAuth servers? Yes. Even major internet services often implement oAuth in ways that do not fully adhere to the specs, or violate them. Offline integrated test suites may need to create servers which can mimic this behavior.
The package generally works by defining one or more subclasses to handle getting/setting data objects, then invoking them on Pyramid requests via explicitly designed oAuth providers.
This approach will allow you to create multiple oAuth servers and/or authentication methods running on the same Pyramid server
The rational for developing with this approach was a need to:
1. support multiple oAuth versions and endpoints on a whitelabel service
2. limit and isolate the oAuth data from the Pyramid request.
This project was largely modeled after `flask-oauthlib` and the core `oauthlib` package. Docstrings in this package are taken from both. Significant portions of code in this package are a port of `flask-oauthlib` to `Pyramid`; many portions adapt bits straight from `oauthlib` as well.
How This Package is Generally Designed
======================================
Both `oauth1` and `oauth2` namespaces offer a `provider` and `validator` namespace.
The `oauth1.validator.OAuth1RequestValidator_Hooks` and `oauth2.validator.OAuth2RequestValidator_Hooks` classes provide hooks for the `RequestValidator` to get/set data from your database and cache. In every deployment these must be subclassed.
The `oauth1.validator.OAuth1RequestValidator` and `oauth2.validator.OAuth2RequestValidator` classes provide the logic used to handle oAuth requests, adapted to Pyramid. Only in rare cases should these be subclassed.
The `oauth1.provider.OAuth1Provider` and `oauth2.provider.OAuth2Provider` provide methods which invoke the `RequestValidator` under Pyramid endpoints as logical units of work that are either endpoints or resource validators. Only in rare cases should these be subclassed.
* `oauth1.provider.OAuth1Provider`
* `.endpoint__request_token`
* `.endpoint__access_token`
* `.extract__endpoint_authorize_data`
* `.endpoint__authorize__authorize`
* `.logic__is_authorized`
* `oauth2.provider.OAuth2Provider`
* `.endpoint__validate_authorization_request`
* `.endpoint__confirm_authorization_request`
* `.endopoint__token`
* `.endpoint__revoke_token`
* `.verify_request`
Typically usage will involve these steps:
* subclass a `hooks` object in the application
* on a request, first create a new instance of a `provider` with the customized hook
* on a request, then invoke the desired endpoint or request validation.
The Tests are Fully Functional Examples!
========================================
The tests contain full example applications/servers and logic flows that iterate through different oAuth strategies. For example, the oAuth2 test include (oAuth1 tests are identical):
* `tests.oauth2_app` defines a fully functional oAuth2 server which can be spun up
* `tests.oauth2.PyramidTestApp` spins up a `tests.oauth2_app` instance, and uses that to make requests
* `tests.oauth2.PyramidTestApp.test_valid_flow__get_access_token` tests a flow for obtaining a "bearer_token" from the oAuth2 server
* `tests.oauth2_model` defines the persistence models (SqlAlchemy) used by unit tests and the test apps
* `tests.oauth2_utils` defines the subclasses and utilities used for both the unit tests and test apps
Supported Flows
===============
All oAuth flows will ideally be supported. PRs are very much welcome!
Currently the supported flows are:
* oAuth1 - Application Authorization - New Account Registration (see `tests.oauth1.PyramidTestApp.test_valid_flow__registration`)
* oAuth2 - Application Authorization - New Account Registration (see `tests.oauth2.PyramidTestApp.test_valid_flow__registration`)
* oAuth2 - Obtain Bearer Token (see `tests.oauth2.PyramidTestApp.test_valid_flow__get_access_token`)
* oAuth2 - Refresh Token (see `tests.oauth2.PyramidTestApp.test_valid_flow__registration`)
* oAuth2 - Revoke Token (see `tests.oauth2.PyramidTestApp.test_valid_flow__get_access_token`)
Todo:
* oAuth1 - Application Authorization - Bind Existing Account
* oAuth2 - Application Authorization - Bind Existing Account
Notes:
* `New Account Registration` means a new account is established on `Application` for an existing user of `Authority`
* `Bind Existing Account` means an existing user of `Application` with connect their account to their existing account on `Authority`
These above elements both use the same oAuth flows and endpoints, they just integrate them slightly differently
Tutorial
===============
Here is a quick way to design an oAuth server:
1. Subclass OAuth1RequestValidator
# this is optional
class CustomValidator(OAuth1RequestValidator):
"""some validator methods do need overrides."""
@property
def realms(self):
return ['platform.actor', ]
@property
def client_key_length(self):
return (40, 64)
...
2. Subclass OAuth1RequestValidator_Hooks
# the library provides a `@catch_backend_failure` to wrap backend failures with more meaning
class CustomValidator_Hooks(OAuth1RequestValidator_Hooks):
"""
This custom object expects a SqlAlchemy connection on `self.pyramid_request.dbSession`
"""
@catch_backend_failure
def _get_TokenRequest_by_verifier(self, verifier, request=None):
"""
:param verifier: The verifier string.
:param request: An oauthlib.common.Request object.
"""
verifierObject = sqla.get_Developer_oAuth1Server_TokenRequest__by_oauthVerifier(
self.pyramid_request.dbSession,
verifier,
)
return verifierObject
3. Create an oAuth object
# this might be a request property via @reify
def new_oauth1Provider(request):
"""this is used to build a new auth"""
validatorHooks = CustomValidator_Hooks(request)
provider = pyramid_oauthlib_lowlevel.oauth1.provider.OAuth1Provider(request,
validator_api_hooks = validatorHooks,
validator_class = CustomValidator
)
return provider
4. Use the oAuth object - Checking for API access
# Within your authorization routines, you can check for a valid oauth request
oauth1Provider = new_oauth1Provider(request)
_is_authorized, req = oauth1Provider.logic__is_authorized(['platform.actor', ])
if not _is_authorized:
raise HTTPUnauthorized(body="""'{"error": "Not Authorized (oAuth Failed)}'""", content_type='application/json')
# perhaps do something with `req.client` and `req.access_token`
5. Use the oAuth object - routes for granting access
See the testapps
Integration
===============
Because this is a `_lowlevel` library, there is no automagic integration of this package into Pyramid.
In the example apps, convenience methods are used to create an oauth provider as needed:
def new_oauth2Provider(pyramid_request):
validatorHooks = CustomValidator_Hooks(pyramid_request)
provider = oauth2_provider.OAuth2Provider(pyramid_request,
validator_api_hooks = validatorHooks,
validator_class = CustomValidator
)
return provider
A deployment might handle this as part of Pyramid AUTH, within Tweens or Middleware, as a request property, or many other options.
The oauth2 testapp has a particular flow worth noting:
`ExampleApp.fetch_protected_resource` A user must log into ExampleApp and have an authorized token for the Authority system. This route will load the token and use it to make an oAuth2 request against the Authority system.
`Authority_Oauth2_API_Public.protected_resource` The resource is protected behind an oauth2 token validation.
oauth2Provider = new_oauth2Provider(self.request)
scopes = ['platform.actor', ]
valid, req = oauth2Provider.verify_request(scopes)
oAuth Flows
======================================
There are many different flows one can do in oAuth
This project is currently aimed at implementing the following families of flows:
* Flow-AccountRegistration - a user of `Authority` establishes a new account on `Application`
* Flow-AccountBind - an existing user of `Application` links their account to `Authority`
* Flow-Developer - a user of `Authority` has created an `Application` and needs an access token
Notes on Token Expiration and Refresh
=====================================
There are several strategies and concerns for expiring access and refresh tokens during a refresh.
Some deployments wish to expire all access tokens for a user when a new access_token is generated.
This is illustrated in `oauth2_utils.OAuth2RequestValidator_Hooks.bearer_token_setter`, which sets existing live tokens for a user/client as inactive.
Some deployments will not want to do this, such as cloud based systems which may take some time to propagate new credentials.
Some deployments will wish to recycle a `refresh_token` across multiple access_token refreshes. This is supported by overriding a default method in `OAuth2RequestValidator`
class CustomValidator(OAuth2RequestValidator):
def rotate_refresh_token(self, request):
"""Determine whether to rotate the refresh token. Default, yes.
When access tokens are refreshed the old refresh token can be kept
or replaced with a new one (rotated). Return True to rotate and
and False for keeping original.
:param request: oauthlib.common.Request
:rtype: True or False
Method is used by:
- Refresh Token Grant
"""
return True
Both forms are covered in the test suite (the default is overridden by monkeypatching the Request Validator, then it is reset)
Some deployments will want to DELETE a token when it expires or is revoked. This library is designed to support using database flags to mark if a token is active, revoked, expired, etc. This is designed for concerns in bookkeeping.
Notes on Refreshing Tokens
==========================
OAuthlib is an excellent library, but there are some minor inconveniences you may need to look out for when refreshing a token.
1. OAuthlib does not cache the refresh_token's object, it merely validates it or it's parameters. Unless you specifically cache it, you may load it multiple times in a single request for each validation operation. Many packages that utilize OAuthlib do not account for this implementation detail - this package included.
2. OAuthlib does not maintain the lineage of a token across refreshes. This is important if your application supports more than one type of grant (such as supporting both `authorization_code` AND `client_credentials`). To get around this, we recommend doing the following:
* extend the storage for tokens with the following fields:
* `grant_type`
* `original_grant_type`
* extend `bearer_token_setter` to do the following:
* store the `request.grant_type` onto the new token object when you save it to the database.
* if the `grant_type` is not "refresh_token", store that value as the `original_grant_type`
* if the `grant_type` is "refresh_token", then load the "refresh_token" object (request.refresh_token), and copy the `original_grant_type`
This strategy will allow you to easily differentiate between client_credential (Application) and authorization_code (User) tokens.
Python Compatibility
====================
`pyramid_oauthlib_lowlevel` is tested to run under Python2.7 and Python3.6+
License
=======
Some functions are ported from oauthlib and flask-oauthlib;
see LICENSE.txt
Some functions are ported from Pyramid and appear under their License;
see LICENSE-Pyramid.txt
Raw data
{
"_id": null,
"home_page": "https://github.com/jvanasco/pyramid_oauthlib_lowlevel",
"name": "pyramid-oauthlib-lowlevel",
"maintainer": "",
"docs_url": null,
"requires_python": "",
"maintainer_email": "",
"keywords": "web pyramid oauth oauthlib",
"author": "Jonathan Vanasco",
"author_email": "jonathan@findmeon.com",
"download_url": "https://files.pythonhosted.org/packages/c8/f9/f924daa3f2af98a64a23f7d905c8db2069460c1e3ea76eb4281503e26f4c/pyramid_oauthlib_lowlevel-0.4.0.tar.gz",
"platform": null,
"description": "pyramid_oauthlib_lowlevel\n=========================\n\n\n\nThis is a package designed to create oAuth servers with Pyramid through a lowlevel interface that allows for more customization.\n\nBefore using this package I suggest you consider the package `pyramid-oauthlib`, it is possibly better suited to your needs as it offers a highlevel interface.\n\nSeriously. This package provides a very lowlevel interface to customizing the `oauthlib` package within Pyramid. Most people will want to use the higher level abstractions with a more simplified package.\n\nWhat do I mean by highlevel vs lowlevel?\n\nhighlevel: `pyramid-oauthlib` makes a lot of hard decisions for you, and gives you a handful of hooks to easily implement oAuth flows into your Pyramid application. You don't need to know much about oAuth to utilize it.\n\nlowlevel: `pyramid-oauthlib-lowlevel` provides a very basic integration scheme for leveraging the oauthlib library in Pyramid applications. You generally need to know quote a bit about oAuth to handle this.\n\nSome use-cases for this package are situations where:\n\n1. You need to support oAuth1. (`pyramid-oauthlib` only supports oAuth2)\n2. You need more fine-grained control over the oAuth2 integration or to host multiple oAuth2 servers. `pyramid-oauthlib` expects you to be doing things a certain way (which is very common and the status-quo).\n3. You need to support/create broken oAuth servers.*\n\n* Broken oAuth servers? Yes. Even major internet services often implement oAuth in ways that do not fully adhere to the specs, or violate them. Offline integrated test suites may need to create servers which can mimic this behavior.\n\nThe package generally works by defining one or more subclasses to handle getting/setting data objects, then invoking them on Pyramid requests via explicitly designed oAuth providers.\n\nThis approach will allow you to create multiple oAuth servers and/or authentication methods running on the same Pyramid server\n\nThe rational for developing with this approach was a need to:\n1. support multiple oAuth versions and endpoints on a whitelabel service\n2. limit and isolate the oAuth data from the Pyramid request.\n\nThis project was largely modeled after `flask-oauthlib` and the core `oauthlib` package. Docstrings in this package are taken from both. Significant portions of code in this package are a port of `flask-oauthlib` to `Pyramid`; many portions adapt bits straight from `oauthlib` as well.\n\n\nHow This Package is Generally Designed\n======================================\n\nBoth `oauth1` and `oauth2` namespaces offer a `provider` and `validator` namespace.\n\nThe `oauth1.validator.OAuth1RequestValidator_Hooks` and `oauth2.validator.OAuth2RequestValidator_Hooks` classes provide hooks for the `RequestValidator` to get/set data from your database and cache. In every deployment these must be subclassed.\n\nThe `oauth1.validator.OAuth1RequestValidator` and `oauth2.validator.OAuth2RequestValidator` classes provide the logic used to handle oAuth requests, adapted to Pyramid. Only in rare cases should these be subclassed.\n\nThe `oauth1.provider.OAuth1Provider` and `oauth2.provider.OAuth2Provider` provide methods which invoke the `RequestValidator` under Pyramid endpoints as logical units of work that are either endpoints or resource validators. Only in rare cases should these be subclassed.\n\n* `oauth1.provider.OAuth1Provider`\n * `.endpoint__request_token`\n * `.endpoint__access_token`\n * `.extract__endpoint_authorize_data`\n * `.endpoint__authorize__authorize`\n * `.logic__is_authorized`\n\n* `oauth2.provider.OAuth2Provider`\n * `.endpoint__validate_authorization_request`\n * `.endpoint__confirm_authorization_request`\n * `.endopoint__token`\n * `.endpoint__revoke_token`\n * `.verify_request`\n\nTypically usage will involve these steps:\n\n* subclass a `hooks` object in the application\n* on a request, first create a new instance of a `provider` with the customized hook\n* on a request, then invoke the desired endpoint or request validation.\n\n\nThe Tests are Fully Functional Examples!\n========================================\n\nThe tests contain full example applications/servers and logic flows that iterate through different oAuth strategies. For example, the oAuth2 test include (oAuth1 tests are identical):\n\n* `tests.oauth2_app` defines a fully functional oAuth2 server which can be spun up\n* `tests.oauth2.PyramidTestApp` spins up a `tests.oauth2_app` instance, and uses that to make requests\n* `tests.oauth2.PyramidTestApp.test_valid_flow__get_access_token` tests a flow for obtaining a \"bearer_token\" from the oAuth2 server\n* `tests.oauth2_model` defines the persistence models (SqlAlchemy) used by unit tests and the test apps\n* `tests.oauth2_utils` defines the subclasses and utilities used for both the unit tests and test apps\n\n\nSupported Flows\n===============\n\nAll oAuth flows will ideally be supported. PRs are very much welcome!\n\nCurrently the supported flows are:\n\n* oAuth1 - Application Authorization - New Account Registration (see `tests.oauth1.PyramidTestApp.test_valid_flow__registration`)\n* oAuth2 - Application Authorization - New Account Registration (see `tests.oauth2.PyramidTestApp.test_valid_flow__registration`)\n* oAuth2 - Obtain Bearer Token (see `tests.oauth2.PyramidTestApp.test_valid_flow__get_access_token`)\n* oAuth2 - Refresh Token (see `tests.oauth2.PyramidTestApp.test_valid_flow__registration`)\n* oAuth2 - Revoke Token (see `tests.oauth2.PyramidTestApp.test_valid_flow__get_access_token`)\n\nTodo:\n\n* oAuth1 - Application Authorization - Bind Existing Account\n* oAuth2 - Application Authorization - Bind Existing Account\n\nNotes:\n\n* `New Account Registration` means a new account is established on `Application` for an existing user of `Authority`\n* `Bind Existing Account` means an existing user of `Application` with connect their account to their existing account on `Authority`\n\nThese above elements both use the same oAuth flows and endpoints, they just integrate them slightly differently\n\n\nTutorial\n===============\n\n\nHere is a quick way to design an oAuth server:\n\n1. Subclass OAuth1RequestValidator\n\n\t# this is optional\n\n\tclass CustomValidator(OAuth1RequestValidator):\n\t\t\"\"\"some validator methods do need overrides.\"\"\"\n\n\t\t@property\n\t\tdef realms(self):\n\t\t\treturn ['platform.actor', ]\n\n\t\t@property\n\t\tdef client_key_length(self):\n\t\t\treturn (40, 64)\n\n\t\t...\n\n2. Subclass OAuth1RequestValidator_Hooks\n\n\t# the library provides a `@catch_backend_failure` to wrap backend failures with more meaning\n\n\tclass CustomValidator_Hooks(OAuth1RequestValidator_Hooks):\n\t\t\"\"\"\n\t\tThis custom object expects a SqlAlchemy connection on `self.pyramid_request.dbSession`\n\t\t\"\"\"\n\n\t\t@catch_backend_failure\n\t\tdef _get_TokenRequest_by_verifier(self, verifier, request=None):\n\t\t\t\"\"\"\n\t\t\t:param verifier: The verifier string.\n\t\t\t:param request: An oauthlib.common.Request object.\n\t\t\t\"\"\"\n\t\t\tverifierObject = sqla.get_Developer_oAuth1Server_TokenRequest__by_oauthVerifier(\n\t\t\t\tself.pyramid_request.dbSession,\n\t\t\t\tverifier,\n\t\t\t)\n\t\t\treturn verifierObject\n\n3. Create an oAuth object\n\n\t# this might be a request property via @reify\n\t\n\tdef new_oauth1Provider(request):\n\t\t\"\"\"this is used to build a new auth\"\"\"\n\t\tvalidatorHooks = CustomValidator_Hooks(request)\n\t\tprovider = pyramid_oauthlib_lowlevel.oauth1.provider.OAuth1Provider(request,\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\tvalidator_api_hooks = validatorHooks,\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\tvalidator_class = CustomValidator\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t)\n\t\treturn provider\n\n4. Use the oAuth object - Checking for API access\n\n\t# Within your authorization routines, you can check for a valid oauth request\n\n\toauth1Provider = new_oauth1Provider(request)\n\t_is_authorized, req = oauth1Provider.logic__is_authorized(['platform.actor', ])\n\tif not _is_authorized:\n\t\traise HTTPUnauthorized(body=\"\"\"'{\"error\": \"Not Authorized (oAuth Failed)}'\"\"\", content_type='application/json')\n\t# perhaps do something with `req.client` and `req.access_token`\n\t\n\t\n5. Use the oAuth object - routes for granting access\n\n\tSee the testapps\n\n\nIntegration\n===============\n\nBecause this is a `_lowlevel` library, there is no automagic integration of this package into Pyramid.\n\nIn the example apps, convenience methods are used to create an oauth provider as needed:\n\n\tdef new_oauth2Provider(pyramid_request):\n\t\tvalidatorHooks = CustomValidator_Hooks(pyramid_request)\n\t\tprovider = oauth2_provider.OAuth2Provider(pyramid_request,\n\t\t\t\t\t\t\t\t\t\t\t\t validator_api_hooks = validatorHooks,\n\t\t\t\t\t\t\t\t\t\t\t\t validator_class = CustomValidator\n\t\t\t\t\t\t\t\t\t\t\t\t )\n\t\treturn provider\n\nA deployment might handle this as part of Pyramid AUTH, within Tweens or Middleware, as a request property, or many other options.\n\nThe oauth2 testapp has a particular flow worth noting:\n\n`ExampleApp.fetch_protected_resource` A user must log into ExampleApp and have an authorized token for the Authority system. This route will load the token and use it to make an oAuth2 request against the Authority system.\n\n`Authority_Oauth2_API_Public.protected_resource` The resource is protected behind an oauth2 token validation.\n\n\t oauth2Provider = new_oauth2Provider(self.request)\n scopes = ['platform.actor', ]\n valid, req = oauth2Provider.verify_request(scopes)\n\n\noAuth Flows\n======================================\n\nThere are many different flows one can do in oAuth\n\nThis project is currently aimed at implementing the following families of flows:\n\n* Flow-AccountRegistration - a user of `Authority` establishes a new account on `Application`\n* Flow-AccountBind - an existing user of `Application` links their account to `Authority`\n* Flow-Developer - a user of `Authority` has created an `Application` and needs an access token\n\n\nNotes on Token Expiration and Refresh\n=====================================\n\nThere are several strategies and concerns for expiring access and refresh tokens during a refresh.\n\nSome deployments wish to expire all access tokens for a user when a new access_token is generated.\n\nThis is illustrated in `oauth2_utils.OAuth2RequestValidator_Hooks.bearer_token_setter`, which sets existing live tokens for a user/client as inactive.\n\nSome deployments will not want to do this, such as cloud based systems which may take some time to propagate new credentials. \n\nSome deployments will wish to recycle a `refresh_token` across multiple access_token refreshes. This is supported by overriding a default method in `OAuth2RequestValidator`\n\n\tclass CustomValidator(OAuth2RequestValidator):\n\n\t\tdef rotate_refresh_token(self, request):\n\t\t\t\"\"\"Determine whether to rotate the refresh token. Default, yes.\n\n\t\t\tWhen access tokens are refreshed the old refresh token can be kept\n\t\t\tor replaced with a new one (rotated). Return True to rotate and\n\t\t\tand False for keeping original.\n\n\t\t\t:param request: oauthlib.common.Request\n\t\t\t:rtype: True or False\n\n\t\t\tMethod is used by:\n\t\t\t\t- Refresh Token Grant\n\t\t\t\"\"\"\n\t\t\treturn True\n\n\nBoth forms are covered in the test suite (the default is overridden by monkeypatching the Request Validator, then it is reset)\n\nSome deployments will want to DELETE a token when it expires or is revoked. This library is designed to support using database flags to mark if a token is active, revoked, expired, etc. This is designed for concerns in bookkeeping.\n\nNotes on Refreshing Tokens\n==========================\n\nOAuthlib is an excellent library, but there are some minor inconveniences you may need to look out for when refreshing a token.\n\n1. OAuthlib does not cache the refresh_token's object, it merely validates it or it's parameters. Unless you specifically cache it, you may load it multiple times in a single request for each validation operation. Many packages that utilize OAuthlib do not account for this implementation detail - this package included.\n\n2. OAuthlib does not maintain the lineage of a token across refreshes. This is important if your application supports more than one type of grant (such as supporting both `authorization_code` AND `client_credentials`). To get around this, we recommend doing the following:\n\n * extend the storage for tokens with the following fields:\n * `grant_type`\n * `original_grant_type`\n * extend `bearer_token_setter` to do the following:\n * store the `request.grant_type` onto the new token object when you save it to the database.\n * if the `grant_type` is not \"refresh_token\", store that value as the `original_grant_type`\n * if the `grant_type` is \"refresh_token\", then load the \"refresh_token\" object (request.refresh_token), and copy the `original_grant_type`\n\nThis strategy will allow you to easily differentiate between client_credential (Application) and authorization_code (User) tokens.\n\n\nPython Compatibility\n====================\n\n`pyramid_oauthlib_lowlevel` is tested to run under Python2.7 and Python3.6+\n\nLicense\n=======\n\nSome functions are ported from oauthlib and flask-oauthlib;\nsee LICENSE.txt\n\nSome functions are ported from Pyramid and appear under their License;\nsee LICENSE-Pyramid.txt\n\n\n\n\n\n\n",
"bugtrack_url": null,
"license": "BSD",
"summary": "lowlevel Pyramid implementation of oauthlib",
"version": "0.4.0",
"project_urls": {
"Homepage": "https://github.com/jvanasco/pyramid_oauthlib_lowlevel"
},
"split_keywords": [
"web",
"pyramid",
"oauth",
"oauthlib"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "c8f9f924daa3f2af98a64a23f7d905c8db2069460c1e3ea76eb4281503e26f4c",
"md5": "810182d55cefff97b72f99012afdb3d2",
"sha256": "06c82be53be67539ad0c937a4ba4c19ba2a584d2fec13f798f2400fdcf9fa34b"
},
"downloads": -1,
"filename": "pyramid_oauthlib_lowlevel-0.4.0.tar.gz",
"has_sig": false,
"md5_digest": "810182d55cefff97b72f99012afdb3d2",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 73562,
"upload_time": "2023-11-20T23:25:29",
"upload_time_iso_8601": "2023-11-20T23:25:29.992069Z",
"url": "https://files.pythonhosted.org/packages/c8/f9/f924daa3f2af98a64a23f7d905c8db2069460c1e3ea76eb4281503e26f4c/pyramid_oauthlib_lowlevel-0.4.0.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2023-11-20 23:25:29",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "jvanasco",
"github_project": "pyramid_oauthlib_lowlevel",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"tox": true,
"lcname": "pyramid-oauthlib-lowlevel"
}
JSON
