[trunk-website-al] ir_rule#_compute_domain caching destroys anonymous browsing for ecommerce
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Odoo Server (MOVED TO GITHUB) |
In Progress
|
High
|
OpenERP's Framework R&D |
Bug Description
Hello,
How to reproduce:
on a fresh installation with demo data of server, addons and web trunk-website-al branches or on runbot here:
http://
go in the /shop web module. Eventually log as public/public if you pass through the web interface.
try to add some e-commerce product to the shopping cart:
you may get a 403 error.
In fact, the very first browser session that try to connect to the shopping cart, will be able use the shopping cart.
BUT any subsequent session (it's likely your aren't the first on the runbot) will get the bug.
if you don't know how to create a new session, use your browser in anynomous mode and browse again for instance.
Why?
It because in the sale.order read, there is a domain like:
['(("sale_
but in the evaluation, website_session_id will be always evaled to the website_session_id of the first website user that browsed the page as public/public.
This is because in openerp/
it will enter around line 106 in:
@tools.
def _compute_
if mode not in self._MODES:
raise ValueError('Invalid mode: %r' % (mode,))
But the issue is the tools.ormcache decorator will cache the domain result param according to the explicit entry params of the _compute_domain method but without any consideration for the werkzeug session params such as website_session_id. Hence all different users get the same domain despite they use the same session so they'will miss there sale.order because they will look for it with a website_session_id that isn't theirs...
A simple way to ensure the bug is as I described is to simply remove @tools.ormcache(). Now users can see their cart information normally.
I imagine you should craft some tools.ormcache decorator that will take the session_id into account, but I'm not sure how bad will be the performance impact of that. Obviously it will badly hit the ability to mutualize the cache accross the portal users...
Still it seems somewhat required.
That leads to my considerations that the caching should move to the frontend web framework wherever possible and that may be trying to reinvent the wheel in the CMS part wasn't that great as you'll need to reinvent all that without a big skilled developer base to test and make it.
In any case I prefer your approach of a single portal user with that dynamic domain matching according to the session so please don't abandon to get a flood of ERP users for all portal users or something crazy like that.
Hope this helps and kudos for the shopping cart job and framework improvement around this and best wishes of success for 2014.
Changed in openobject-server: | |
assignee: | nobody → OpenERP's Framework R&D (openerp-dev-framework) |
I raphael, I just test it and reproduce it.
Hope this will change soon :)