[JDEV] Jabber server 1.2

[Dennis Noordsij]

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

I couldn't find any information in the docs about this so I looked and 
looked until I found some example python scripts in some directory in 
the 1.2 sourcetree that upon execution (via <exec>) send <root> back to 
jabberd. This caused an invalid namespace error, and after some trial 
and error I could get jabberd to send an auth request after me (the 
script) sending <root xmlns='jabber:component:exec'>.

I wouldn't mind some more doc's though :)


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

Looking forward to it! :-))

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

Hmmm.. the thing is that the LDAP dbase already exists and I am not sure 
how the passwords and hashed (thats my friend's department), all I 
imagine is that it likely is irreversible. I am not worried about 
sniffing or anything like that, just the fact that I might not be able 
to reverse already hashed passwords.

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

I was looking at implementing jabberd for routing all sorts of messages, 
but I guess a more sane approach is to use the jabber protocol for 
control messages etc, doing the actual transfer of large objects 
directly client to client. Jabber would be very well suited for that.


Thanks for your reply!
Kind regards,
Dennis


 
> -David Waite
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev