[JDEV] Jabber server 1.2

[David Waite]

Dennis Noordsij wrote:

> Hello list!
>
> Jabber 1.2 itself is working fine for me, but I would like to move over
> certain things over to external programs, for example do all
> user/password lookups via an LDAP dbase, and use a fast SQL dbase for
> roster lists etc.
>
> I haven't been able to find much documentation regarding jabber 1.2, for
> example the XML messaging used between modules (I got as far as <root
> xmlns='jabber:component:exec'> for for example an xdb <exec> script).

if it is <root xmlns="jabber:component:exec"> I'm going to have to strangle
someone ;-) It is at least *supposed* to be the standard stream:stream
header, with a namespace of jabber:component:exec.

After you get this and reply (or is it the other order), you are connected.
Connections with TCP sockets require an authentication, consisting of a
known secret between the two components, hashed the same way as digest
auth.

There is some support code for this in the 0.9.0 JabberBeans beta, if you
know/like Java ;-)

> I would like to turn off the standard password checking and roster
> lookups and use my own scripts for it.
>
> If anyone can point me to appropriate documention, or has it working
> themselves, it would be very much appreciated :-) If you have it working
> yourself, a config file should be enough for me to figure most things
> out myself. (the configs directory in the jabber source doesn't have
> much variation).

Roster checking and password checking are things I  haven't gotten around
to overriding yet :)

> On a side note, from what I gathered using jabberd -D the authorization
> module supplies the password in plaintext to another module that
> compares it to the password that was given by the client. Most likely
> though I am missing something here :-) The LDAP passwords will be hashed
> irreversibly, I would like to compare hashes, not plaintext passwords.

Its kinda all bad - if you are passing a hash of the password around, you
get rid of the benefit of it being a hash in the first place (easily
replayable, original password never required so the hash basically takes
its place and becomes the 'new' plaintext password).

Look up 0k auth. I posed a message a few days ago about it (although
I swear I can never remember its formal name :))

> Secondly, what is the maximum size of a message? For example, does
> jabberd stream a message through while it is receiving it, or does it
> first receive the entire message, and then route it and send it? What is
> the performance when spools get very very big?

last I heard,  1 MB was the max size before the server just hung up on you.
If karma is turned on with default settings, it will quite a while
(I thought more than a day) to get a message up this high without being
throttled.

streaming a message through is impossible since it is basically generating
a DOM tree per message packet, and using that as the basis of any routing
at all.  Also, if it was client->server->client, it wouldn't be able to
stream to the other client, if the first client got hung up midstream, the
second client would be stuck with an invalid XML stream and would be forced
to disconnect as well.

-David Waite