Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat(monitoring-tool): password-protected forms #311

Open
chrismclarke opened this issue Jul 31, 2024 · 0 comments · May be fixed by #328
Open

feat(monitoring-tool): password-protected forms #311

chrismclarke opened this issue Jul 31, 2024 · 0 comments · May be fixed by #328
Assignees

Comments

@chrismclarke
Copy link
Collaborator

chrismclarke commented Jul 31, 2024

Is your feature request related to a problem? Please describe.
Currently any user can access any monitoring form and submit results. Ideally we should have a means of restricting who can access specific forms

Describe the solution you'd like
As we don't plan to impose user login the only way to restrict would be an input-based system where the user first has to unlock the form via some sort of password/access code

  1. Update the monitoring schema for a v4 version that includes optional access_code and access_unlocked properties. access_code should be a string and access_unlocked a boolean value. There shouldn't be any need to provide migration code as default values for access code and unlocked properties are fine to leave as undefined (default forms to not have code)
  2. Create a new hardcoded form for testing. This can be mostly just a copy of any of the existing forms, but specify an access code (can leave unlocked as undefined). Recommend using the code "picsa" for simple testing
  3. Update forms home page to display locked forms with a lock symbol (where locked is calculated by a form both having an access code and not being marked as access unlocked)
  4. Add dialog/modal to allow user to input an unlock code when clicking on a locked form. Handle database update to mark access_unlocked true.
  5. Update the form display page to display the same form unlock input instead of the form in case the user has navigated directly to a form by url (and bypassed the list page)

Additional context

  • Monitoring schema in apps\picsa-tools\monitoring-tool\src\app\schema
  • Monitoring hardcoded forms in apps\picsa-tools\monitoring-tool\data\forms

We will likely need to consider in the future how to make the access codes more secure, e.g. using some form of hashing so the access_code is stored as a hashed string and we can check if the input a user specifies corresponds to the expected unlock code after passing through the same hashing algorithm.

@chrismclarke chrismclarke moved this to Next Priority in PICSA Apps Development Jul 31, 2024
@OchiengPaul442 OchiengPaul442 linked a pull request Sep 21, 2024 that will close this issue
@chrismclarke chrismclarke moved this from Next Priority to In Progress in PICSA Apps Development Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: In Progress
Development

Successfully merging a pull request may close this issue.

2 participants