On Tue, 30 Dec 2003, Ken Murchison wrote:
> Igor Brezac wrote:
>
> >>Ummm.. there aren't many mechs on my system :-) But at least this
> >
> >
> > Read cyrus-sasl/doc/
> >
> >
> >>Would you like me to post my config again? I don't know what to tell you
> >>about my configuration to make you believe me when I say I can't connect a
> >>global admin through anything but localhost. If I had the time and I was
> >>more understanding of C, I'd dive in the code and hunt it down, but the
> >>best I can provide right now is evidence. I don't know how bad I could
> >>screw the configuration (and I'm pretty good about reading docs), so I
> >>really don't see why this looks suspicious.
> >
> >
> > Well, something has to be different. I never ran 2.2.2-Beta and perhaps I
> > incorrectly assume that there is very little difference between it and cvs
> > head. The code prior to recent Ken's commit discards domain part of the
> > username if the username is in defaultdomain. So, I do not understand why
> > do your admin logins have domain in the queries. This can also explain
> > why you are only able to connect to localhost with your admin userid.
> >
> > Ken, any ideas?
>
> You could verify by looking at the commit logs, but I don't recall
> changing much of anything in the virtdomains code recently. So the
> current CVS should be identical to the last beta release.
>
Ken,
I think I found what is causing the problem or at least unpredicteble
behavior. %r will have a value regardless of whether an application
(imapd in this case) passes the realm to the auxprop. saslauthd auths do
not work this way. This is also somewhat related to bug #2326. Why does
serverFQDN need to be used to realm when user_realm is not available?
Other auxprop plugins do the same thing...
if(sparams->user_realm) {
user_realm = sparams->user_realm;
} else {
user_realm = sparams->serverFQDN;
}
--
Igor
