This is a Feature Proposal
🎩 Description
TLDR: Support for short-term and feature related authorizations would boost reusability of Decidim modules.
Authorizations are a great feature to allow Decidim instances to relate participatory actions to custom code that allows identify users. But authorizations are intended to be executed few times and in a global context (you can't know inside the authorization handler which feature is the user dealing with).
We are facing cases very similar to those solved by authorizations (custom code to answer an authorization request related to participatory actions) but with a much smaller scope: only for a small period of time and for an specific feature. Some examples of this are related to our secure voting scenario:
- A two factor authentication based on SMS's is used every time the user wants to enter to the voting booth.
- Some votings are related to an scope. The system needs to check that the user was related to that scope at the moment of the "census closure". This could be done calling an external API that has that information.
When creating a module that implements secure votings we have two options: implement all these traits inside the module or define feature actions, that can be related to different authorizations handlers for each feature instance. The second option is more versatile and would allow us to create more reusable modules, but would require core changes on authorizations system.
These "new" authorizations would be related to a feature instance, would not be displayed in user profile page and will probably have an expiration date.
📌 Related issues
📋 Additional Data
- Decidim deployment where you found the issue:
- Browser & version:
- Screenshot:
- Error messages:
- URL to reproduce the error:
This is a Feature Proposal
🎩 Description
TLDR: Support for short-term and feature related authorizations would boost reusability of Decidim modules.
Authorizations are a great feature to allow Decidim instances to relate participatory actions to custom code that allows identify users. But authorizations are intended to be executed few times and in a global context (you can't know inside the authorization handler which feature is the user dealing with).
We are facing cases very similar to those solved by authorizations (custom code to answer an authorization request related to participatory actions) but with a much smaller scope: only for a small period of time and for an specific feature. Some examples of this are related to our secure voting scenario:
When creating a module that implements secure votings we have two options: implement all these traits inside the module or define feature actions, that can be related to different authorizations handlers for each feature instance. The second option is more versatile and would allow us to create more reusable modules, but would require core changes on authorizations system.
These "new" authorizations would be related to a feature instance, would not be displayed in user profile page and will probably have an expiration date.
📌 Related issues
📋 Additional Data