[imp] IMP 3.1 / user@domain.ext on virtual domains

[Amith Varghese]

> Now that I think about it, what you are really trying to do is dynamically
> set
> the realm parameter (without using $HTTP_HOST, etc).  I don't think there is
> really anyway to do this cleanly (i.e. no code modification), but you could
> perhaps create a hook for that purpose.  something called _prefs_hook_realm.
> And then you would have to modify the code so that it checked for that hook
> before it set the realm.  There are a bunch of examples scattered throughout
> the
> code on hooks are called.  Definitely possible, but I don't know if that type
> of
> functionality would be incorporate if you supplied a patch.  And if it did
> get
> commited it would be to HEAD  I would try it that way though... I think its
> cleaner than the vinfo stuff we talked about earlier.

I was thinking about this more and even if you could set the realm dynamically
(BTW you can... you could access Auth::getAuth() before the server definition
and get the name of the user who logged in and their realm and use that info to
set the realm parameter) it still wouldn't work because IMP would still think
the user is user@foo.bar rather than user (which is what you want).  Ok here's
is my complicated solution.  Excuse myself why I attempt to explain the madness.

Basically you want to use the vinfo hook as I mentioned before.  In the vinfo
hook the user will be user@foo.bar@kabissa.org.  In the hook you want to strip
off @foo.bar@kabissa.org.  This gives you "user" as you wanted.  Then what you
want to do is before servers.php you want to add some code that does something
like this:

// this splits user@foo.bar@kabissa.org into an array of parts user, foo.bar,
// and kabissa.org
$userdomain = preg_split('/@/',Auth::getAuth()); 

// set the $domain_array parameter to foo.bar
$domain_part = $userdomain[1];

in your definition of servers.php
realm => $domain_part

so now all your preferences will be stored with the @foo.bar (or whatever the
user wanted) on the end.  This avoids collisions.

Then as mentioned before you will want to change the _prefs_hook_from_addr() so
that it strips off the @kabissa.org

And in addition you'll have to modify login.inc so that the @kabissa.org doesn't
show up on the login page (if that is what you want)

I think this solves your problem as you stated.  However, I still don't know how
you are going to handle user@foo.com and user@bar.com if you strip off domain
before you authenticate with the IMAP server.

Amith