mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bernd.fonderm...@googlemail.com>
Subject Re: from addresses c2s [Re: [vysper][pubsub] Realworld demo with realworld client]
Date Sun, 05 Jul 2009 12:50:06 GMT
On Sun, Jul 5, 2009 at 12:21, Michael Jakl<jakl.michael@gmail.com> wrote:
> Hi!
> On Sun, Jul 5, 2009 at 00:34, Bernd Fondermann<bf_jak@brainlounge.de> wrote:
>> Bernd Fondermann wrote:
>> After a quick(!) review, I found that the /client/ is required to send a
>> 'from' address /only/ if it has bound more than one resource at the same
>> time (rare).
>> In all other cases, the from is available in the handler via
>> SessionContext.getInitiatingEntity(). So it is not necessary to enrich
>> the stanza while it is still in the handler.
>> Now, where do you expect the server to add the from, when it currently
>> doesn't?
> I was thinking that a "from" attribute should be present because all
> examples in the XEP0060 include one.

Examples are not normative. Don't be fooled by illustrations ;-)
It's good that all examples have 'from's, this makes the spec easier
to comprehend.

> Additionally this error condition
> explicitely notes it:
> XEP0060
> http://xmpp.org/extensions/tmp/xep-0060-1.13.html#subscriber-subscribe-error-nomatch
> If the specified JID is a bare JID or full JID, the service MUST at a
> minimum check the bare JID portion against the bare JID portion of the
> 'from' attribute on the received IQ request to make sure that the
> requesting entity has the same identity as the JID which is being
> requested to be added to the subscriber list.

I think this is to prevent subscribing evil@vysper.org to a node which
should only accessible for angel@vysper.org by means of a fake 'from'
address (spoofing attack). If the from is not there, the server knows
who's it.

> Second, the RFC3929 9.1.2 says this:
> When a server receives an XML stanza within the context of an
> authenticated stream qualified by the 'jabber:client' namespace, it
> MUST do one of the following:
>   1. validate that the value of the 'from' attribute provided by the
> client is that of a connected resource for the associated entity
>   2. add a 'from' address to the stanza whose value is the bare JID
> (<node@domain>) or the full JID (<node@domain/resource>) determined by
> the server for the connected resource that generated the stanza (see
> Determination of Addresses (Determination of Addresses))

We do (1.), so we are fine. Some stanzas come without from addresses,
the most prominent probably being availability presence.

> I think it would be easier to just add the "from" attribute to the
> stanza than have each component that requires it check wether one is
> included, if not, take the one from the SessionContext.

I think we should write a utility method which provides this info.

> I'd add the from attribute in XMPPCoreStanzaHandler#execute. There we
> already deal with 9.1.1 of the RFC (veryfying proper "to" attribute).
> Another way to get this in, in a general way, is to extend
> Stanza#getFrom, but this isn't the right place to do this IMHO.

The 'from' attribute is meaningless in an authenticated stream (see
exception below!), because the server knows who he is dealing with
At this stage, the from should be ignored in most cases, because it
only leads to double-checks, spoofing attacks and errors.

There is one exception: If more than one resource is bound in the same
session (rare!), then you need to differentiate at times.

Now, if you really need the 'from', because you need to decide between
subscribing a bare or full jid, well, use it.

(It took me a few months to comprehend this, BTW.)


View raw message