Newly registered users don't receive welcome message

MrEddX commented 1 week ago

Environment

ejabberd version: 24.06
Erlang version: Erlang/OTP 24 [erts-12.2.1] [source] [64-bit] [smp:2:2] [ds:2:2:10] [async-threads:1]
OS: Linux (Ubuntu 22.04.4 LTS)
Installed from: distro package

Errors from error.log/crash.log

No errors

Bug description

Since I updated ejabberd from from version 23.10 to version 24.02, noticed that the option welcome_message: of the module mod_register no longer works as expected. Newly registered users do not receive the welcome message anymore. No changes have been made during this time to the configuration file, so that's why I am not sharing it here. After updating to version 24.06, the problem persists.

Please, can someone using this feature, confirm that it works so I know if it makes sense to continue looking for the cause on my side?

Thank you!

badlop commented 1 week ago

I've tested with ejabberd 23.10, 24.02 and 24.06. In all cases with the same configuration:

modules:
  ...
  mod_register:
    ip_access: trusted_network
    welcome_message:
      subject: "hi you"
      body: "Hi\nWelcome Body"

I register an account with Tkabber, using In-Band Registration, and it receives the messages with all the tested ejabberd versions.

Just for completeness, I've also tested with the container image:

podman run --name ejabberd -it -p 5222:5222 ghcr.io/processone/ejabberd live

podman exec -it ejabberd vi /opt/ejabberd/conf/ejabberd.yml

and configure mod_register with only this:

  mod_register:
    welcome_message:
      body: "This is the body"

Then:

podman exec -it ejabberd ejabberdctl reload_config

When the client registers the account and logins, it receives:

<!-- 15:56:34.383 IN (::xmpp::9, admin235@localhost/tka1) -->
<message to='admin235@localhost'
    from='localhost'>
  <archived by='admin235@localhost'
    id='1720187794065880'
    xmlns='urn:xmpp:mam:tmp'/>
  <stanza-id by='admin235@localhost'
    id='1720187794065880'
    xmlns='urn:xmpp:sid:0'/>
  <delay from='localhost'
    stamp='2024-07-05T13:56:34.090684Z'
    xmlns='urn:xmpp:delay'>Offline storage</delay>
  <body xml:lang='en'>This is the body</body>
</message>

Notice that this feature requires mod_offline to be enabled.

MrEddX commented 1 week ago

Thank you for your time and comprehensive response.

The module mod_offline is enabled. Тhese are the sections of the configuration file responsible for performing this function:

...
modules:
...
  mod_offline:
    access_max_user_messages: max_user_offline_messages
...
  mod_register:
    password_strength: 64
    captcha_protected: true
    registration_watchers:
      - "user@domain.tld"
      - "admin@domain.tld"
    welcome_message:
      subject: "Welcome to domain.tld!"
      body: |-
        Language 1
        text here

        *     *     *     *     *     *     *

        Language 2
        text here

    ip_access: all

I also tried with a simplified version - same result.

...
modules:
...
  mod_register:
    welcome_message:
      subject: "Welcome!"
      body: "Body text here"
    ip_access: all
...

What do you think would be a good starting point for debugging such a situation?

Thank you @mremond and @badlop.

badlop commented 1 week ago

Looking at mod_register:try_register, the code is fairly simple, let's follow it and propose some tests you can try:

A) log message is displayed?

Do you see in ejabberd.log the line "The account X was registered from IP addresss..." ?

Immediately after that the send_welcome_function is executed for account X.

B) non-latin1 characters and some bug in ejabberd?

Is account X correctly displayed? Maybe it has non-latin1 characters? You can try with simple strings like "user1@example.com"

C) welcome_message option cannot be retrieved?

The send_welcome_message function gets the configured value of welcome_message. Maybe it's incorrectly retrieved for some reason. Start an interactive erlang shell in your ejabberd and check the option:

$ ejabberdctl debug
Erlang/OTP 26 [erts-14.2.5] [source] [64-bit] [smp:4:4] [ds:4:4:10] [async-threads:1] [jit:ns]
Eshell V14.2.5 (press Ctrl+G to abort, type help(). for help)

(ejabberd@localhost)1> mod_register_opt:welcome_message(<<"localhost">>).
{<<"Welcome to domain.tld!">>,
 <<"Language 1\ntext here\n\n*     *     *     *     *     *     *\n\nLanguage 2\ntext here">>}

D) Is the welcome message stored in offline queue?

If the option is set, that function immediately sends a message stanza to the account. You could try to register the account using In Band Registration but NOT login yet, and see if the message is stored in the offline table.

If your client registers the account and immediately logins, you can try this: setup in your jabber client as presence priority a negative value, like -5 for example. That way, when the client logins, ejabberd does NOT send offline messages to him.

Then check if that account has the welcome message stored at his offline queue

http://localhost:5280/admin/server/localhost/user/user1/queue/ or in the mnesia table http://localhost:5280/admin/node/ejabberd@localhost/db/table/offline_msg/elements/1/

E) Does client login with positive priority to get offline messages?

Login to that account with a zero or positive priority, for example 8, then ejabberd will send to the client the offline messages, including the welcome message. If the account has offline messages stored in the queue, but does not send them to the client after login, then maybe you are setting a negative presence priority.

MrEddX commented 6 days ago

I appreciate your time and detailed instructions @badlop! I'm really impressed.

TL;DR

Since the problem is most likely not related to ejabberd, here are the results so far:

Client software	OS	Мessage received
blabber.im v3.1.4	Android 10	✅
Dino v0.4.3 - Ilulissat	Ubuntu 24.04	✅
Kaidan v0.9.1	Ubuntu 24.04	✅
Conversations v2.15.0+free	Android 6	❌
Conversations v2.16.4+playstore	Android 10	❌
monocles chat v1.7.9.6	Android 10	❌
monocles chat v1.7.9.6	Android 13	❌
Snikket v2.13.4-2+free	Android 10	❌
Gajim v1.9.0	Windows 10	❌
Gajim v1.9.0	Ubuntu 24.04	❌
Converse.js v10.1.5	Desktop App	❌
Converse.js v10.1.7	Browser	❌

Conclusion: The search should be redirected to the client application logs.

The Long Story

A) log message is displayed?

Yes. A log message is displayed. Tested with the client apps mentioned above.

...
2024-07-09 07:58:53.120925+03:00 [info] <0.913.0>@mod_register:try_register/6:368 The account test2@domain.tld was registered from IP address ::ffff:xxx.xxx.xxx.xxx
...

B) non-latin1 characters and some bug in ejabberd?

No non-latin1 characters are used in the account name(s).

C) welcome_message option cannot be retrieved?

I have no experience with the erlang shell and for that the only thing I did was copy/paste the command in the erlang shell.

mod_register_opt:welcome_message(<<"localhost">>). {<<"Welcome to domain.tld!">>, <<"Language 1\ntext here\n\n* * * * * * *\n\nLanguage 2\ntext here">>}

The output was:

..

I have no idea what that means.

D) Is the welcome message stored in offline queue?

Yes. It is stored when an account is only registered, but didn't log in. It doesn't matter if the message is the long version (With subject and body in two different languages) or the short version (only with a short body without subject).

Users

User	Offline	Roster	Timestamp	Status
test2@domain.tld	1	0	2024-07-09T06:44:04Z	Registered but didn't login

If I click on the Offline counter:

Time	From	To	Packet
2024-07-09 09:44:04	domain.tld	test2@domain.tld	*The snippet below

<message to='test2@domain.tld'
         from='domain.tld'
         xmlns='jabber:client'>
  <archived by='test2@domain.tld'
            id='1720507444561113'
            xmlns='urn:xmpp:mam:tmp'/>
  <stanza-id by='test2@domain.tld'
             id='1720507444561113'
             xmlns='urn:xmpp:sid:0'/>
  <body xml:lang='en'>Welcome message here</body>
</message>

I sent a message to test2@domain.tld from another account, before he logged in. Now the Offline counter changed from 1 to 2 and the message is visible in the table. So far everything works as expected.

And now the interesting part: The moment test2@domain.tld logs in, he only receives the message from the other user who sent him a message, while he was offline, but not the welcome (system) message. The Offline counter is now set to 0 (which is expected). The question is: Where does the welcome message go?

E) Does client login with positive priority to get offline messages?

Gajim's default priority is 0. Changing to 8 doesn't make the welcome message to appear.

licaon-kter commented 5 days ago

just a FYI, latest Conversations +free is 2.16.4 too :tongue:

blabber.im is 2 years old, stop using it pls, backup and restore in Conversations

MrEddX commented 5 days ago

Thanks @licaon-kter. I am aware of that. Don't worry, they were only used for testing purposes. We're just trying to figure out where the problem is coming from. I don't understand if it is due to the server configuration or something is happening during the communication with the client application.

badlop commented 4 days ago

C)

FYI, in the erlang shell, type only the command, that ends with a dot . The other text I shows is the expected result. Anyway, that's not the problem in this case.

D)

The moment test2@domain.tld logs in, he only receives the message from the other user who sent him a message, while he was offline, but not the welcome (system) message.

You say "he receives", but properly speaking, you only checked what do the XMPP clients show to the human. You didn't check what do the XMPP clients receive from the server, right?. For that, open the client XML Console, or Raw Console, or whatever it's called. At least Gajim has a very good raw xml console.

Unfortunately, I cannot test with Gajim (it requires a fully signed certificate and does not accept a self-signed cert, or non-encryption).

F)

Pidgin receives the welcome message, but shows it as a chat message, so the Subject is not displayed, only the Body.

Notice that the welcome message is a message stanza of type=normal with optional subject and body. Maybe some clients don't show properly message stanzas of type=normal? You can try sending from a client to another client a stanza similar to what ejabberd sends as welcomen message... do they show it properly?

You can also experiment removing the Subject element.

G)

If you enabled contributed or custom modules, maybe they affect the stanza forwarding?

H)

And it would be worth checking if the server sends the stanza or not. I guess you have encrypted traffic, so sniffing the network is useless. If it's a small server, you can set loglevel: debug, register an account (in this example admin5@localhost), when it logins, ejabberd shows that it is sending the welcome message from offline queue:

```xml 2024-07-11 16:07:05.077925+02:00 [debug] Route: #message{id = <<>>,type = normal,lang = <<>>, from = #jid{user = <<>>,server = <<"localhost">>,resource = <<>>, luser = <<>>,lserver = <<"localhost">>,lresource = <<>>}, to = #jid{user = <<"admin5">>,server = <<"localhost">>, resource = <<>>,luser = <<"admin5">>, lserver = <<"localhost">>,lresource = <<>>}, subject = [#text{lang = <<"en">>,data = <<"Welcome!">>}], body = [#text{lang = <<"en">>,data = <<"Body text here">>}], thread = undefined, sub_els = [#xmlel{name = <<"archived">>, attrs = [{<<"by">>,<<"admin5@localhost">>}, {<<"id">>,<<"1720706824821547">>}, {<<"xmlns">>,<<"urn:xmpp:mam:tmp">>}], children = []}, #xmlel{name = <<"stanza-id">>, attrs = [{<<"by">>,<<"admin5@localhost">>}, {<<"id">>,<<"1720706824821547">>}, {<<"xmlns">>,<<"urn:xmpp:sid:0">>}], children = []}, #delay{stamp = {1720,706824,865880}, from = #jid{user = <<>>,server = <<"localhost">>, resource = <<>>,luser = <<>>, lserver = <<"localhost">>, lresource = <<>>}, desc = <<"Offline storage">>}], meta = #{from_offline => true}} 2024-07-11 16:07:05.078198+02:00 [debug] Local route: #message{id = <<>>,type = normal,lang = <<>>, from = #jid{user = <<>>,server = <<"localhost">>,resource = <<>>, luser = <<>>,lserver = <<"localhost">>,lresource = <<>>}, to = #jid{user = <<"admin5">>,server = <<"localhost">>, resource = <<>>,luser = <<"admin5">>, lserver = <<"localhost">>,lresource = <<>>}, subject = [#text{lang = <<"en">>,data = <<"Welcome!">>}], body = [#text{lang = <<"en">>,data = <<"Body text here">>}], thread = undefined, sub_els = [#xmlel{name = <<"archived">>, attrs = [{<<"by">>,<<"admin5@localhost">>}, {<<"id">>,<<"1720706824821547">>}, {<<"xmlns">>,<<"urn:xmpp:mam:tmp">>}], children = []}, #xmlel{name = <<"stanza-id">>, attrs = [{<<"by">>,<<"admin5@localhost">>}, {<<"id">>,<<"1720706824821547">>}, {<<"xmlns">>,<<"urn:xmpp:sid:0">>}], children = []}, #delay{stamp = {1720,706824,865880}, from = #jid{user = <<>>,server = <<"localhost">>, resource = <<>>,luser = <<>>, lserver = <<"localhost">>, lresource = <<>>}, desc = <<"Offline storage">>}], meta = #{from_offline => true}} 2024-07-11 16:07:05.078561+02:00 [debug] Running hook sm_receive_packet: mod_mam:sm_receive_packet/1 2024-07-11 16:07:05.078720+02:00 [debug] Processing message to bare JID: #message{id = <<>>,type = normal,lang = <<>>, from = #jid{user = <<>>,server = <<"localhost">>,resource = <<>>, luser = <<>>,lserver = <<"localhost">>,lresource = <<>>}, to = #jid{user = <<"admin5">>,server = <<"localhost">>, resource = <<>>,luser = <<"admin5">>, lserver = <<"localhost">>,lresource = <<>>}, subject = [#text{lang = <<"en">>,data = <<"Welcome!">>}], body = [#text{lang = <<"en">>,data = <<"Body text here">>}], thread = undefined, sub_els = [#xmlel{name = <<"archived">>, attrs = [{<<"by">>,<<"admin5@localhost">>}, {<<"id">>,<<"1720706824821547">>}, {<<"xmlns">>,<<"urn:xmpp:mam:tmp">>}], children = []}, #xmlel{name = <<"stanza-id">>, attrs = [{<<"by">>,<<"admin5@localhost">>}, {<<"id">>,<<"1720706824821547">>}, {<<"xmlns">>,<<"urn:xmpp:sid:0">>}], children = []}, #delay{stamp = {1720,706824,865880}, from = #jid{user = <<>>,server = <<"localhost">>, resource = <<>>,luser = <<>>, lserver = <<"localhost">>, lresource = <<>>}, desc = <<"Offline storage">>}], meta = #{from_offline => true}} ... 2024-07-11 16:07:05.089327+02:00 [notice] (tcp|<0.2616.0>) Send XML on stream = <<"

Offline storage Body text here Welcome!

">> ```

MrEddX commented 3 days ago

D)

You are absolutely right. The welcome message is present in the Gajim's Debug Console. It is simply not displayed to the user by the application.

F)

The result is as in D). Sending a message from a client to another client with stanza of type=normal is not shown to the user, but is present in the Gajim's console. In case the stanza is changed to type=chat the message is displayed to the user, as expected.

I see that mod_register does not have an option to choose what type of stanza to be used. The strange thing (for me) is that when the option registration_watchers is enabled, these (system) messages are sent as stanza of type=chat and of course they are shown to the respective user(s). I don't know why but I expected them to be sent as type=normal as well.

Removing the Subject makes no change.

G)

No such modules activated.

H)

Yes the server sends the stanza and the traffic is encrypted.

...
2024-07-12 09:52:06.093697+03:00 [debug] <0.20672.0>@ejabberd_sm:do_route/1:719 Processing message to bare JID:
#message{id = <<>>,type = normal,lang = <<>>,
         from = #jid{user = <<>>,server = <<"domain.tld">>,resource = <<>>,
...

badlop commented 3 days ago

Sending a message from a client to another client with stanza of type=normal is not shown to the user, but is present in the Gajim's console. In case the stanza is changed to type=chat the message is displayed to the user, as expected.

Aha!

In summary:

mod_register sends message to registration_watchers of type chat, and clients show them correctly
mod_register sends welcome messages of type normal, and you noticed several clients don't show them!
mod_announce sends messages of type headline, do clients show them correctly?

Then comes the obvious question: how can clients fail to show properly normal messages? That is clearly specified since years ago in the protocol. Specially Gajim, as it's a well established XMPP client.

Considering that welcome messages are not expected to be replied, it made sense to send them as headline, not normal or chat. Unfortunately, headline messages are not stored in offline queue and that is fundamental for welcome message.

In summary, the only method I can find is to send welcome messages as type chat to ensure all clients display them correctly. And maybe do this in addition to the normal message. Something like this:

```diff diff --git a/src/mod_register.erl b/src/mod_register.erl index 7da8ca74a..d656263bf 100644 --- a/src/mod_register.erl +++ b/src/mod_register.erl @@ -412,6 +412,12 @@ send_welcome_message(JID) -> case mod_register_opt:welcome_message(Host) of {<<"">>, <<"">>} -> ok; {Subj, Body} -> + ejabberd_router:route( + #message{from = jid:make(Host), + to = JID, + type = chat, + subject = xmpp:mk_text(Subj), + body = xmpp:mk_text(<>)}), ejabberd_router:route( #message{from = jid:make(Host), to = JID, ```

But there's something that puzzles me:

Since I updated ejabberd from from version 23.10 to version 24.02, noticed that the option welcome_message: of the module mod_register no longer works as expected.

Nothing relevant has changed in mod_register between 23.10 and 24.02. Are you sure those clients received the welcome message in previous versions, or probably they never did?

MrEddX commented 3 days ago

mod_announce sends messages of type headline, do clients show them correctly?

I tried sending such a message type=headline through the web admin. It is displayed by Conversations. Dino doesn't show the message. In Gajim it appears only in the console.

Do you think it's appropriate to notify the developers of the respective client apps?

Nothing relevant has changed in mod_register between 23.10 and 24.02. Are you sure those clients received the welcome message in previous versions, or probably they never did?

In conclusion, I can say: It must be a coincidence. However, during this time, quite a few updates have been made to the client applications as well. I don't think the problem is related to Ejabberd in any way.

mremond commented 15 hours ago

Closing as the referenced commit should fix the issue.

processone / ejabberd