I've implemented the changes you've suggested: - replace <uidattr_format> and <filter> with <query>. This deprecates <uidattr> and <append-realm>. These are still supported, but <query> overrides them. In the query, '&', '<' and '>' must be escaped as '&', '<', and '>' respectively (the standard XML escape sequences). for example: <query>(&([EMAIL PROTECTED])(objectClass=inetOrgPerson))</query>
- only support %u and %r wildcards, %d was removed. I still haven't understood the nuance of realm though... ^^; Oh well... However, Epic Fail at updating the file on the Trac ticket page. Tomasz, could you do that please? Best, jean On 12/5/07, Harald Braumann <[EMAIL PROTECTED]> wrote: > On Wed, 5 Dec 2007 08:24:13 +0100 > "Jean de Largentaye" <[EMAIL PROTECTED]> wrote: > > > Hi Harry, thanks for your feedback! Comments inlined > > > > On 12/5/07, Harald Braumann <[EMAIL PROTECTED]> wrote: > > > > > > > Why so complicated? Why not just use a single <query/> tag, or some > > > such, that contains the whole ldap query (including substituting > > > node/domain for %u/%d). In case the query tag is given, the legacy > > > uid and append-realm tags would just be ignored. IMHO that would be > > > much simpler and more flexible. To quote your example, it would be > > > something like <query>(&(uid=%u)(objectClass=inetorgerson))</query> > > > (of course with stupid XML excapes). > > > > You're right, this would be simpler, though I hate to present a > > problem of escapes to the user. (I don't think there is such a problem > > anywhere else in the configs, in fact.) I'll have a look into it. > The problem of escaping exists anyway if you want to AND multiple > expressions in the filter, even with your proposed solution. You would > prevent this only for the one special case, where the filter only > contains one attribute to check. Also, you can always put the query > string in a CDATA section and thus prevent further escaping altogether. > Just give a little example in c2s.xml like: > <query><![CDATA[(&(uid=%u)(objectClass=inetorgerson))]]</query> > and point out, that the string should always be written in a CDATA > section in a little comment. > > > > > Actually "domain" and "realm" are two different things in jabberd2. > > > The "domain" is the part of the jid after the `@' (without the > > > resource part). This is also the term the XMPP RFC uses. The > > > "realm" is whatever you specify as attribute in the <id/> tag. Thus > > > "%r" and "%d" should map to different things. If you only support > > > the domain part of the jid in the query, it should be "%d" only. > > > > Ah, I wasn't aware of the distinction. In my case, I refer to the > > realm defined in the c2s' and sm's configuration <id> tag. In fact, I > > believe it really refers to a domain (in the code, on the query, the > > "realm" variable only contains the domain part, without the > > ressource). Even more confusing. Nevertheless, in light of your > > explanation I guess I'll keep only '%d' > I looked into the source a little, and actually I think that what is > supplied in the realm parameter of the authreg functions really is the > realm, and not the domain. I.e. it's the value that you supply to the > "realm" attribute in the <id/> tag in c2s.xml. This is also quite > reasonable, as the realm attribute provides a mechanism to map the > domain to a authentication realm, and it is used for authentication, > solely. Note that the realm is set to the domain automatically if you > leave the realm attribute unspecified. > > I also think that you don't have access to the domain part of the jid > in the authreg functions, just to the mapped realm. > > Thus you should really use "%r". > > > Best, > > Jean > Regards, > harry > > _______________________________________________ > Jabberd2 mailing list > [email protected] > http://lists.xiaoka.com/listinfo.cgi/jabberd2-xiaoka.com > > >
authreg_ldap.diff.gz
Description: GNU Zip compressed data
_______________________________________________ Jabberd2 mailing list [email protected] http://lists.xiaoka.com/listinfo.cgi/jabberd2-xiaoka.com
