Giter Club home page Giter Club logo

Comments (11)

badlop avatar badlop commented on August 26, 2024

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.

from ejabberd.

MrEddX avatar MrEddX commented on August 26, 2024

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:
      - "[email protected]"
      - "[email protected]"
    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.

from ejabberd.

badlop avatar badlop commented on August 26, 2024

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 "[email protected]"

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.

from ejabberd.

MrEddX avatar MrEddX commented on August 26, 2024

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 [email protected] 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
[email protected] 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 [email protected] *The snippet below
<message to='[email protected]'
         from='domain.tld'
         xmlns='jabber:client'>
  <archived by='[email protected]'
            id='1720507444561113'
            xmlns='urn:xmpp:mam:tmp'/>
  <stanza-id by='[email protected]'
             id='1720507444561113'
             xmlns='urn:xmpp:sid:0'/>
  <body xml:lang='en'>Welcome message here</body>
</message>

I sent a message to [email protected] 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 [email protected] 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.

from ejabberd.

licaon-kter avatar licaon-kter commented on August 26, 2024

just a FYI, latest Conversations +free is 2.16.4 too πŸ‘…

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

from ejabberd.

MrEddX avatar MrEddX commented on August 26, 2024

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.

from ejabberd.

badlop avatar badlop commented on August 26, 2024

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 [email protected] 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:

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 = <<"
<message to='admin5@localhost'
         from='localhost'>
  <archived by='admin5@localhost'
            id='1720706824821547'
            xmlns='urn:xmpp:mam:tmp' />
  <stanza-id by='admin5@localhost'
             id='1720706824821547'
             xmlns='urn:xmpp:sid:0' />
  <delay from='localhost'
         stamp='2024-07-11T14:07:04.865880Z'
         xmlns='urn:xmpp:delay'>Offline storage</delay>
  <body xml:lang='en'>Body text here</body>
  <subject xml:lang='en'>Welcome!</subject>
</message>
">>

from ejabberd.

MrEddX avatar MrEddX commented on August 26, 2024

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 = <<>>,
...

from ejabberd.

badlop avatar badlop commented on August 26, 2024

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 --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(<<Subj/binary, "\n\n", Body/binary>>)}),
 	  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?

from ejabberd.

MrEddX avatar MrEddX commented on August 26, 2024
  • 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.

from ejabberd.

mremond avatar mremond commented on August 26, 2024

Closing as the referenced commit should fix the issue.

from ejabberd.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.