[JDEV] phew

[Schuyler Heath]

Hi,

On Thu, Nov 30, 2000 at 06:03:16PM +0200, Dennis Noordsij wrote:
> Now, someone tries to authenticate. For some reason a simple 
> 
> <xdb id="1" from="..." to="... at ...../jabber:iq:auth" type="get"> 
> 
> is sent to my xdb module. It expects me to send for example
> 
> <xdb id="1" from="... at ...../jabber:iq:auth" to="...." type="result">
>   <password/>
> </xdb>
> 
> Next my LDAP authentication script receives the proper 
> 
> <route...<xdb...<query...<iq
> 
> tag with the necessary info to perform the authentication.
> 
> Question 1
> Why is that one xdb tag w.r.t. jabber:iq:auth sent to the xdb module? To 
> fetch the information necessary for authentication (password) from the 
> backend for use in the proper authentication module? Or to simply check if 
> the user exists at all?

Simply to check if the user exists.

> 
> After a succesfull login my xdb script receives 
> 
> <xdb id="4" to="... at ...../jabber:iq:roster" from="....." type="get">
> 
> I answer with for example
> 
> <xdb id="4" type="result" from="... at ...../jabber:iq:roster" to="....">
>  <iq xmlns="jabber:iq:roster">
>   <item jid="dennis" name="Dennis" subscription="none">
>     <group>Friends</group>
>   </item>
> </xdb>
> 
> 
> 2 things can happen now.
> 
> Firstly, if I have <mod_presence> support loaded in the JSM, the following 
> happens:
> 
> >From the xdb script point of view:
>  single auth request for the login, as above
>  single roster request, as above
>  connection to jabberd lost

Is that the *exact* xml you're sending?  The xml above isn't valid which
would cause your connection to jabberd to be closed.  Strictly speaking
it should be <query xmln="jabber:iq:roster" not <iq/>.  Otherwise I can't
think of why your connection would be dropped.

<xdb id="4" type="result" from="... at ...../jabber:iq:roster" to="....">
  <query xmlns="jabber:iq:roster">
    <item jid="dennis" name="Dennis" subscription="none">
      <group>Friends</group>
    </item>
  </query>
</xdb>

> >From the gabber point of view
>  logged in .. ok
>  received roster data .. in <iq..<query..<item tags, xml is correct.
>  sent <presence/>
>  transmitter error, disconnected: 4
> 
> >From the jabberd -D point of view:
>  logging in went fine
>  received the roster information from xdbperl, sent it to jabber
>  received the <presence/> tag from gabber
>  delivering to instance xdbperl
>  base_load.c:323 xdb_get() waiting for dennis at domain jabber:iq:roster 
>  at this point jabberd has died. No segfault, no error, just gone


Is your connection lost before you send the result?  If so, your result is
never received so the request is timed out.  You will still see the
"delivering to instance xdbperl" even though packet are not reaching your
script.  Packet are buffered for a default of 30 seconds before they
are bounced.  This is to give the client a chance to reconnect.  Unfortunately,
there seems to be a bug that makes jabberd die when a xdb request is resent after
5 seconds (or something along those lines).

> MAYBE I am wrong about my assumption the mod_presence data is simply the part 
> of the JSM that handles it, I don't know if it is in any way related to 
> wether the information comes from xdb_file spool files or somewhere else.
> 
> 
> If I do not have <mod_presence> enabled, this happens:
> 
> Same as above, except for the crash
> deliver.c:84 incoming packet, the <presence/> tag from jabber 
> I am not sure what happens with it, but it seems to be ok. I do not know if 
> presence would now actually work.
> jabber:x:offline is deliverd to my xdbperl module next
> All is fine and dandy, until

mod_presence makes a xdb request for the user's roster.  This is so
it can notify the people subscribed to the user that they are now online.
By disabling mod_presence the xdb request that is crashing the server
is no longer made.

> I use gabber to send a message to a user that is not logged in (well it 
> doesn't even exist, but how would jabber now? unless that is what the one 
> line <xdb type="get".....> tag with jabber:iq:auth is for?

Right, that is what the jabber:iq:auth is for.  The user doesn't exist
therefor offline messages cannot be stored.

> Now, if I do nothing, the xdbperl script will receive three jabber:x:offline 
> requests, and then jabberd will die.
> 
> If I however in the mean time try to send a message to anyone else, jabber 
> will claim to deliver an xdb auth tag to xdbperl, but in reality jabber dies 
> before xdbperl has ever seen anything.
> 
> 
> All the time the "crash" sequence (according to the -D output) is
> 
> delivering to instance xdbperl
> xdb_set() waiting for dennis at domain jabber:[iq|x]:[offline|auth|roster]
> 
> Then jabberd is gone.

It sounds as if jabberd is never receiving your result.  If your connection
has been dropped, this would make since :)  Or if you're sending invalid
xml.  Sorry if this doesn't really answer your question.

> My goal is to control the backend jabber uses for all it's user info, that 
> means I want it to come to me (my script :) to ask anything, to authenticate, 
> add and delete users from roster lists, vcards, etc. I want to define what 
> happens with offline messages and how they are retrieved. If possible I would 
> even like to control the presence list (so I can "fake" a user being 
> available when in fact he is not logged in to jabber but has an agent 
> forwarding his messages to sms and receiving his messages and putting them 
> back on the wire on his behalf. ie the other party thinks he is using jabber 
> when in fact he is not).

A component may create a session by sending:
<route type="session" to="user at localhost/sms" from="9 at perlsms"/>

All packet for the session will be delivered from jsm to perlsms like so:

<route to="9 at perlsms" from="user at localhost/sms">
  <message ...../>
</route>

To kill your session send:
<route type="error" to="user at localhost/sms" from="9 at perlsms"/>

perlsms.localhost could then be subscribed to the user so it knows the users
presence and hence when to create or kill the fake session.

> What exactly do the mod_.... references do? Do they simply define features 
> that are on or off?

Yes.  They also allows you to control the order in which the modules are called
and to make it simpler to extend jsm in the future.

> And why does jabber die on me like that? Btw I use the Net::Jabber module, 
> but even if it was flakey it shouldn't cause jabberd to die right?

Because it's a bug :)

Schuyler