[sork] Passwd backends

[Peter Borg (horde)]

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.

At what point does anything that could be solved by a hook become a
preference? Surely many things that are currently preferences could be
solved through hooks? So why have preferences at all?

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.

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.

In a virtual hosting situation, you want whatever the user has entered,
domain and all. 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.

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. 

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

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.

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.

And from horde/docs/install

   .. Warning:: You only need the ``hooks.php`` file if you want to create
                custom hooks for some of Horde's features and default
values.
                Beside that, this file only contains examples that you
should
                not use as they are and that even cause fatal error if you
                keep this file unchanged.  If you don't need hooks it's a
good
                idea to remove this file now::

                   rm hooks.php

The use of a hook for this purpose is not well documented, and there is no
example that would work. 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).

Peter.

-----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).