from addresses c2s [Re: [vysper][pubsub] Realworld demo with realworld client]

[Bernd Fondermann <bf...@brainlounge.de>]

Bernd Fondermann wrote:
> Michael Jakl wrote:
>> Hi!
>>
>> I've been trying to implement a demo application for my publish/subscribe
>> extension. My experience so far is all but rosy, in fact I'm tearing my hair
>> out.
>>
>> Let me explain what I did so far:
>>
>> I've tried basic usage of the server with Pidgin and Gajim, both cannot connect
>> to the server due to XML parse errors or programming errors? Pidgin is
>> widely used
>> and Gajim includes support for the pubsub extension.
>>
>> Smack to the rescue! Using smack I could connect to the server and send a few
>> messages back and forth. As soon as I switch to the pubsub extension for
>> smack[1] the whole thing breaks down again.
>>
>> Let me show a small part of the code I wanted to write (c1 and c2 are
>> XMPPConnections, one for user1 and one for user2):
>>
>>  PubSubManager psm1 = new PubSubManager(c1);
>>  PubSubManager psm2 = new PubSubManager(c2);
>>
>>  // create test node by user1
>>  Node test1 = psm1.getNode("test");
>>  test1.subscribe("user1@vysper.org");
>>
>>  // subscribe user2 to test node
>>  Node test2 = psm2.getNode("test");
>>  test2.subscribe("user2@vysper.org");
>>
>>  // user1 publishes some item
>>  Item<PublishItem> item = new Item<PublishItem>("something");
>>  test1.send(item);
>>
>> In plaintext:
>>  - user1: create a node "test"
>>  - user1: subscribe to "test"
>>  - user2: lookup "test"
>>  - user2: subscribe to "test"
>>  - user1: send a message to "test"
>>  - user1: receive notification (not shown)
>>  - user2: receive notification (not shown)
> 
> Seems all good to me.
> To avoid making this a smack pubsub extension debugging project you
> could send plain stanzas using the barebone smack API.
> 
>> The problem starts with the subscribe request. It seems that Vysper
>> does not add the "from" address
>> of the sender (see RFC3920, 9.1.2) to the stanzas.
> 
> Maybe you could write a simple unit test for that?
> This should be an easy thing to fix.
> Could you open a JIRA for that, please?

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?

<snip/>

  Bernd

Re: from addresses c2s [Re: [vysper][pubsub] Realworld demo with realworld client]

[Michael Jakl <ja...@gmail.com>]

Hi!

On Sun, Jul 5, 2009 at 14:50, Bernd
Fondermann<be...@googlemail.com> wrote:
> On Sun, Jul 5, 2009 at 12:21, Michael Jakl<ja...@gmail.com> wrote:
>> 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
>> (<no...@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've read it like this: IF there is an "from", THEN (1.), ELSE (2.). But the
Do EITHER (1.) OR (2.) is also a valid interpretation I haven't seen.

>> 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've done that for my PubSub module now.

Thanks for the clarifications,
Michael

Re: from addresses c2s [Re: [vysper][pubsub] Realworld demo with realworld client]

[Bernd Fondermann <be...@googlemail.com>]

On Sun, Jul 5, 2009 at 12:21, Michael Jakl<ja...@gmail.com> wrote:
> Hi!
>
> On Sun, Jul 5, 2009 at 00:34, Bernd Fondermann<bf...@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 6.1.3.1:
> 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
> (<no...@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
already.
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.)

  Bernd

Re: from addresses c2s [Re: [vysper][pubsub] Realworld demo with realworld client]

[Michael Jakl <ja...@gmail.com>]

Hi!

On Sun, Jul 5, 2009 at 00:34, Bernd Fondermann<bf...@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. Additionally this error condition
explicitely notes it:

XEP0060 6.1.3.1:
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.

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
(<no...@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))

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'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.

What do you think about it?

Michael