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 > [EMAIL PROTECTED] > http://mailman.jabber.org/listinfo/jdev -- Matt "linuxwolf" Miller JID: [EMAIL PROTECTED] E-MAIL: [EMAIL PROTECTED] - Got "JABBER"? (http://www.jabber.org/) _______________________________________________ jdev mailing list [EMAIL PROTECTED] http://mailman.jabber.org/listinfo/jdev
