[Standards] BOSH patches, hopefully the last before final

Christian Schudt christian.schudt at gmx.de
Sat Feb 1 17:17:40 UTC 2014


Hi,

we use XMPP in a "closed" environment. Users don't know their JID, because it is kind of a random UUID (the local part).

They authenticate not with their "XMPP Username" (nor with their JID).

It works similar to how Facebook chat works: The users' JID are something like 12347324532 at chat.facebook.com.

But users authenticate with their email address (even non-Facebook email-address) as username (or even the other SASL mechanism X-FACEBOOK-PLATFORM).

In our case it is similar. Users only enter their email address (or username they chose during registration).

In the client's connection settings they just have an IP address where they connect to (as I wrote in my last email), depending from, if they are connecting from internet or intranet.
(because the real domain can't be resolved from intranet).

The whole issue with the 'from' attribute is no big problem of course. It was just something that caught my attention.
On the other hand, I am not considering it a "major thing" to change a MAY to a MUST in the BOSH specification, especially because the draft status clearly says "but some changes to the protocol are possible before it becomes a Final Standard". But I am no expert in XEP definitions. Maybe a SHOULD is a also possible!?

@Michael Weibel: Concerning Openfire's (3.8.2) BOSH implementation: It is not stable, but for now stable enough, I'd say. But it is still BOSH version 1.6 and XEP-206 is not supported.

Christian


Am 01.02.2014 um 17:22 schrieb Winfried Tilanus:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 01/29/2014 01:04 PM, Christian Schudt wrote:
> 
> Hi,
> 
>> The problem we then had, when users wanted to connect with BOSH,
>> is that our BOSH implementation (which is the one from Openfire)
>> did not return a "from" attribute, which also means that during
>> SASL DIGEST-MD5 authentication the realm could not be set (which
>> is expected to be the server's domain name). Consequently this 
>> authentication failed.
> 
> Well, what is causing my confusion, is that in most clients you enter
> your JID to identify yourself. The part before the '@' is the local
> part, usually your username, the part right after it, is the domain
> you want to connect to. The story of the SRV records is a way to
> determine what server is actually serving that domain.
> 
> So I assume you know your domain when you enter your login credentials
> somewhere.
> 
>> The only solution was to either hardcode the domain name in our 
>> client or to make it configurable on the client's UI, which means 
>> there's another field for the user to fillout besides the 
>> hostname/IP, which might be confusing.
> 
> The situation I am used to, is to let the client determine the server
> automatically, based on the domain part of the jid. If that does not
> work, you can tick a box to manually enter a server address. But in
> both cases you know to what domain you try to connect.
> 
>> (For normal XMPP on 5222 it works in this case, since the 'from' 
>> attribute is included in the stream header response).
> 
> Please notice you should not trust any 'from' before the stream
> restart. The server may send anything there.
> 
>> I don't know if this use case is "valid" or if you expect to know
>> the identity (as you said), i.e. the domain name before
>> connecting.
> 
> I don't think a case can be 'valid' or not. I try to judge if we
> should to break open the BOSH XEPs for this (what would be a more than
> major thing in this stage).
> 
> Up to now, I am far from convinced, because you should already provide
> the domain name when configuring the client with the credentials of
> the user.
> 
>> But I guess this use case is quite similar to 
>> http://xmpp.org/rfcs/rfc6120.html#tcp-resolution-srvnot
>> 
>> "(say, to "hardcode" an association from an origin domain of 
>> example.net to a configured FQDN of apps.example.com)"
> 
> Yes, that is about overwriting the automatic server discovery by
> specifying a server by hand. That is the situation you are in too.
> 
>> in which case you would connect to 
>> "http://apps.example.com/http-bind/" but would never know that the 
>> origin domain name is actually "example.net".
> 
> Once the BOSH session is established, your XMPP stream is opened and
> you are authorized, then you do your resource binding. After that you
> know what domain the server thinks you have. But if that differs from
> the domain in your JID, you should treat that as an error.
> 
> Winfried
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQIcBAEBCgAGBQJS7R9DAAoJEHZ7UH0X6LdcSSEP+gIMdF11M0ura5nYD/1oOP+f
> HM0V0gzaAMgKOh+j9n22BDyYO+Av/inaUyrqE9d7TljMmU9omYooXLyqJvxk/uxH
> wQJ6On81hmS0SNAnt6J6lvEbzEXJoUvA4TFQDghlLhWJZWTCyRmyshpM9A669J2M
> byZQuVBxSVbpx8p2ulpyKZ85fzhsdMxSumRyf/X6cpQNNn8EyVIS//vmKoCQhcF/
> 0BMKFPOYEGm9xEG0w2Q8VWA3bb5W2y1LZ3BnVfBLpmCLJ/B5dXSepFCyF3jrnQ6J
> s7zKAAkqR2VFB8msHNFVoCiQZv1kgyEDdOLzZRyq7dff/NHn3ZTEIbKiWAaq+Jey
> qNuUlisSCzF1lCpfHXNgcZTDUbtFFW1gGB9L2hXD2MxAs0EvLKV+lVNO74bDga0K
> OwHoThuj3fJ7FD3MNZW/ZvUYKF5Nh5jvdtImzX0jWAi70uZP2S6R69dZJxSGPTPU
> H8Bl6bPeFjzy6qsAp8OOhk9BVSKaO648fHqeCsWBGYkhm9wl/n2gFpmAyrxP+hjl
> n84/QuozSMQoccQSJPcim/S6dBLOyCtbh9pZnFUmraDjej5DcYBbl1gxrJ3L9JCw
> ubiZOgjsQILh596oLZFQGs6KwnwuEk9i0PkeLvblZ6nL3XCNr9DwSCgqa01EM5ML
> iMneCM8zDDIZI96Fexr3
> =Hld8
> -----END PGP SIGNATURE-----




More information about the Standards mailing list