Julien Castiaux
06cc322e7e
This commit is the 13th commit of a comprehensive refactor of our HTTP framework. See odoo/odoo#78857 for complete historic, discussions and rationnals. Here be dragons. First and foremost, `http_routing` is a technical module that aim to provide the minimum viable compatibility code between portal and website. Its primary job is to take care of the lang inserted in the path of URLs, e.g. `en` in `/en/my_blog`. Both when routing a request with a lang in the URL and when rendering templates with multilang support. Next to `http_routing` is website, the module used by customers to create pretty web page accessible online. Website uses a different routing logic than the backend, webpages are **not** registered in the routing map of werkzeug but instead delivered by website dedicated code. It means that **all** request targeting a website page thrown at the werkzeug router **fail** with a HTTP 404 error. The reality is that website abuses the fallback mechanism (`_serve_fallback`) to deliver its pages. Using `_serve_fallback` as the standard way to deliver pages is broken by design. It is the least crappy way to deliver content as long as website page don't have a dedicated path prefix. Using a path prefix (e.g. `p` in `/p/fr/mon_blog`) it would have been possible to route the request to a dedicated endpoint using the same router as the backend and with no change to the HTTP dispatching code. Sadly, the business does not want such prefix so we have to stick with a broken design. It is broken because prior to serving a page, website needs to setup A LOT of stuff on the system. It needs to ensure a proper user is set on the environment, it needs to setup the GeoIP database, it also needs to determine the lang the user requested the page and it also needs to save multiple attributes on the request objet itself (`is_frontend`, `is_frontend_multilang`, `routing_iteration`, `website`, `lang`, `rerouting` and `website_routing`). Since `base/ir.http@_match()` will fail, everything must be set either prior to calling this method or in `website/ir.http@_serve_fallback`. --- The original implementation was overriding the `_dispatch` method which was responsible to call the four `_match()`, `_authenticate()`, `_postprocess_args` and finally `WebRequest._dispatch()`. The override was very special, here is an attempt to explain it: 1) try to match an endpoint using the backend router, 404-errors are ignored. 2) include the geoip stuff. 3) authenticate using the `auth` @route argument if an endpoint matched in (1), otherwise authenticate with the public user. 4) if not endpoint matched or if a frontend endpoint matched in (1): a) call `_add_dispatch_parameters` which sets many arguments on the `request` object, including the lang found in the request cookies b) try to extract a lang from the URL: abort with a redirection when the lang is missing or wrong, remove the lang from the request path when it is set (updating both `request.lang` and the cookie). 5) return the result of `super()._dispatch()` Note that `_serve_fallback()` is called during `super()._dispatch()` when the path still does not route to an endpoint. Thanks to the `_dispatch` overrides in http_routing and website, it is garanteed that the system is setup prior to calling `_serve_fallback`. --- Because it is now `http.py@Request._serve_ir_http()` that is responsible of calling the four`_match()`, `_authenticate()`, `_pre_dispatch` and finally `_(http|json)_dispatch()` it is no more possible to override it to take over the dispatching to perform the http_routing/website magic. The prior implementation can not work with the new design thus is has been refactored too. To render a website page, there must be a user configured on the environment (not None) and the various special attributes must be set on the request object. The special `lang` attribute is popped from the request path but backend endpoints must be delivered in priority. Using the new design, it has been decided to override the `_match` method to implement the lang-in-path logic, to override both `_pre_dispatch` and `_serve_fallback` to call `_add_dispatch_parameters` which have been renamed `_frontend_pre_dispatch` and to also grant the public user in the `_serve_fallback` override. The `_handle_error` override in website has similar needs, the function is called upon error (4xx/5xx) in order to render a pretty website-looking page. Because such error can occurs as early as in `_match()` (page not found and no fallback), when nothing has been setup yet, website is yet again responsible for setuping everything: request, orm, frontend. Many other small improvement are not described here. Hopefully the added comments in the source code are enought. PR: odoo#78857 Task: 2571224
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
To learn the software, we recommend the Odoo eLearning, or Scale-up, the business game. Developers can start with the developer tutorials