Archives
Contributors
External access token expiration
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.
by Akim Juillerat - 07:46 - 11 Jan 2024
Follow-Ups
-
Re: External access token expiration
Thanks JohanIt's also a solution I had in mind but one I wanted to avoid. Anyway, I guess it will be the only option to have something reliable and that we can control over time.camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSAkim JuilleratBusiness solutionsSoftware architectOn Fri, Jan 12, 2024 at 10:57 AM Johan Van Hirtum <notifications@odoo-community.org> wrote:
Dear,
I don’t use this. But I would make the token field on the document a ‘to many’ field. You create a token, each time you send a document. The tokens get a expire field. And a simple cron job deletes each day the expired tokens. This gives you the required function with little rewrite and practical no penalties : the solution stay the same for the user, there is practically no extra memory or processing needed. So this could maybe be the standard for this modules -)
With kind regards,
Van Hirtum Johan
Van: Akim Juillerat [mailto:notifications@odoo-community.org]
Verzonden: donderdag 11 januari 2024 19:48
Aan: Contributors
Onderwerp: External access token expirationDear community
With 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#L15
Access to the document is handled through this controller: https://github.com/odoo/odoo/blob/15.0/addons/portal/controllers/mail.py#L206
Now, 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 (extracte d 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.
camptocamp
INNOVATIVE SOLUTIONS
BY OPEN SOURCE EXPERTS
Akim Juillerat
Business solutions
Software architect
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe_______________________________________________
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 -
Re: External access token expiration
Thanks Holger for your answer.I'm not sure it would work in our case if said e-mail has to be sent multiple times, but it's an interesting technique I'll try to keep in mind for a later use.camptocampINNOVATIVE SOLUTIONSBY OPEN SOURCE EXPERTSAkim JuilleratBusiness solutionsSoftware architectOn Thu, Jan 11, 2024 at 9:52 PM Holger Brunn <notifications@odoo-community.org> wrote:
> 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 -
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
by Holger Brunn - 09:51 - 11 Jan 2024