|
From: John R. <ro...@ie...> - 2025-08-09 05:33:03
|
Hello all:
I have a proof of concept for a feature that I was asked about and I
am looking for feedback.
Consider a user changing a password. You as the admin want to make sure
that the user is actually present and that the request isn't being made on
an unlocked computer by some random person.
One way to add an extra layer of protection on sensitive changes is
to require the user to authorize the change by typing their password.
We see this with github and other places. My POC runs like this:
1) an auditor detects a sensitive change and raises a Reauth exception.
(This is a new exception for use by an auditor.)
2) the Reauth exception handler generates a page from the
reauth template (which is done by the _generic.reauth.html
template unless there is one specifically for the class being changed).
This template includes a form with a
password field that asks for the user's password. It also includes
hidden fields for all of the information passed in to make the change
in step 1.
3) the new page/form calls the reauth action. It verifies the password
using login.verifyPassword. If that succeeds it adds the property
reauth_suceeded to the database (client.db) object. Then it determines
the actual action (e.g. edit) that was executed in step 1 and it
re-executes the action.
4) the original (step1) action is run and the auditor runs again,
but it checks
for the presence of db.reauth_suceeded = True. If it finds that. it
continues processing without raising Reauth.
Step 2 is a bit tricky and it adds fields like: @next_action to store the action
from step 1 since step 2 does a reauth action. This allows step 3 to figure out
the correct action. It also adds @next_template to make sure that the
result of step 4 is shown with the correct template since step 2 uses
the @template=reauth.
So my questions:
Has anybody done something like this already?
Does this seem useful?
Are there other sequences other than reauth that I should consider adding
and maybe build this into a better framework to allow other use cases?
(YAGNI would seem to say no but....).
Thanks.
-- rouilj
|