Merge pull request OCA#503 from OCA/17.0

Syncing from upstream OCA/server-auth (17.0)

Author: bt-admin

README.md

@@ -23,7 +23,7 @@ addon | version | maintainers | summary
 --- | --- | --- | ---
 [auth_admin_passkey](auth_admin_passkey/) | 17.0.1.0.0 |  | Allows system administrator to authenticate with any account
 [auth_admin_passkey_totp_mail_enforce](auth_admin_passkey_totp_mail_enforce/) | 17.0.1.0.0 |  | Disable 2FA if Passkey is being used
-[auth_api_key](auth_api_key/) | 17.0.1.1.0 |  | Authenticate http requests from an API key
+[auth_api_key](auth_api_key/) | 17.0.1.1.1 |  | Authenticate http requests from an API key
 [auth_api_key_group](auth_api_key_group/) | 17.0.1.0.1 | [![simahawk](https://github.com/simahawk.png?size=30px)](https://github.com/simahawk) | Allow grouping API keys together. Grouping per se does nothing. This feature is supposed to be used by other modules to limit access to services or records based on groups of keys.
 [auth_api_key_server_env](auth_api_key_server_env/) | 17.0.1.0.0 |  | Configure api keys via server env. This can be very useful to avoid mixing your keys between your various environments when restoring databases. All you have to do is to add a new section to your configuration file according to the following convention:
 [auth_oidc](auth_oidc/) | 17.0.1.0.0 | [![sbidoul](https://github.com/sbidoul.png?size=30px)](https://github.com/sbidoul) | Allow users to login through OpenID Connect Provider

auth_api_key/README.rst

@@ -7,7 +7,7 @@ Auth Api Key
    !! This file is generated by oca-gen-addon-readme !!
    !! changes will be overwritten.                   !!
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-   !! source digest: sha256:5baa940e682e7653045bd8939d27f501b2409da7a9b3ec1ca80597eb2b79e7b7
+   !! source digest: sha256:ae78e8c4442001a4d138783fb1c46e4ad153932b5b8ca56333b08e21cdfbeaef
    !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
 
 .. |badge1| image:: https://img.shields.io/badge/maturity-Production%2FStable-green.png
@@ -41,6 +41,19 @@ from known sources.
 For unknown sources, it is a good practice to filter out this header at
 proxy level.
 
+Odoo allows users to authenticate ``XMLRPC/JSONRPC`` calls using their
+API key instead of a password by native API keys (``res.users.apikey``).
+However, ``auth_api_key`` has some special features of its own such as:
+
+-  API keys remain usable even when the user is inactive, if enabled via
+   settings (e.g., for system users in a shopinvader case).
+-  Supports dual authentication via Basic Auth and API_KEY in separate
+   HTTP headers.
+-  Admins can manage API keys for all users
+
+Given these advantages, particularly in use case like system user
+authentication, we have decided to keep the ``auth_api_key`` module
+
 **Table of contents**
 
 .. contents::

auth_api_key/__manifest__.py

@@ -5,7 +5,7 @@
     "name": "Auth Api Key",
     "summary": """
         Authenticate http requests from an API key""",
-    "version": "17.0.1.1.0",
+    "version": "17.0.1.1.1",
     "license": "LGPL-3",
     "author": "ACSONE SA/NV,Odoo Community Association (OCA)",
     "website": "https://github.com/OCA/server-auth",

auth_api_key/readme/DESCRIPTION.md

@@ -10,3 +10,10 @@ from known sources.
 
 For unknown sources, it is a good practice to filter out this header at
 proxy level.
+
+Odoo allows users to authenticate `XMLRPC/JSONRPC` calls using their API key instead of a password by native API keys (`res.users.apikey`). However, `auth_api_key` has some special features of its own such as:
+- API keys remain usable even when the user is inactive, if enabled via settings (e.g., for system users in a shopinvader case).
+- Supports dual authentication via Basic Auth and API_KEY in separate HTTP headers.
+- Admins can manage API keys for all users
+
+Given these advantages, particularly in use case like system user authentication, we have decided to keep the `auth_api_key` module

auth_api_key/static/description/index.html

@@ -367,7 +367,7 @@ <h1 class="title">Auth Api Key</h1>
 !! This file is generated by oca-gen-addon-readme !!
 !! changes will be overwritten.                   !!
 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-!! source digest: sha256:5baa940e682e7653045bd8939d27f501b2409da7a9b3ec1ca80597eb2b79e7b7
+!! source digest: sha256:ae78e8c4442001a4d138783fb1c46e4ad153932b5b8ca56333b08e21cdfbeaef
 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! -->
 <p><a class="reference external image-reference" href="https://odoo-community.org/page/development-status"><img alt="Production/Stable" src="https://img.shields.io/badge/maturity-Production%2FStable-green.png" /></a> <a class="reference external image-reference" href="http://www.gnu.org/licenses/lgpl-3.0-standalone.html"><img alt="License: LGPL-3" src="https://img.shields.io/badge/licence-LGPL--3-blue.png" /></a> <a class="reference external image-reference" href="https://github.com/OCA/server-auth/tree/17.0/auth_api_key"><img alt="OCA/server-auth" src="https://img.shields.io/badge/github-OCA%2Fserver--auth-lightgray.png?logo=github" /></a> <a class="reference external image-reference" href="https://translation.odoo-community.org/projects/server-auth-17-0/server-auth-17-0-auth_api_key"><img alt="Translate me on Weblate" src="https://img.shields.io/badge/weblate-Translate%20me-F47D42.png" /></a> <a class="reference external image-reference" href="https://runboat.odoo-community.org/builds?repo=OCA/server-auth&amp;target_branch=17.0"><img alt="Try me on Runboat" src="https://img.shields.io/badge/runboat-Try%20me-875A7B.png" /></a></p>
 <p>Authenticate http requests from an API key.</p>
@@ -379,6 +379,18 @@ <h1 class="title">Auth Api Key</h1>
 from known sources.</p>
 <p>For unknown sources, it is a good practice to filter out this header at
 proxy level.</p>
+<p>Odoo allows users to authenticate <tt class="docutils literal">XMLRPC/JSONRPC</tt> calls using their
+API key instead of a password by native API keys (<tt class="docutils literal">res.users.apikey</tt>).
+However, <tt class="docutils literal">auth_api_key</tt> has some special features of its own such as:</p>
+<ul class="simple">
+<li>API keys remain usable even when the user is inactive, if enabled via
+settings (e.g., for system users in a shopinvader case).</li>
+<li>Supports dual authentication via Basic Auth and API_KEY in separate
+HTTP headers.</li>
+<li>Admins can manage API keys for all users</li>
+</ul>
+<p>Given these advantages, particularly in use case like system user
+authentication, we have decided to keep the <tt class="docutils literal">auth_api_key</tt> module</p>
 <p><strong>Table of contents</strong></p>
 <div class="contents local topic" id="contents">
 <ul class="simple">