Skip to content

Commit

Permalink
[MIG] auth_jwt: Migration to 17.0
Browse files Browse the repository at this point in the history
  • Loading branch information
MikeAelbrecht authored and kobros-tech committed Jan 17, 2025
1 parent 5856039 commit 559b3fe
Show file tree
Hide file tree
Showing 16 changed files with 233 additions and 202 deletions.
121 changes: 64 additions & 57 deletions auth_jwt/README.rst
Original file line number Diff line number Diff line change
Expand Up @@ -17,13 +17,13 @@ Auth JWT
:target: http://www.gnu.org/licenses/lgpl-3.0-standalone.html
:alt: License: LGPL-3
.. |badge3| image:: https://img.shields.io/badge/github-OCA%2Fserver--auth-lightgray.png?logo=github
:target: https://github.com/OCA/server-auth/tree/16.0/auth_jwt
:target: https://github.com/OCA/server-auth/tree/17.0/auth_jwt
:alt: OCA/server-auth
.. |badge4| image:: https://img.shields.io/badge/weblate-Translate%20me-F47D42.png
:target: https://translation.odoo-community.org/projects/server-auth-16-0/server-auth-16-0-auth_jwt
:target: https://translation.odoo-community.org/projects/server-auth-17-0/server-auth-17-0-auth_jwt
:alt: Translate me on Weblate
.. |badge5| image:: https://img.shields.io/badge/runboat-Try%20me-875A7B.png
:target: https://runboat.odoo-community.org/builds?repo=OCA/server-auth&target_branch=16.0
:target: https://runboat.odoo-community.org/builds?repo=OCA/server-auth&target_branch=17.0
:alt: Try me on Runboat

|badge1| |badge2| |badge3| |badge4| |badge5|
Expand All @@ -43,96 +43,103 @@ This module requires the ``pyjwt`` library to be installed.
Usage
=====

This module lets developpers add a new ``jwt`` authentication method on Odoo
controller routes.
This module lets developpers add a new ``jwt`` authentication method on
Odoo controller routes.

To use it, you must:

* Create an ``auth.jwt.validator`` record to configure how the JWT token will
be validated.
* Add an ``auth="jwt_{validator-name}"`` or ``auth="public_or_jwt_{validator-name}"``
attribute to the routes you want to protect where ``{validator-name}`` corresponds to
the name attribute of the JWT validator record.
- Create an ``auth.jwt.validator`` record to configure how the JWT token
will be validated.
- Add an ``auth="jwt_{validator-name}"`` or
``auth="public_or_jwt_{validator-name}"`` attribute to the routes you
want to protect where ``{validator-name}`` corresponds to the name
attribute of the JWT validator record.

The ``auth_jwt_demo`` module provides examples.

The JWT validator can be configured with the following properties:

* ``name``: the validator name, to match the ``auth="jwt_{validator-name}"``
route property.
* ``audience``: a comma-separated list of allowed audiences, used to validate
the ``aud`` claim.
* ``issuer``: used to validate the ``iss`` claim.
* Signature type (secret or public key), algorithm, secret and JWK URI
- ``name``: the validator name, to match the
``auth="jwt_{validator-name}"`` route property.
- ``audience``: a comma-separated list of allowed audiences, used to
validate the ``aud`` claim.
- ``issuer``: used to validate the ``iss`` claim.
- Signature type (secret or public key), algorithm, secret and JWK URI
are used to validate the token signature.

In addition, the ``exp`` claim is validated to reject expired tokens.

If the ``Authorization`` HTTP header is missing, malformed, or contains
an invalid token, the request is rejected with a 401 (Unauthorized) code,
unless the cookie mode is enabled (see below).

If the token is valid, the request executes with the configured user id. By
default the user id selection strategy is ``static`` (i.e. the same for all
requests) and the selected user is configured on the JWT validator. Additional
strategies can be provided by overriding the ``_get_uid()`` method and
extending the ``user_id_strategy`` selection field.

The selected user is *not* stored in the session. It is only available in
``request.uid`` (and thus it is the one used in ``request.env``). To avoid any
confusion and mismatches between the bearer token and the session, this module
rejects requests made with an authenticated user session.

Additionally, if a ``partner_id_strategy`` is configured, a partner is searched
and if found, its id is stored in the ``request.jwt_partner_id`` attribute. If
``partner_id_required`` is set, a 401 (Unauthorized) is returned if no partner
was found. Otherwise ``request.jwt_partner_id`` is left falsy. Additional
strategies can be provided by overriding the ``_get_partner_id()`` method
and extending the ``partner_id_strategy`` selection field.
an invalid token, the request is rejected with a 401 (Unauthorized)
code, unless the cookie mode is enabled (see below).

If the token is valid, the request executes with the configured user id.
By default the user id selection strategy is ``static`` (i.e. the same
for all requests) and the selected user is configured on the JWT
validator. Additional strategies can be provided by overriding the
``_get_uid()`` method and extending the ``user_id_strategy`` selection
field.

The selected user is *not* stored in the session. It is only available
in ``request.uid`` (and thus it is the one used in ``request.env``). To
avoid any confusion and mismatches between the bearer token and the
session, this module rejects requests made with an authenticated user
session.

Additionally, if a ``partner_id_strategy`` is configured, a partner is
searched and if found, its id is stored in the
``request.jwt_partner_id`` attribute. If ``partner_id_required`` is set,
a 401 (Unauthorized) is returned if no partner was found. Otherwise
``request.jwt_partner_id`` is left falsy. Additional strategies can be
provided by overriding the ``_get_partner_id()`` method and extending
the ``partner_id_strategy`` selection field.

The decoded JWT payload is stored in ``request.jwt_payload``.

The ``public_auth_jwt`` method delegates authentication to the standard Odoo ``public``
method when the Authorization header is not set. If it is set, the regular JWT
authentication is performed as described above. This method is useful for public
endpoints that need to work for anonymous users, but can be enhanced when an
authenticated user is know. A typical use case is a "add to cart" endpoint that can work
for anonymous users, but can be enhanced by binding the cart to a known customer when
the authenticated user is known.

You can enable a cookie mode on JWT validators. In this case, the JWT payload obtained
from the ``Authorization`` header is returned as a Http-Only cookie. This mode is
sometimes simpler for front-end applications which do not then need to store and protect
the JWT token across requests and can simply rely on the cookie management mechanisms of
browsers. When both the ``Authorization`` header and a cookie are provided, the cookie
is ignored in order to let clients authenticate with a different user by providing a new
JWT token.
The ``public_auth_jwt`` method delegates authentication to the standard
Odoo ``public`` method when the Authorization header is not set. If it
is set, the regular JWT authentication is performed as described above.
This method is useful for public endpoints that need to work for
anonymous users, but can be enhanced when an authenticated user is know.
A typical use case is a "add to cart" endpoint that can work for
anonymous users, but can be enhanced by binding the cart to a known
customer when the authenticated user is known.

You can enable a cookie mode on JWT validators. In this case, the JWT
payload obtained from the ``Authorization`` header is returned as a
Http-Only cookie. This mode is sometimes simpler for front-end
applications which do not then need to store and protect the JWT token
across requests and can simply rely on the cookie management mechanisms
of browsers. When both the ``Authorization`` header and a cookie are
provided, the cookie is ignored in order to let clients authenticate
with a different user by providing a new JWT token.

Bug Tracker
===========

Bugs are tracked on `GitHub Issues <https://github.com/OCA/server-auth/issues>`_.
In case of trouble, please check there if your issue has already been reported.
If you spotted it first, help us to smash it by providing a detailed and welcomed
`feedback <https://github.com/OCA/server-auth/issues/new?body=module:%20auth_jwt%0Aversion:%2016.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_.
`feedback <https://github.com/OCA/server-auth/issues/new?body=module:%20auth_jwt%0Aversion:%2017.0%0A%0A**Steps%20to%20reproduce**%0A-%20...%0A%0A**Current%20behavior**%0A%0A**Expected%20behavior**>`_.

Do not contact contributors directly about support or help with technical issues.

Credits
=======

Authors
~~~~~~~
-------

* ACSONE SA/NV

Contributors
~~~~~~~~~~~~
------------

* Stéphane Bidoul <[email protected]>
- Stéphane Bidoul <[email protected]>
- Mohamed Alkobrosli <[email protected]>

Maintainers
~~~~~~~~~~~
-----------

This module is maintained by the OCA.

Expand All @@ -152,6 +159,6 @@ Current `maintainer <https://odoo-community.org/page/maintainer-role>`__:

|maintainer-sbidoul|

This module is part of the `OCA/server-auth <https://github.com/OCA/server-auth/tree/16.0/auth_jwt>`_ project on GitHub.
This module is part of the `OCA/server-auth <https://github.com/OCA/server-auth/tree/17.0/auth_jwt>`_ project on GitHub.

You are welcome to contribute. To learn how please visit https://odoo-community.org/page/Contribute.
5 changes: 4 additions & 1 deletion auth_jwt/__manifest__.py
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@
"name": "Auth JWT",
"summary": """
JWT bearer token authentication.""",
"version": "16.0.1.1.0",
"version": "17.0.1.0.0",
"license": "LGPL-3",
"author": "ACSONE SA/NV,Odoo Community Association (OCA)",
"maintainers": ["sbidoul"],
Expand All @@ -14,4 +14,7 @@
"external_dependencies": {"python": ["pyjwt", "cryptography"]},
"data": ["security/ir.model.access.csv", "views/auth_jwt_validator_views.xml"],
"demo": [],
"installable": True,
"application": False,
"auto_install": False,
}
2 changes: 1 addition & 1 deletion auth_jwt/exceptions.py
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ def __init__(self, errors):
super().__init__(
"Multiple errors occurred during JWT chain validation:\n"
+ "\n".join(
"{}: {}".format(validator_name, error)
f"{validator_name}: {error}"
for validator_name, error in self.errors.items()
)
)
Expand Down
1 change: 0 additions & 1 deletion auth_jwt/models/ir_http.py
Original file line number Diff line number Diff line change
Expand Up @@ -19,7 +19,6 @@


class IrHttpJwt(models.AbstractModel):

_inherit = "ir.http"

@classmethod
Expand Down
3 changes: 3 additions & 0 deletions auth_jwt/pyproject.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
[build-system]
requires = ["whool"]
build-backend = "whool.buildapi"
2 changes: 2 additions & 0 deletions auth_jwt/readme/CONTRIBUTORS.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
- Stéphane Bidoul \<<[email protected]>\>
- Mohamed Alkobrosli \<<[email protected]>\>
1 change: 0 additions & 1 deletion auth_jwt/readme/CONTRIBUTORS.rst

This file was deleted.

File renamed without changes.
1 change: 1 addition & 0 deletions auth_jwt/readme/INSTALL.md
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
This module requires the `pyjwt` library to be installed.
1 change: 0 additions & 1 deletion auth_jwt/readme/INSTALL.rst

This file was deleted.

69 changes: 69 additions & 0 deletions auth_jwt/readme/USAGE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
This module lets developpers add a new `jwt` authentication method on
Odoo controller routes.

To use it, you must:

- Create an `auth.jwt.validator` record to configure how the JWT token
will be validated.
- Add an `auth="jwt_{validator-name}"` or
`auth="public_or_jwt_{validator-name}"` attribute to the routes you
want to protect where `{validator-name}` corresponds to the name
attribute of the JWT validator record.

The `auth_jwt_demo` module provides examples.

The JWT validator can be configured with the following properties:

- `name`: the validator name, to match the `auth="jwt_{validator-name}"`
route property.
- `audience`: a comma-separated list of allowed audiences, used to
validate the `aud` claim.
- `issuer`: used to validate the `iss` claim.
- Signature type (secret or public key), algorithm, secret and JWK URI
are used to validate the token signature.

In addition, the `exp` claim is validated to reject expired tokens.

If the `Authorization` HTTP header is missing, malformed, or contains an
invalid token, the request is rejected with a 401 (Unauthorized) code,
unless the cookie mode is enabled (see below).

If the token is valid, the request executes with the configured user id.
By default the user id selection strategy is `static` (i.e. the same for
all requests) and the selected user is configured on the JWT validator.
Additional strategies can be provided by overriding the `_get_uid()`
method and extending the `user_id_strategy` selection field.

The selected user is *not* stored in the session. It is only available
in `request.uid` (and thus it is the one used in `request.env`). To
avoid any confusion and mismatches between the bearer token and the
session, this module rejects requests made with an authenticated user
session.

Additionally, if a `partner_id_strategy` is configured, a partner is
searched and if found, its id is stored in the `request.jwt_partner_id`
attribute. If `partner_id_required` is set, a 401 (Unauthorized) is
returned if no partner was found. Otherwise `request.jwt_partner_id` is
left falsy. Additional strategies can be provided by overriding the
`_get_partner_id()` method and extending the `partner_id_strategy`
selection field.

The decoded JWT payload is stored in `request.jwt_payload`.

The `public_auth_jwt` method delegates authentication to the standard
Odoo `public` method when the Authorization header is not set. If it is
set, the regular JWT authentication is performed as described above.
This method is useful for public endpoints that need to work for
anonymous users, but can be enhanced when an authenticated user is know.
A typical use case is a "add to cart" endpoint that can work for
anonymous users, but can be enhanced by binding the cart to a known
customer when the authenticated user is known.

You can enable a cookie mode on JWT validators. In this case, the JWT
payload obtained from the `Authorization` header is returned as a
Http-Only cookie. This mode is sometimes simpler for front-end
applications which do not then need to store and protect the JWT token
across requests and can simply rely on the cookie management mechanisms
of browsers. When both the `Authorization` header and a cookie are
provided, the cookie is ignored in order to let clients authenticate
with a different user by providing a new JWT token.
64 changes: 0 additions & 64 deletions auth_jwt/readme/USAGE.rst

This file was deleted.

Loading

0 comments on commit 559b3fe

Please sign in to comment.