Hello,
I have been working on a major refactoring of my two factor authentication
software. I have split it out into a master action module that implements
the authentication front-end and a suite of helper modules that provide the
authentication functionality. This will allow us to more easily add
additional modules to implement other mechanisms, say a module for Twilio
and a module for RSA tokens. However, in the production wiki I am trying
to implement this in, I have run into an odd scenario. The users cannot
change any of their personal information because it is pulled from AD with
no edit permissions. Normally, if the user cannot make any edits, they
cannot access their profile. However, I rely on access to the profile to
configure their two factor settings.
For now, I have hacked in a fix for my environment, but I'm exploring
long-term fixes. I'm looking for comments on my suggestions, as well as
more alternatives.
1. Check for any registered hooks to AUTH_USER_CHANGE(_BEFORE?) and/or
HTML_UPDATEPROFILEFORM_OUTPUT and if any are present, allow for access to
the profile, even if there is no user modifiable data. This would enable
access to the profile if any action module would interface with a user data
change. However it might break existing modules that are designed to only
change the existing fields of data or cause undesired functionality for the
wiki admin. This would also require a change to Doku_Event_Handler so we
could query if there is any registered hooks; I have a working copy of this
code.
2. Provide for an "allow profile" option in the base Doku_Wiki_Auth class.
This would add a new option to the main wiki options that would allow the
profile to always be visited, even if there was no user modifiable data.
This would always allow a user to review their email and display name when
turned on. Admins that don't want this functionality can leave it off.
This is also the simplest to implement; I have a working copy of this code
as well.
3. I supplement my two factor class with an auth module. This would
replace the existing auth module with a true two factor auth module, and
use another admin defined auth class to perform the basic authentication
functionality. In concept, it would work like authchain and wrap the real
authentication objects. This would allow me to ensure the profile is
displayed, but may cause linked auth modules to not work as expected.
4. Create a new hook to register for use of the profile. This would allow
an action module to specifically register for use of the profile instead of
reusing an existing event to cause the profile to appear. It could also
clean up the use of HTML_UPDATEPROFILEFORM_OUTPUT, As I see it,
HTML_UPDATEPROFILEFORM_OUTPUT is used to change how the existing data is
managed. I'm trying to manage data that is not normally handled by the
default profile. Having this would provide a way to add additional forms
that focus on this new data without trying to insert itself into or affect
the existing form. It would specifically provide a new, empty form to work
with, instead of supplying the existing profile form.
5. Create the ability to add new actions. Right now, all actions like
show, login, and profile are fixed. One way to provide the user interface
I'm using would be to create two new actions: twofactor_profile and
twofactor_login. However, the ability to register new top level actions is
not currently possible; act_validate checks against a fixed number of
options. There is no way to add a "new" action; the current expectation is
to register hooks and use the existing action. This would allow for a new
action to be added and the developer would not have to worry about
competing with other hooks that might be registered in addition.
ACTION_ACT_PREPROCESS could be hooked to switch the user to, from, and
between the new and existing actions.
Again, I'm looking for comment on these suggestions. If this conversation
has already happened, if you could provide a link to any online content I
would appreciate it.
Greetings,
Mike
