On Wed, Jan 14, 2009 at 08:14:12PM -0500, Andreas Hofmeister via RT wrote:
Show quoted text> Queue: AnyEvent-XMPP
> Ticket <URL:
https://rt.cpan.org/Ticket/Display.html?id=42194 >
>
>
> Am 14.01.2009 um 23:55 schrieb Robin Redeker via RT:
> >
> > I thought a bit longer about this. Why do i have to pass the
> > host which was used to override the domain in the JID?
>
> The domain part in the JID and the host you connect to are not
> actually related. It is very well possible that the XMPP domain
> 'example.com' is hosted by 'somehost.big-isp.net'.
Yes, an I don't know about the internal redirections they do, or the SRV stuff
they do, somehost.big-isp.net should just know that it hosts example.com.
Show quoted text> Nevertheless, remember that when you connect another host, deep down
> you use IP the address to connect the host, not the name.
I'm well aware of that. The 'host' parameter the user can pass
to override the TCP endpoint we are going to connect to doesn't
even have to be a hostname, it could be an IP aswell.
Show quoted text> > Sometimes the 'host' which was specified to override is not even
> > a hostname (but an IP). And I thought one wants to
> > authenticate as node@domain?
>
> You still pass 'node@domain' to the host you connect to. It is the
> job of the server to figure out that 'node@domain' belongs to its own
> namespace.
>
> When you use Kerberos authentication, the jid you passed to the
> server does not even need to be related to the identity you use for
> authentication, as the identity is taken from the ticket passed to
> the server. The server then figure out that the Kerberos identity
> 'user@EXAMPLE.COM' is in fact valid for the JID 'user@example.com'.
Yes, sounds like I thought. And why do I have to pass the override parameter
for connecting the TCP endpoint as realm?
This scenario:
user@example.com wants to override all SRV lookup related
stuff and specifies the 'host' foobar.com and the port 5222
to connect to. He knows that it's the right server.
It's still the domain 'example.com' which we authenticate for,
if the user wanted to authenticate as user@foobar.com he should
have specified the correct JID. The TCP endpoint, as you said,
is unrelated to authentication, so why should I pass it?
Show quoted text> In theory, similar is true for other SASL mechanisms. When you pass
> 'user@example.com' as identity, the server may choose to just use the
> whole string as the user id, or it may choose to use 'example.com' as
> an authentication realm for SASL, or even just ignore the domain part
> altogether.
Yep.
Show quoted text> Summary: the assumption host == JID domain == SASL realm does not
> hold, so what one needs is a mapping between those domains.
Yes, and that mapping is on the host I connect to. He knows
the best which JID domains he is responsible for.
Show quoted text> The mapping JID => authentication ID, it seems to be a common praxis
> to use the JID as the authentication ID for those mechanisms that
> actually need one. None of the clients I've seen so far do it
> different. However, keeping them distinct internally may be a good idea.
>
> DNS-SRV records provide the mapping from JID domain to the host to
> connect. I would suggest this algorithm
SRV records may even hold a mapping of JID domain to an IP address directly.
Show quoted text> 1. when the user explicitly specified a host, just use it.
> 2. look for SRV records for the domain-part of the JID. When found,
> use the best one (Net::DNS has a method and an example for this).
> 3. try to lookup the JID-domain as an IP-Address, when found use it.
> 4. give up.
Currently it's like this:
1. If the 'host' parameter is given, may it an IP or a hostname,
use it to make the TCP connect. But for all authentication issues
use the JID domain.
2. When no 'host' parameter is used, and the 'port' parameter contains
'xmpp-client', do a SRV lookup and as the SRV rfc says try to connect
to the returned endpoints until it succeeds.
When connected, do authentication issues by the JID domain.
Show quoted text> Using the SRV records over the domain-as-a-host catches the case of
> domains having catch-all DNS records.
>
> Hope that helps,
It helps to clear up my mind and find the right solution, I hope :)
Thanks,
Robin
--
Robin Redeker | Deliantra, the free code+content MORPG
elmex@ta-sa.org / r.redeker@gmail.com |
http://www.deliantra.net
http://www.ta-sa.org/ |
