Mercurial > p > roundup > code
comparison doc/upgrading.txt @ 8411:ef1ea918b07a reauth-confirm_id
feat(security): Add user confirmation/reauth for sensitive changes
Auditors can raise Reauth(reason) exception to require the user to
enter a token (e.g. account password) to verify the user is performing
the change.
Naming is subject to change.
actions.py: New ReauthAction class handler and verifyPassword() method
for overriding if needed.
client.py: Handle Reauth exception by calling Client:reauth() method.
Default client:reauth method. Add 'reauth' action declaration.
exceptions.py: Define and document Reauth exception as a subclass of
RoundupCGIException.
templating.py: Define method utils.embed_form_fields().
The original form making a change to the database has a lot of form
fields. These need to be resubmitted to Roundup as part of the form
submission that verifies the user's password.
This method turns all non file form fields into type=hidden inputs.
It escapes the names and values to prevent XSS.
For file form fields, it base64 encodes the contents and puts them
in hidden pre blocks. The pre blocks have data attributes for the
filename, filetype and the original field name. (Note the original
field name is not used.)
This stops the file content data (maybe binary e.g. jpegs) from
breaking the html page. The reauth template runs JavaScript that
turns the encoded data inside the pre tags back into a file. Then
it adds a multiple file input control to the page and attaches all
the files to it. This file input is submitted with the rest of the
fields.
_generic.reauth.html (multiple tracker templates): Generates a form
with id=reauth_form to:
display any message from the Reauth exception to the user (e.g. why
user is asked to auth).
get the user's password
submit the form
embed all the form data that triggered the reauth
recreate any file data that was submitted as part of the form and
generate a new file input to push the data to the back end
It has the JavaScript routine (as an IIFE) that regenerates a file
input without user intervention.
All the TAL based tracker templates use the same form. There is also
one for the jinja2 template. The JavaScript for both is the same.
reference.txt: document embed_form_fields utility method.
upgrading.txt: initial upgrading docs.
TODO:
Finalize naming. I am leaning toward ConfirmID rather than Reauth.
Still looking for a standard name for this workflow.
Externalize the javascript in _generic.reauth.html to a seperate file
and use utils.readfile() to embed it or change the script to load it
from a @@file url.
Clean up upgrading.txt with just steps to implement and less feature
detail/internals.
Document internals/troubleshooting in reference.txt.
Add tests using live server.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Mon, 11 Aug 2025 14:01:12 -0400 |
| parents | 7d1b50c02835 |
| children | 0663a7bcef6c |
comparison
equal
deleted
inserted
replaced
| 8410:fd72487d0054 | 8411:ef1ea918b07a |
|---|---|
| 100 :local: | 100 :local: |
| 101 | 101 |
| 102 .. raw:: html | 102 .. raw:: html |
| 103 | 103 |
| 104 </details> | 104 </details> |
| 105 | |
| 106 .. index:: Upgrading; 2.5.0 to 2.6.0 | |
| 107 | |
| 108 Migrating from 2.5.0 to 2.6.0 | |
| 109 ============================= | |
| 110 | |
| 111 Support authorized changes in your tracker (optional) | |
| 112 ----------------------------------------------------- | |
| 113 | |
| 114 An auditor can require change verification with user's password. | |
| 115 | |
| 116 When changing sensitive information (e.g. passwords) it is | |
| 117 useful to ask for a validated authorization. This makes sure | |
| 118 that the user is present by typing their password. | |
| 119 | |
| 120 In an auditor adding:: | |
| 121 | |
| 122 from roundup.cgi.exceptions import Reauth | |
| 123 | |
| 124 if 'password' in newvalues and not getattr(db, 'reauth_done', False): | |
| 125 raise Reauth('Add an optional message to the user') | |
| 126 | |
| 127 will present the user with a authorization page and optional message | |
| 128 when the password is changed. The page is generated from the | |
| 129 ``_generic.reauth.html`` template by default. | |
| 130 | |
| 131 Once the user enters their password and submits the page, the | |
| 132 password will be verified using: | |
| 133 | |
| 134 roundup.cgi.actions:LoginAction::verifyPassword() | |
| 135 | |
| 136 If the password is correct the original change is done. | |
| 137 | |
| 138 To prevent the auditor from trigering another Reauth, the | |
| 139 attribute ``reauth_done`` is added to the db object. As a result, | |
| 140 the getattr call will return True and not raise Reauth. | |
| 141 | |
| 142 You get one reauth for a submitted change. Note you cannot Reauth | |
| 143 multiple properties separately. If you need to auth multiple | |
| 144 properties separately, you need to reject the change and force the | |
| 145 user to submit each sensitive property separately. For example:: | |
| 146 | |
| 147 if 'password' in newvalues and 'realname' in newvalues: | |
| 148 raise Reject('Changing the username and the realname ' | |
| 149 'at the same time is not allowed. Please ' | |
| 150 'submit two changes.') | |
| 151 | |
| 152 if 'password' in newvalues and not getattr(db, 'reauth_done', False): | |
| 153 raise Reauth() | |
| 154 | |
| 155 if 'realname' in newvalues and not getattr(db, 'reauth_done', False): | |
| 156 raise Reauth() | |
| 157 | |
| 158 See also: client.py:Client:reauth(self, exception) which can be changed | |
| 159 using interfaces.py in your tracker. | |
| 160 | |
| 161 You should copy ``_generic.reauth.html`` into your tracker's html | |
| 162 subdirectory. See the classic template directory for a copy. If you | |
| 163 are using jinja2, see the jinja2 template directory. Then you can | |
| 164 raise a Reauth exception and have the proper page displayed. | |
| 165 | |
| 166 Also javascript *MUST* be turned on if this is used with a file | |
| 167 input. If JavaScript is not turned on, attached files are lost during | |
| 168 the reauth step. Information from other types of inputs (password, | |
| 169 date, text etc.) do not need JavaScript to work. | |
| 105 | 170 |
| 106 .. index:: Upgrading; 2.4.0 to 2.5.0 | 171 .. index:: Upgrading; 2.4.0 to 2.5.0 |
| 107 | 172 |
| 108 Migrating from 2.4.0 to 2.5.0 | 173 Migrating from 2.4.0 to 2.5.0 |
| 109 ============================= | 174 ============================= |
