[sork] Passwd backends

[Eric Rostetter]

Quoting "Peter Borg (horde)" <horde at peter-b.org>:

> It's not so much that the hook won't solve the problem as how common a
> problem it is and how east it is to solve.

It's not that hooks are harder to use, it is that they are more flexible
and solve a greater number of problems with a single solution.

> At what point does anything that could be solved by a hook become a
> preference?

It has always gone the other way.  A preference or configuration item becomes
a hook, not the other way around.

> Surely many things that are currently preferences could be
> solved through hooks? So why have preferences at all?

A preference is a per-user setting.  Configuration items and hooks are
system/host (or virtual host) wide settings, not per user settings.
 
> For this situation, solving the problem through hooks would require the
> administrator/installer to have knowledge of PHP and be able to dig through
> the horde API and find the difference between getAuth and getBareAuth then
> implement it within a hook.

Mostly correct.

> This isn't necessarily straight-forward unless you're familiar with this
> kind of application and know where to dig around to find where the
> difference could be found. As it was I only stumbled across which direction
> to take thanks to the hordeauth preference in IMP.

Cool.

> In a virtual hosting situation, you want whatever the user has entered,
> domain and all.

This is not true.  In some virtual hosting situations you want that. In
others, you want to append to what they entered, and what you append may
be different depending on your setup.  In some (virtual domains with 
unique usernames across all domains) you may want to remove information.
The hook also allows for other changes (like upper/lower case translations,
mapping to an NT domain, etc).  If you did this with configuration settings
you would need to think of all these cases in advance and plan for all
of them, etc.  With the hook, each installer can provide the exact code
they need and/or want.

> You don't necessarily know what the domain will be, and you
> can't necessarily determine it from the domain through which the user logged
> in to horde. Therefore the only guaranteed way to get what you need is to
> use getAuth.

Not true in all cases.  You can know these things in some cases, and not in
others.  You also assume that the horde authentication is of any real use
in changing the password, which it may not be at all (because the horde
authentication may be completely different from the authentication used
to change a password).
 
> The modification suggested would not impact the situation described below,
> that is one user changing the password for another, say in a helpdesk
> situation. The only difference would be that the current user's ID would be
> collected according to the option. Users, if permitted, would still be able
> to enter a different username and/or select a different back-end. The user
> ID would pre-fill either with or without the domain according to the
> back-end entered.

Which is why over time it evolved into a hook, to provide just that
functionality.  The history of it is:

At first, it just used the logged in username, without any way for the end
user to change it, and provided a configuration option to allow you to
remove the domain part or not.  Then, it added realm support, and had a 
configuration item for each realm, like above.  Then it added the ability
for the user to specify the username (or not, via a configuration option).
Then it added multiple backend support, and it could not longer support all
the configuation options above for all the backends in a sane and readable
way, so it was converted to a hook.  Incidently, all these changes were
recommended by the users, not the author/maintainer (which was me at the
time).  In fact, I had no knowledge of writing horde code to do multiple
backends or hooks, and would have never gone that route except that the
users demanded it, and someone else stepped up to do the backend/hook
coding.

> This is, effectively, also added functionality for the user, as currently
> the user would have to determine at the time of selecting the back-end
> whether or not the domain name is required.

No, the system manager should determine this, not the user.

> Yes, a hook could be written and
> defined in each backend which automatically appends the domain name where
> required, but in this instance the hook would have to be extensive in
> testing whether or not a different username had been entered rather than
> what would be returned by getAuth. This is possibly beyond many horde/imp
> installers/administrators as well.

Maybe, but so would be having thousands of configuration options they need
to sort through of which only one or two apply to them.

> For me it was a question of functionality & usability. I'm quite happy to
> dig around in code, find what I need to create hooks, or modify other code
> to suit my purposes. Not everyone in my situation would necessarily have the
> ability to do this. After modifying imp to use hordeauth such users may
> simply disable passwd as they cannot find a simple way of making it do what
> they want.

Or they could write to the mailing list, explaining what they want, and
probably get someone on the list to send them a sample hook that does what
they want.
 
> To quote from horde/config/hooks.php.dist:
> 
>  * THE HOOKS PROVIDED IN THIS FILE ARE EXAMPLES ONLY.  DO NOT ENABLE THEM
>  * BLINDLY IF YOU DO NOT KNOW WHAT YOU ARE DOING.  YOU HAVE TO CUSTOMIZE
> THEM
>  * TO MATCH YOUR SPECIFIC NEEDS AND SYSTEM ENVIRONMENT.

True.  Same really for configuration items though, no?

> The use of a hook for this purpose is not well documented, and there is no
> example that would work.

Then a) it should be better documented, and b) of course not, we can't
write a thousand hooks in the example file to satisfy all thousand cases
we can think of.

> Other requests for assistance with the exact same
> situation exist in the horde list archives and in other places on the net,
> although they're often wound in with other issues (such as with poppassd and
> virtual hosting).

Which is exactly what we are talking about (passwd supports poppassd and 
virtual hosting, so of course there will be things "wound in" with these
issues.
 
> Peter.

I'm sorry, but you've not made a case I can support yet.  Yes, a configuration
item which does what you want is easier than creating your own hook code
to do what you want.  But since there are thousands of possible situations,
we can't reasonably be expected to support thousands of configuration items.
We can be reasonably expected to support a hook mechanism that allows you
to implement any of those thousands of setups you want to.

Hooks are more flexible, and when you have a situation in which the 
possibilities exceed a handful of cases, you need to switch to something
more flexible.

> -----Original Message-----
> From: sork-bounces at lists.horde.org [mailto:sork-bounces at lists.horde.org] On
> Behalf Of Eric Rostetter
> Sent: 27 January 2005 23:17
> To: sork at lists.horde.org
> Subject: RE: [sork] Passwd backends
> 
> Quoting "Peter Borg (General)" <general at peter-b.org>:
> 
> > Re: hooks; yup, I'd considered this and even tried it, but having
> > previously searched around for information on this issue (and a
> > related one, more on that in a few days), I'd realised that I wasn't
> > alone in this requirement, and that it's quite a common one.
> 
> But the hook should solve the problem, common or not, unless I'm not
> understanding the problem correctly.
> 
> > The thing that led me to suggest this modification, rather than just
> > hacking my own installation and keeping quiet, was that there is a
> > similar setting in imp/config/servers.php - 'hordeauth' - which I have
> > used for my particular installation.
> 
> Yeah, and another, called realm.  That doesn't mean every application should
> have those though...
> 
> I always thought of hordeauth as using the same username/password
> credentials that Horde uses for login/authentication.  Since passwd doesn't
> do this per se - it is to change a password, not to login to something - I
> never thought it was appropriate to use it here.
> 
> None-the-less, I'd support the addition of a hordeauth solution if it was
> clean, to login/authenticate against the backend being used to change the
> password.  It would still need to prompt for the old and new passwords (and
> optionally the username) separate from the hordeauth though to maintain
> backwards compatibility (think of the case where a user is changing the
> password for another user, ala a helpdesk).
> 
> > It seemed strange that this setting existed in imp but not in passwd.
> > After
> 
> The setting came along (in gollem and imp, maybe others) not that long ago
> in Horde-years, and I think it was only put into applications to avoid a
> double login situation.  This is not really the situation in passwd, as we
> don't consider it a double login (we consider it a security issue).
> 
> > setting it in imp I went looking for it in passwd and was surprised
> > not to find it. Therefore I thought it might be good to provide a
> > similar setting in passwd.
> 
> It might be.  Not sure.  You'd have to convince us of the merit.
> 
> > I would suggest that it is not an uncommon requirement; I suspect that
> > Horde/Imp is used as a webmail solution in many virtual hosting
> > environments where the full user & domain name is required for
> > authentication and authorisation.
> 
> That's why the hook was put into the sork apps that use usernames (IIRC).
> 
> > The ability to change a password in the webmail environment is
> > probably incredibly desirable in many such situations, as typically
> > the user interface for password changes is a separate one provided by
> > the hosting software, and in my experience is absolutely dreadful!
> 
> But, that doesn't mean you don't need to ask the user for a
> username/password to use.  That is a separate issue (security).
> 
> 


-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin
 
Why get even? Get odd!