ejabberd - Comments for "allowing pubsub node suscription whatever jid "

hi cvoluter, did you managed

iharush — Mon, 07 Mar 2016 11:29:49 +0000

hi cvoluter,

did you managed to add a user as "trusted proxies" ?
what was your solution for that?

Thanks,

No, this feature is not

mremond — Fri, 27 Feb 2015 13:34:00 +0000

No, this feature is not supported. As I mentioned is it generally not a good approach to grant right to privileged users. It means that you have a way to seriously compromise your service if the password for that user is compromised.

If you still want to go that way, I think you will need to change the Pubsub code is a custom way.

Hello , In section 6.1.3.1

cvoluter — Fri, 27 Feb 2015 11:45:07 +0000

Hello ,

In section 6.1.3.1 JIDs Do Not Match, you have a note that explain 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 blacklisting of entities that are not allowed to perform specific operations (such as subscribing or creating nodes).

Ejabberd can be set user as "trusted proxies" ?

thanks,

Hello, The behaviour you

mremond — Thu, 26 Feb 2015 14:25:54 +0000

Hello,

The behaviour you describe would not be conforme to the PubSub specification as described in XEP-0060: Publish-Subscribe.

More specifically, section 6.1.3.1 JIDs Do Not Match is self explanatory:

6.1.3.1 JIDs Do Not Match

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.

If the bare JID portions of the JIDs do not match as described above and the requesting entity does not have some kind of admin or proxy privilege as defined by the implementation, the service MUST return a error, which SHOULD also include a pubsub-specific error condition of <invalid-jid/>.

To have a non-custom PubSub behaviour, you probably need to write your own ejabberd PubSub plugin. However, it really depend what you want to do. Relying on admin status of ejabberd to do privileged operations may be a security risk. I would rather write a custom ejabberd module to handle back-end to back-end operation for admin tasks.