RPC & API Key Access Control for Odoo | XML-RPC & JSON-RPC User Allowlist | Restrict External API Access | API Login Audit Log
by CODEerts https://www.codeerts.com$ 44.99
RPC & API Key Access Control
Decide which users may reach the database over XML-RPC, JSON-RPC or
an API key, with a per-user allowlist, an audit log and a global kill switch.
Gates the XML-RPC, JSON-RPC and API key authentication paths. Denies by default. Logs every attempt. Never locks you out.
|
3
Operating Modes
|
2
Authentication Gates
|
Per User
Access Control
|
1 Click
Global Kill Switch
|
v17
Compatible
|
The API gap every Odoo administrator inherits
Odoo ships with the door wide open. You lock it.
Here is what native Odoo leaves unprotected, and exactly how this module closes each gap.
|
The problem
Every user is an API user by default
Any internal user who knows their login and password can authenticate over XML-RPC and JSON-RPC. Odoo has no per-user toggle to turn this off, and the authentication path carries no policy check. |
The problem
API keys grant even wider access
A bearer token or Outlook plugin key bypasses the login form and identifies as a real internal user. Without a gate on the bearer path, every user with an API key has unguarded external access. |
The problem
Failed logins leave no trace
Failed XML-RPC authentications are invisible in Odoo's standard audit tools, and core applies no cooldown on the RPC path. An attacker gets unlimited password attempts with no record of the activity. |
|
How this module fixes it
A per-user API access toggle
Two checkboxes on every user form: API Access Allowed and API Keys Only. Turn access on for the two users who need it and leave it off for everyone else. No new groups, no complex rules. |
How this module fixes it
Dual-gate covers both paths
Gate A sits on the RPC credential check and catches XML-RPC and JSON-RPC password logins, and refuses the login itself, so common.login no longer confirms that a blocked user's credentials are valid. Logins made through a browser are never affected. Gate B on Odoo's HTTP authentication hook catches Outlook plugin API keys. Password and API key logins are both covered. |
How this module fixes it
Every attempt is logged
A searchable audit log records who tried, over which protocol, with which auth method, and whether it was allowed or blocked. Brute-force attacks fold into one row with a hit count so the log stays lean. |
What this module does
CODEerts RPC & API Key Access Control puts a policy gate on Odoo's XML-RPC, JSON-RPC and API key authentication paths. It ships in Monitor mode so nothing is blocked on install: open the audit log, watch who connects for a day or two, then switch to Enforce when you are ready. A global kill switch blocks all XML-RPC, JSON-RPC and API key access in one click, settings users are permanently exempt from both gates, and every allowed and blocked attempt is written to a searchable audit log with automatic retention cleanup.
Two authentication gates cover the RPC and API key paths. Gate A sits on the RPC credential check and catches XML-RPC and JSON-RPC password logins, and refuses the login itself, so common.login no longer confirms that a blocked user's credentials are valid. Logins made through a browser are never affected. Gate B on Odoo's HTTP authentication hook catches Outlook plugin API keys. The audit log uses an atomic fold so a brute-force attack writes one entry with an incrementing hit count, not ten thousand rows.
|
⚙ Three Operating Modes
Disabled, Monitor and Enforce. Monitor logs what would happen without blocking, so you see the real impact before you switch. Audit log entries carry a would_block result distinct from a real block. |
🔒 Per-User Allowlist
Two checkboxes on every user form: API Access Allowed and API Keys Only. Turn access on for the users who need it, leave it off for everyone else. No new groups or complex rules. |
|
🔑 API-Keys-Only Mode
Per user: require an API key and refuse password-based API authentication. The user can still log in through the web UI with their password; only external API calls are gated. |
🎯 Dual-Gate Architecture
Gate A catches XML-RPC and JSON-RPC password logins through the RPC credential check. Gate B catches Outlook plugin API key authentications through ir.http. Both are covered by the same policy. |
|
🚨 Global Kill Switch
One checkbox in General Settings blocks all XML-RPC, JSON-RPC and API key access immediately, even for allowed users. The audit log records the kill_switch reason so you can tell the two apart. |
🛠 Settings Users Exempt
Any user in the Administration / Settings group bypasses the gate entirely. You can never lock yourself out of your own database by misconfiguring the module. |
|
📋 Full Audit Log
Every allowed and blocked API login is recorded with the user, protocol, auth method and reason. Protected by CSV ACL so only the Administration group can read it. |
🗄 DoS-Resistant Logging
Identical outcomes in a five-minute window fold onto one row with a hit count via atomic ON CONFLICT. A brute-force attack writes one entry, not ten thousand. |
One module, both RPC authentication paths covered
|
📡
Monitor
Log without blocking |
🛡
Enforce
Block with AccessDenied |
👥
Per User
Access toggle on form |
🔑
Keys Only
Refuse passwords |
|
⚡
Kill Switch
Global shutoff |
📋
Audit Log
Searchable trail |
🛠
Safe by Design
Admin exempt |
🧹
Retention
Auto cleanup |
Screenshots
See it in action across settings, the user form, and the full audit trail.
Choose Disabled, Monitor or Enforce, set the log retention in days, and toggle the global kill switch in one place.
A new API Access tab on every user form carries the API Access Allowed checkbox and the API Keys Only toggle. Settings users are always exempt.
Every allowed and blocked API login is recorded with the user, protocol, auth method and reason. Identical outcomes fold onto one row with a hit count inside a five-minute window.
Open any row to see the user, protocol, auth method, outcome, reason and hit count, plus who created the entry and when.
How it works
1 |
Install and stay in Monitor mode
The module installs in Monitor mode. Nothing is blocked yet, but every API call is already being logged with a would_block or allowed verdict. Open the audit log and watch for a few hours to see who is connecting. |
2 |
Open the gate for users who need it
On each user form, check API Access Allowed. Turn on API Keys Only for the ones who should never authenticate with a password over the API. Settings users are already exempt. |
3 |
Switch to Enforce
Change the mode in General Settings. Every denied call now raises AccessDenied. The audit log keeps recording every blocked and allowed attempt. |
4 |
Review the audit trail and adjust
The audit log is searchable and protected by CSV ACL. Old entries are cleaned up automatically on the retention schedule you set in Settings. Toggle the kill switch any time for an instant global shutoff. |
Technical information
|
Version
19.0
|
License
OPL-1
|
Editions
Community & Enterprise
|
Dependencies
base, base_setup
|
Technical name: codeerts_api_access_control · Gates: the RPC credential check (XML-RPC / JSON-RPC) + Odoo's HTTP authentication hook (bearer / Outlook)
Frequently asked questions
No. The module only gates external API authentication: XML-RPC, JSON-RPC, API key bearer tokens and Outlook plugin keys. Regular web login through /web/login is not affected, and the API-keys-only toggle only applies to API calls, not the web UI.
No. Any user in the Administration / Settings group is permanently exempt from the gate. As long as at least one admin account can log in, you can always reach the settings and the user forms to fix a misconfiguration.
Yes, every call that reaches the gate is recorded. However, identical outcomes for the same user in the same five-minute window fold onto a single row with an incrementing hit count, so a brute-force attack writes one entry, not ten thousand.
Nothing that affects authentication. The audit writer opens its own database connection, and every failure is caught and logged to the server log only. A deadlock on the log table or a full disk will never surface as an AccessDenied for a legitimate user.
Yes. The module has no external dependencies and uses only core Odoo APIs. It works on Odoo Online, Odoo.sh and on-premise deployments running Odoo 17, 18 or 19, Community and Enterprise editions.
The team behind this module
About CODEerts
Full-Service Odoo ERP Company · Solutions That Scale
Every module in our store is built from real client work, tested in production and maintained long-term by a team of experienced Odoo consultants. When you need more than an app, we deliver the full solution.
|
🏗️ Implementation
Full Odoo roll-outs from requirements to go-live, across any industry and company size. |
🧩 Custom Development
Bespoke modules, OWL components and business logic built precisely to your workflow. |
🔄 Migrations
Zero-data-loss upgrades from older Odoo versions with full custom module porting. |
|
🔌 Integrations
Payment gateways, shipping carriers, biometric devices, eCommerce and third-party APIs. |
🔍 Odoo Audits
Performance, security and code-quality reviews that surface risks before they become problems. |
🧑💻 Support & Training
Ongoing helpdesk, user training and monthly retainers so your team stays productive. |
|
Odoo
Experts
|
6+
Years
|
50+
Projects
|
10+
Industries
|
90+
Published Apps
|
More from CODEerts
Other apps we build to make Odoo do more. Tap any card to open it on the Odoo Apps Store.
 FREE Archive Anything |  FREE Transaction Flow Visualizer |  FREE Smart Mail Rebrand |  FREE Duplicate Record Detector |
 AI Dashboard Builder |  Advance Payment Pro |  Advance Payment Management |  Activity Dashboard |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Lines of code | 541 |
| Technical Name |
codeerts_api_access_control |
| License | OPL-1 |
| Website | https://www.codeerts.com |
Odoo Proprietary License v1.0 This software and associated files (the "Software") may only be used (executed, modified, executed after modifications) if you have purchased a valid license from the authors, typically via Odoo Apps, or if you have received a written agreement from the authors of the Software (see the COPYRIGHT file). You may develop Odoo modules that use the Software as a library (typically by depending on it, importing it and using its resources), but without copying any source code or material from the Software. You may distribute those modules under the license of your choice, provided that this license is compatible with the terms of the Odoo Proprietary License (For example: LGPL, MIT, or proprietary licenses similar to this one). It is forbidden to publish, distribute, sublicense, or sell copies of the Software or modified copies of the Software. The above copyright notice and this permission notice must be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Please log in to comment on this module