Archives
Contributors
Re: External access token expiration
> Did anyone here face a similar requirement? How did you handle it? > Ideally, we would need a single token to be generated per e-mail being sent > so that we can define the expiration of said token, but it seems like > there's no other solution than to overwrite and redefine everything, what I > would prefer to avoid to ease maintenance of such a module. Thanks for > sharing your insights. are you aware of the poisoning the cache technique? you can do things like def _notify_get_groups(self, msg_vals=None): self._cache['access_token'] = 'whatever you need for your workflow' return super()._notify_get_groups(msg_vals=msg_vals) and given super won't initiate a new database read, it will stick with whatever you put in the cache, as that's where the ORM reads values from first. I read through your whole thing because I'm a weird kind of nerd, for other people to read it I suggest to start with a TLDR on the beginning so that people can filter if they're interested or not. -- Your partner for the hard Odoo problems https://hunki-enterprises.com_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Akim Juillerat - 05:56 - 12 Jan 2024
Reference
-
External access token expiration
Dear communityWith portal module installed, Odoo can send links to documents by e-mail using an access token so that the recipient doesn't need a portal user to see said documents.The token is handled in the portal.mixin https://github.com/odoo/odoo/blob/15.0/addons/portal/models/portal_mixin.py#L15Access to the document is handled through this controller: https://github.com/odoo/odoo/blob/15.0/addons/portal/controllers/mail.py#L206Now, it's been multiple time customer are requiring to expire this token one way or another, because in standard Odoo the document stays accessible forever. The only solutions I could come up with without having to change everything are described below (extracted from personal notes):
That means, to restrict the validity of the token that was sent in the mail, the token set on the record that is accessed needs to change after a "validity period". The issue with this, is if the link for a same record is sent multiple times during a single "validity period", the availability will not be the same. For example, if we want to define that access tokens are recomputed every 30 days, someone receiving an e-mail 5 days after the token was recomputed would be able to access the document for 25 days, and someone receiving an e-mail 25 days after the token was recomputed would be able to access it only for 5 days.
A slightly better solution without changing everything but probably more tricky to implement properly, would be to add a new Datetime field next_access_token_refresh on portal.mixin (or another mixin to be inherited on selected models in order to control the application by model) and set it XXX days in the future (according to a server parameter) each time we need to set the access token in an email. If we define the availability to 30 days, that means if a mail is sent to access the same document to a first external user today and to a second external user in 15 days, the first external user would be able to access it during a period of 45 days.
Did anyone here face a similar requirement? How did you handle it?
Ideally, we would need a single token to be generated per e-mail being sent so that we can define the expiration of said token, but it seems like there's no other solution than to overwrite and redefine everything, what I would prefer to avoid to ease maintenance of such a module.
Thanks for sharing your insights.
camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSAkim JuilleratBusiness solutionsSoftware architect
by Akim Juillerat - 07:46 - 11 Jan 2024