Most Odoo deployments trust any device that presents a valid password, so a leaked credential, a phished login, or a reused session cookie can reach your ERP from anywhere on the internet. Odoo core gives you strong password policies, optional two-factor authentication, and group-based access rights via ir.model.access.csv and record rules — but it has no native concept of a network boundary. Nothing in the standard product lets you say "the accounting team may only authenticate from the office range, the API integration user only from our fixed server IP, and administrators only from the VPN." Auditors, ISO 27001 programs, and many finance and healthcare mandates expect exactly that network-layer control, and out of the box Odoo simply cannot enforce it.

Access Restriction By IP is the build-to-order module ECOSIRE designs to close that gap. We build an allowlist engine that hooks the authentication flow (res.users._login / _check_credentials plus session validation) so that after credentials pass, the request's source IP is evaluated against your rules before a session is granted. Rules live on new models (for example ecosire.ip.rule) with fields.Char CIDR entries validated by an @api.constrains using Python's ipaddress library, linked many2many to res.users and res.groups, and administered from clean backend views (XML/OWL list and form) governed by ir.model.access.csv and record rules so only security administrators can edit them. The engine reads the true client IP — honoring X-Forwarded-For and your --proxy-mode / reverse-proxy topology so Nginx or Cloudflare in front of Odoo does not mask the real address — and resolves per-user rules over per-group rules with a configurable default-allow or default-deny posture.

Because it operates at the authentication layer rather than the routing layer, the restriction covers the web client, the login controller, and — where you require it — the XML-RPC / JSON-RPC API, so a scripted integration cannot bypass the browser rules. Every blocked attempt can be written to a log model and surfaced through an optional automated action or email alert, giving you the audit trail assessors ask for. We keep superuser and a break-glass recovery path explicit so a misconfigured range can never lock your entire company out, and we tune behavior for Community vs Enterprise (Enterprise adds features like the built-in auth_totp two-factor that this module complements rather than replaces).

Delivery is build-to-order: we start with a short scoping call, agree the exact rule model, proxy topology, and lock-out safeguards, then build against your Odoo 17.0, 18.0, or 19.0 version, validate on a staging clone with your real network ranges, and deploy with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. Pricing starts from $249 (indicative, single-company base scope); multi-company IP policies, reverse-proxy and geo-IP integrations, per-database rule sets, and deeper audit-logging requirements increase the quoted scope.