Project

General

Profile

Confused with the 3 "from"/"to" getters

Gabriel Rossetti
Added over 4 years ago

Hi all,

The 3 src/dest getters are a bit confusing to me:

  • getFrom()

  • getPacketFrom()

  • getStanzaFrom()

  • getTo()

  • getPacketTo()

  • getStanzaTo()

Maybe I am missing something about addressing in XMPP, I understand the "to" has to be entered by the sender and the "from" does not have to be entered but if it is not entered the server adds it (I am not sure of what happens if the sender spoofs the "from" field, I didn't see this mentioned in the spec but I could have missed it).

I assume the StanzaFrom is the one given by the sender entered in the stanza, if it is given, and the PacketFrom is one set in the packet by the client and/or the server and it should equal to the one entered by the sender (in the stanza) if it was given (and if it is correct?) and if not then one set by the server upon receiving the packet). From what I understood in the spec (http://xmpp.org/rfcs/rfc6120.html#streams-attr-from) the from field +should+ be given by the sender after the encryption has started, if it is not the given then the server +must+ enter one (after the encryption has started). The receiver +must+ add the from when replying.

The thing is all 3 APIs (the "from" ones) say they return null if the JID is not set, but there must be one of those that is always set from what the spec says. I understand the one set by the server is not necessarily a user@domain type of address and could just be a domain address.

The getFrom() one sends back the PacketFrom if it's not null and the StanzaFrom if it is, but it can still return null which I don't understand why after reading the spec. Also I would have made it return the StanzaFrom with priority (if it is not null) since the PacketFrom could just be the domain, why was it done the other way around? Is it because of the fact that it could be spoofed?

Some more questions:

  • Does the server set the PacketFrom before letting it get processed by plugins and components? I assume this is the case but correct me if I am wrong.

  • What happens if the address entered by the sender in the stanza is spoofed btw? I would have assumed this was not allowed and the server would replace the address but I am not sure now.

These questions popped up when I needed to check if the mgs came from the admin or not (using @isAdmin()@, but I need to understand this better anyways for other cases where I have to check the user.

Thank you,

Gabriel


Replies (4)

Added by Wojciech Kapcia TigaseTeam over 4 years ago

I think that the confusion stems from the fact that internally Tigase use Packet objects which enclose regular stanza sent by the user and adds additional information for internal processing hence the Stanza address (e.g. JID of the user) can be different from the actual Packet address (i.e. internal address of the component, in contrast to the address of the component seen by the user). I think that the Packet javadoc explains it quite well.

As for other question - it's not possible to spoof the from address as Tigase will override it with the one that was authorized.

Added by Gabriel Rossetti over 4 years ago

Wojciech Kapcia wrote:

I think that the confusion stems from the fact that internally Tigase use Packet objects which enclose regular stanza sent by the user and adds additional information for internal processing hence the Stanza address (e.g. JID of the user) can be different from the actual Packet address (i.e. internal address of the component, in contrast to the address of the component seen by the user). I think that the Packet javadoc explains it quite well.

Yes it does, thanks, I had looked at the method headers in the code which didn't explain it as well. From what I understand the packet to/from is more for internal processing so I should use the stanza to/from methods, but why do the getTo()@/@getFrom() methods priviledge the packet to/from and not the stanza to/from?

As for other question - it's not possible to spoof the from address as Tigase will override it with the one that was authorized.

Thank you. In which cases do these methods return null btw, from what I understand by the time the packet arrives to a component or plugin the "to/from" (stanza & packet) should be set thus not null, how is this assumption false?

Added by Wojciech Kapcia TigaseTeam over 4 years ago

Gabriel Rossetti wrote:

Yes it does, thanks, I had looked at the method headers in the code which didn't explain it as well. From what I understand the packet to/from is more for internal processing so I should use the stanza to/from methods, but why do the getTo()@/@getFrom() methods priviledge the packet to/from and not the stanza to/from?

It's still mostly use for internal logic hence preference towards packet address over stanzas.

Thank you. In which cases do these methods return null btw, from what I understand by the time the packet arrives to a component or plugin the "to/from" (stanza & packet) should be set thus not null, how is this assumption false?

You can generate packet by component/plugin and set (or not) the values yourself. What I mentioned earlier apply only to to packets received from client connection.

Added by Gabriel Rossetti over 4 years ago

Wojciech Kapcia wrote:

Gabriel Rossetti wrote:

Yes it does, thanks, I had looked at the method headers in the code which didn't explain it as well. From what I understand the packet to/from is more for internal processing so I should use the stanza to/from methods, but why do the getTo()@/@getFrom() methods priviledge the packet to/from and not the stanza to/from?

It's still mostly use for internal logic hence preference towards packet address over stanzas.

Thank you. In which cases do these methods return null btw, from what I understand by the time the packet arrives to a component or plugin the "to/from" (stanza & packet) should be set thus not null, how is this assumption false?

You can generate packet by component/plugin and set (or not) the values yourself. What I mentioned earlier apply only to to packets received from client connection.

Thank you

    (1-4/4)