Contributors mailing list archives
contributors@odoo-community.org
Browse archives
External access token expiration
byThat 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.
