[JDEV] jabberd patch

[Matthew A. Miller]

The more I read this thread, the more I agree with both sides...

Is there middle ground to be had?  What if XMPP were defined in such a
way that if a connection/session attempted to auth as an already online
one, it was up to the server.  If the server decided it was allowed, it
sent the appropriate iq-error to the original connection (302?) along
with the disconnect.  If the server decided it wasn't, it sent a 409 or
405 iq-error to the new connection along with the diconnect.

Does the above sound reasonable?  If so, I'll make a point of
approaching the XMPP I-D authors on it.


-  LW 

On Tue, 2003-02-25 at 16:03, Wes Morgan wrote:
> I forgot to mention why I needed this behavior in the first place... I 
> implemented a custom web-based chat system for a client that uses jabberd as 
> its backend. However, one of the requirements for the system was that users 
> could only log on once, and that if they tried to log on a second time, they 
> wouldn't be allowed (unless, of course, they terminated the first session). I 
> had been keeping track of this in a state database that my auth agent was 
> using (it communicates with jabberd at the XDB level), but sometimes jabberd 
> and this database would get out of sync with each other. So, I decided to 
> just build this functionality into jabberd itself. That's why, for my needs, 
> it wouldn't work to just "define the protocol" as kicking the first 
> connection when a second one comes along. I at least need the option of 
> changing the functionality.
> 
> Wes Morgan
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
-- 

Matt "linuxwolf" Miller
JID:	linuxwolf at outer-planes.net
E-MAIL:	linuxwolf at outer-planes.net

- Got "JABBER"? (http://www.jabber.org/)