search

esl / MongooseIM

MongooseIM is Erlang Solutions' robust, scalable and efficient XMPP server, aimed at large installations. Specifically designed for enterprise purposes, it is fault-tolerant and can utilise the resources of multiple clustered machines.
Other
1.64k stars 421 forks source link

mod_pubsub using subscribee returns bad-request, invalid-jid #4144

Closed adamramage closed 7 months ago

adamramage commented 7 months ago

MongooseIM version: [6.1.0](version: 6.1.0-445-gdd130793a) Installed from: pkg/docker:latest Erlang/OTP version: (put the version)

Describe the issue.

Background:

I am attempting to subscribe other JIDS to a pub sub topic but when i do so, i am returned bad request errors relating to invalid jids. if the subscribee JID is the same as the JID of the client, it succeeds.

Problem:

below does not work as the subscriber jid is different to the authenticated jid when=2023-10-10T06:14:30.853477+00:00 level=debug what=route pid=<0.3238.0> at=ejabberd_router:route/4:104 from_jid=test@managed.dev-xmpp.foxtel.com.au/1696-918466-452158-9d1494188e3ad523 to_jid=pubsub.managed.dev-xmpp.example.com packet="<iq type='set' to='pubsub.managed.dev-xmpp.example.com' id='1bc32fe0-6325-47a5-9449-a6a6ea1ffd86-5'><pubsub xmlns='http://jabber.org/protocol/pubsub'><subscribe node='adams_topic' jid='61234567890@managed.dev-xmpp.example.com'/></pubsub></iq>" origin_pid=<0.3238.0> acc_timestamp=2023-10-10T06:14:30.853262+00:00

with response: <iq from="pubsub.managed.dev-xmpp.example.com" to="test@managed.dev-xmpp.example.com/1696-917612-648460-6a7e16a2967d6d97" type="error" id="011579b6-6ab0-4eca-afe7-35228f561b62-4"><pubsub xmlns="http://jabber.org/protocol/pubsub"><subscribe node="adams_topic" jid="61234567890@managed.dev-xmpp.example.com" /></pubsub><error code="400" type="modify"><bad-request xmlns="urn:ietf:params:xml:ns:xmpp-stanzas" /><invalid-jid xmlns="http://jabber.org/protocol/pubsub#errors" /></error></iq>

the only interesting part in the logs is below where it indicates the jid is incorrect when=2023-10-10T06:00:12.980015+00:00 level=debug what=local_routing pid=<0.3139.0> at=ejabberd_local:do_route/4:364 from_jid=pubsub.managed.dev-xmpp.example.com to_jid=test@managed.dev-xmpp.example.com/1696-917612-648460-6a7e16a2967d6d97 packet="<iq type='error' from='pubsub.managed.dev-xmpp.example.com' id='011579b6-6ab0-4eca-afe7-35228f561b62-4'><pubsub xmlns='http://jabber.org/protocol/pubsub'><subscribe node='adams_topic' jid='61234567890@managed.dev-xmpp.example.com'/></pubsub><error code='400' type='modify'><bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/><invalid-jid xmlns='http://jabber.org/protocol/pubsub#errors'/></error></iq>" origin_pid=<0.3139.0> acc_timestamp=2023-10-10T06:00:12.976433+00:00

I am using the sleekxmpp pubsub_client.py code to drive this, given i can change the subscribee component to match the basejid and it works along with the payload appearing to be compliant, im confident this can be excluded as a cause.

chrzaszcz commented 7 months ago

Hi @adamramage. The described behaviour is exactly as defined in XEP-0060, Section 6.1.3.1. Subscribing another user would be against the specification, so it is not allowed. The returned error is exactly the same as in the example. I am closing this issue, because everything works as specified in the standard.

adamramage commented 7 months ago

thanks @chrzaszcz: Thought i searched enough for the error but didnt see it in there..

per the note, there is an option which could allow an administrator to make the change as a 'trusted proxy" does mim allow this?

Note: An implementation MAY enable the service administrator to configure a list of entities that are excluded from this check; those entities may be considered "trusted proxies" that are allowed to subscribe on behalf of other entities. In the same way, implementations MAY enable listing of entities that are not allowed to perform specific operations (such as subscribing or creating nodes).

Hijacking this issue for an addition related question, does Erlang have any advice on implementation limits regarding maximum number of topics, maximum number of subscribees per topic? I have tried to find anything about this but there doesn't seem to be much. I'm assuming for the most part, it will be a resource limitation for the host infrastructure. we have 9 c5.4xlarge instances.