[18.0][BKP] webservice: configurable OAuth2 token request - #168
Closed
Ricardoalso wants to merge 241 commits into
Closed
Ricardoalso wants to merge 241 commits into
Ricardoalso wants to merge 241 commits into
Conversation
When an endpoint is archived it must be dropped. When it's unarchive it must be restored.
Routing maps are generated **per env** which means that every new env will have its own routing map attached to `ir.http` registry class. This is not desired (as per core Odoo comment) but it's like this today :/ Hence, before this change, the routing map could be mis-aligned across different envs leading to random responses for custom endpoints. This refactoring simplifies a lot the handling of the rules leaving to std `_generate_routing_rules` the duty to yield rules and to `routing_map` to generate them for the new route map. EndpointRegistry memory consumption is improved too thanks to smaller data to store and to the usage of __slots__.
To avoid multiple invalidation of all envs on each edit or create of persistent records, a new flag is introduced: 'registry_sync'. This flag delays the sync of the rule registry till manual action occurs. Records in the UI are decorated accordingly to notify users of the need to reflect changes on ther registry to make them effective. The sync happens in a post commit hook to ensure all values are in place for the affected records.
Depending on your modules inheritance and upgrade order when you introduce this mixin on an existing model it might happen that gets called before the model's table is ready (eg: another odoo service loading the env before the upgrade happens). Let if fail gracefully since the hook will be called again later.
As routes are registered automatically in the db after sync there's no reason to look for non registered routes at boot. Furthermore, this is causing access conflicts on the table when multiple instances w/ multiple workers are spawned.
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: web-api-19.0/web-api-19.0-endpoint Translate-URL: https://translation.odoo-community.org/projects/web-api-19-0/web-api-19-0-endpoint/
This commits adds support for CORS setting on endpoints. Without this, the default behavior is to disallow all origins. That's usually the opposite of what you want for an API endpoint, as you want consumers to be able to access the endpoint from their own origin. Now, by default, the endpoint will allow all origins (default="*"), and it can be further configured for more specific restrictions.
Currently translated at 100.0% (53 of 53 strings) Translation: web-api-19.0/web-api-19.0-endpoint Translate-URL: https://translation.odoo-community.org/projects/web-api-19-0/web-api-19-0-endpoint/it/
…d calls When sending exchanges through an OAuth2-configured webservice.backend, the request crashed with: TypeError: Session.request() got an unexpected keyword argument 'content_only' Stack trace pointed to webservice/components/request_adapter.py in BackendApplicationOAuth2RestRequestsAdapter._request, where content_only was forwarded to OAuth2Session.request(...)
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: web-api-19.0/web-api-19.0-endpoint_route_handler Translate-URL: https://translation.odoo-community.org/projects/web-api-19-0/web-api-19-0-endpoint_route_handler/
Updated by "Update PO files to match POT (msgmerge)" hook in Weblate. Translation: web-api-19.0/web-api-19.0-endpoint Translate-URL: https://translation.odoo-community.org/projects/web-api-19-0/web-api-19-0-endpoint/
Currently translated at 100.0% (55 of 55 strings) Translation: web-api-19.0/web-api-19.0-endpoint Translate-URL: https://translation.odoo-community.org/projects/web-api-19-0/web-api-19-0-endpoint/it/
Currently translated at 100.0% (31 of 31 strings) Translation: web-api-19.0/web-api-19.0-endpoint_route_handler Translate-URL: https://translation.odoo-community.org/projects/web-api-19-0/web-api-19-0-endpoint_route_handler/it/
Until now the OAuth2 "Backend Application (Client Credentials)" flow
always requested the token in one fixed way: an HTTP POST where the
client id and secret were turned into an HTTP Basic Authorization header
(this is what oauthlib does by default). Providers that deviate from
that could not be used.
Two configuration options are added to the webservice backend so those
providers can be supported through configuration only:
- Token Request Method: POST (default) or GET, for providers that expose
the token endpoint as a GET.
- Client Authentication: how the client credentials are presented to the
token endpoint:
* Client ID & Secret (HTTP Basic) (default): the previous behavior,
unchanged.
* Custom Authorization header: a static, verbatim header value (for
example "SSWS <token>"). In this case the Client ID / Client Secret
fields are not used; the header name and value are configured
directly instead.
The defaults keep the exact same behavior as before, so existing
backends are not affected. The custom header is injected through a small
requests auth handler so that oauthlib does not overwrite it with its
automatic Basic Authorization header.
Two validation rules make sure the right fields are filled in depending
on the chosen client authentication: the client id and secret for the
HTTP Basic method, or the header name and value for the custom header
method.
There was a misuse of `and` instead of `or` in the `invisible` attribute of some fields that are specific to the Web Application flow
The webservice module gained new OAuth2 configuration fields (the token request method, the client authentication method, and the custom Authorization header name and value). These are now also manageable through server environment configuration files, like the other webservice fields.
Contributor
OCA-git-bot
added
mod:webservice
Ricardoalso
marked this pull request as draft
September 23, 2026 14:28
Ricardoalso
force-pushed
the
18.0-imp-webservice-oauth2-client-auth
branch
from
September 24, 2026 11:24
4771f4f to
1087c69
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Back port of https://github.com/OCA/web-api/pull/143/commits