Messages sent with `mod_privilege` are not carbon-copied

[truenicoco]

Is your feature request related to a problem? Please describe. Messages sent by components through mod_privilege (XEP-0356) are not carbon-copied to connected clients of the impersonated user. I use it to reflect messages sent by a gateway user via a non-XMPP client. In my use-case at least, the whole point of sending messages on behalf of an XMPP account is to trigger sending carbon-copies and being archived in the user MAM, so chat history between the bridged network and XMPP is similar.

Describe the solution you'd like Sending a message on behalf of a user XMPP account via mod_privilege should produce the same results as this user sending a message from an XMPP client. In practice, this means sending carbon copies to other connected resources of this account and archiving the message in their personal MAM archive, depending on the server/user preferences and possible message processing hints.

Describe alternatives you've considered I think a possible alternative for slidge is to write the carbon-copy stanza and send it to all connected resources of the impersonated user. I don't think this solves the archiving problem, since carbons are not supposed to be archived.

Additional context Prosody's mod_privilege (a community module) used to behave the same as ejabberd.

[badlop]

Looking at the module source code in https://github.com/processone/ejabberd/blob/dd2efc360b7f6371f870c56a1cf8c4a6c50b87df/src/mod_privilege.erl#L400 the content is extracted and sent with no modifications. Maybe the changes you are noticing are performed during xmpp library parsing?

Is there any example of stanza sent, and what is finally received by the destination?

Or add this debug line to ejabberd, recompile, trigger the problem and copy here the information logged:

```diff diff --git a/src/mod_privilege.erl b/src/mod_privilege.erl index 3862b33c7..c60c41a65 100644 --- a/src/mod_privilege.erl +++ b/src/mod_privilege.erl @@ -403,6 +403,7 @@ forward_message(#message{to = To} = Msg) -> #message{} = NewMsg -> case NewMsg#message.from of #jid{lresource = <<"">>, lserver = ServerHost} -> + ?INFO_MSG("forward_message ~n Msg: ~p~n NewMsg~p", [Msg, NewMsg]), ejabberd_router:route(NewMsg); _ -> Lang = xmpp:get_lang(Msg), ```

[truenicoco]

I am not running ejabberd myself, I develop a component that uses XEP-0356; I learned about this behaviour through reports from users of the component. (I use prosody myself).

Maybe the changes you are noticing are performed

There are no changes in the sent message and sending messages on behalf of a user's JID works. But this message does not make ejabberd send message carbons (XEP-0280) to other active resources of the impersonated account. Thus, only the recipient of the message ever gets the message, but the impersonated user never sees it anywhere, neither in their other online clients (carbons) nor when querying MAM.

FWIW, the current behaviour of ejabberd's mod_privilege is in line with what prosody's was before this patch. However, I checked with goffi (XEP author) and he agrees that generating carbons and being stored in MAM is in the spirit of the specification, even though not explicitly stated. Maybe I should propose a patch to XEP0356 to make it explicit.

[badlop]

Ok, I wrote an experimental patch for this, included Holger's fix for the roster push problem, and all this can be tested using containers. Check the list of changes from ejabberd upstream.

If more people would be able to test those changes and report their results, it would be great.

How to quickly test the experimental changes in ejabberd to support Slidge

1. Create a file called include.yml with content:

define_macro:
  MYSERVER: example.org
  MYSLIDGE: slidge.example.org

Replace example.org with a valid host name where facebook will be able to contact your server.

2. Then start this ejabberd experimental container in attached mode:

podman run \
       --network=host \
       --name=ejabberd \
       -it \
       -v $(pwd)/include.yml:/opt/ejabberd/conf/include.yml \
       ghcr.io/badlop/ejabberd:slidge

3. Start messlidger, replacing example.org accordingly:

podman run \
       --network=host \
       --name=messlidger \
       docker.io/nicocool84/messlidger:master \
       --secret=secret \
       --jid=slidge.example.org \
       --admins admin@example.org \
       --user-jid-validator .*@example.org

4. ejabberd should show:

2023-06-28 14:34:20.605847+00:00 [info] (<0.913.0>)
 Accepted connection 127.0.0.1:35006 -> 127.0.0.1:5347
2023-06-28 14:34:20.609973+00:00 [info] (tcp|<0.913.0>)
 Accepted external component handshake authentication
 for slidge.example.org from 127.0.0.1
2023-06-28 14:34:20.612838+00:00 [info]
 Granting permissions to external component 'slidge.example.org':
 roster = both, presence = none, message = outgoing

And messlidger should show:

INFO:slidge.core.gateway.base:Slidge has successfully started

5. This works great with Gajim: register an account in example.org (for example admin@example.org), open the Service Discovery, select "Facebook", click Command, select "Register to the gateway", click Execute, in the form provide the email and password of your facebook account, click Next.

6. messlidger should log:

   INFO:slidge.core.gateway.base:Login success for <User admin@example.org>

7. Also, Gajim should receive all your facebook contacts and a welcoming message from the transport. Now you can send messages to your contacts, your contacts can message you, and any message sent from your account in facebook should be carbon copied in gajim.

[ravermeister]

I'd love to try that out. Is there any way to test it when I'm using the installer (.run) script to install ejabberd (as non root)?

[badlop]

@ravermeister I've triggered the generation of installers. If it finishes successfully, in one or two hours they should be available on the bottom of the action run in https://github.com/badlop/ejabberd/actions/runs/5424912285

So far I've tried slidge-whatsapp and messlidger, both work perfectly. slidgram however has problems after succesfully registering the account. If you are able to test those or other, please comment your results

[ravermeister]

@badlop I've tested the 'sending on behalf of a user' from whatsapp original client, and it worked with gajim/cheogram, great Thanks! means I saw my own message, that I've sent to a WA recipient via whatsapp original Client in gajim/cheogram. Next will be signal, I'll update this post when I'm done :)

Update: slidge-signal (slidgnal) works too

[badlop]

Ok, I tested and worked correctly (register, receive contacts, send and receive messages): whatsapp, discord, steam, skype and facebook.

The telegram one, when using its experimental tag, works correctly: it throws some error messages, but roster contacts and messaging works correctly.

[ravermeister]

looking forward for this to arrive in upstream :). until this happens I'll stick with your Version you created here Thanks again :)