[Standards] BOSH patches, hopefully the last before final

Ludovic BOCQUET lbxmpp at live.com
Mon Feb 3 00:40:02 UTC 2014


Le 01/02/2014 18:17, Christian Schudt a écrit :
> 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.
It is very old:
- http://issues.igniterealtime.org/browse/OF-81
- http://issues.igniterealtime.org/browse/OF-626

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3736 bytes
Desc: Signature cryptographique S/MIME
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140203/0c4c5e88/attachment.bin>


More information about the Standards mailing list