[MIG] auth_jwt: Migration to 17.0

auth_jwt/README.rst

@@ -7,7 +7,7 @@ Auth JWT
    !! This file is generated by oca-gen-addon-readme !!
    !! changes will be overwritten.                   !!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-   !! source digest: sha256:d22309ac82ef1eb8879974683b10d4be288eb330fd7e250927f1a8d602dc3988
+   !! source digest: sha256:608e8780fabb7f7a32193245dd2a7e594810863dcc55aa1dc9e5b2bc3426d74c
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 
 .. |badge1| image:: https://img.shields.io/badge/maturity-Beta-yellow.png
@@ -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|
@@ -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.
 
@@ -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.

auth_jwt/__manifest__.py

@@ -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"],
@@ -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,
 }

auth_jwt/exceptions.py

@@ -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()
             )
         )

auth_jwt/i18n/auth_jwt.pot

@@ -4,7 +4,7 @@
 #
 msgid ""
 msgstr ""
-"Project-Id-Version: Odoo Server 16.0\n"
+"Project-Id-Version: Odoo Server 17.0\n"
 "Report-Msgid-Bugs-To: \n"
 "Last-Translator: \n"
 "Language-Team: \n"
@@ -176,11 +176,6 @@ msgstr ""
 msgid "Key"
 msgstr ""
 
-#. module: auth_jwt
-#: model:ir.model.fields,field_description:auth_jwt.field_auth_jwt_validator____last_update
-msgid "Last Modified on"
-msgstr ""
-
 #. module: auth_jwt
 #: model:ir.model.fields,field_description:auth_jwt.field_auth_jwt_validator__write_uid
 msgid "Last Updated by"

auth_jwt/i18n/es.po

@@ -187,11 +187,6 @@ msgstr "¡Los nombres de los validadores JWT deben ser únicos!"
 msgid "Key"
 msgstr "Clave"
 
-#. module: auth_jwt
-#: model:ir.model.fields,field_description:auth_jwt.field_auth_jwt_validator____last_update
-msgid "Last Modified on"
-msgstr "Última Modificación el"
-
 #. module: auth_jwt
 #: model:ir.model.fields,field_description:auth_jwt.field_auth_jwt_validator__write_uid
 msgid "Last Updated by"
@@ -355,3 +350,6 @@ msgstr "Los validadores no deben hacer una cadena cerrada: {}."
 #: model_terms:ir.ui.view,arch_db:auth_jwt.view_auth_jwt_validator_form
 msgid "arch"
 msgstr "arch"
+
+#~ msgid "Last Modified on"
+#~ msgstr "Última Modificación el"

auth_jwt/i18n/it.po

@@ -184,11 +184,6 @@ msgstr "I nomi dei validatori JWT devono essere univoci!"
 msgid "Key"
 msgstr "Chiave"
 
-#. module: auth_jwt
-#: model:ir.model.fields,field_description:auth_jwt.field_auth_jwt_validator____last_update
-msgid "Last Modified on"
-msgstr "Ultima modifica il"
-
 #. module: auth_jwt
 #: model:ir.model.fields,field_description:auth_jwt.field_auth_jwt_validator__write_uid
 msgid "Last Updated by"
@@ -352,3 +347,6 @@ msgstr "I validatori non devono creare una catena chiusa: {}."
 #: model_terms:ir.ui.view,arch_db:auth_jwt.view_auth_jwt_validator_form
 msgid "arch"
 msgstr "arch"
+
+#~ msgid "Last Modified on"
+#~ msgstr "Ultima modifica il"

auth_jwt/models/ir_http.py

@@ -19,7 +19,6 @@
 
 
 class IrHttpJwt(models.AbstractModel):
-
     _inherit = "ir.http"
 
     @classmethod

auth_jwt/pyproject.toml

@@ -0,0 +1,3 @@
+[build-system]
+requires = ["whool"]
+build-backend = "whool.buildapi"

auth_jwt/readme/CONTRIBUTORS.md

@@ -0,0 +1,2 @@
+- Stéphane Bidoul \<<[email protected]>\>
+- Mohamed Alkobrosli \<<[email protected]>\>

auth_jwt/readme/INSTALL.md

@@ -0,0 +1 @@
+This module requires the `pyjwt` library to be installed.

auth_jwt/readme/USAGE.md

@@ -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.