Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: External access token expiration
byDear,
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 expiration
Dear 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
