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 =============================

Roundup Issue Tracker: http://roundup-tracker.org/