Comments (11)
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.
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.
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.
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.
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.
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.
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.
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.
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 typechat
, and clients show them correctlymod_register
sends welcome messages of typenormal
, and you noticed several clients don't show them!mod_announce
sends messages of typeheadline
, 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.
mod_announce
sends messages of typeheadline
, 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.
Closing as the referenced commit should fix the issue.
from ejabberd.
Related Issues (20)
- Ejabberd Access to WebAdmin page vhosts/ for account HOT 5
- create_room_with_opts doen't work anymore as per documentation HOT 2
- WebAdmin is empty in ejabberd 24.06
- Issue Report: Dialyzer Warnings and Common Test Failures HOT 1
- Support spam/abuse report forwarding HOT 1
- mod_mam HOT 2
- Ejabberd service is responding slow HOT 2
- 24.06 rebar3 compatibility HOT 6
- APNS push notification with p2 Proxy HOT 1
- Error: Apparently your account has no administration rights in this server. Please check how to grant admin rights: HOT 5
- Wrong path in start scripts of binary installer invoked by regular user HOT 1
- Error with mod_muc_rtbl when restarting server HOT 1
- mod_push SQL query optimization for PostgreSQL
- [QUESTION] muc_room not getting saved in mysql via API create_room_with_opts HOT 5
- XEP-0478: Stream Limits Advertisement support
- Ejabberd process crashes while user trying to update VCard whith LDAP backend HOT 5
- ejabberdctl request_certificate crashes HOT 1
- Unable to build with OTP 27.0.1 and rebar3 HEAD HOT 6
- Failed RPC connection to the node 'ejabberd@xxx': timeout HOT 9
- XEP-0402: do not return an empty <nick /> if the nicname wasn't set when joined a conference
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ejabberd.