search

processone / ejabberd

Robust, Ubiquitous and Massively Scalable Messaging Platform (XMPP, MQTT, SIP Server)
https://www.process-one.net/ejabberd/
Other
6.12k stars 1.51k forks source link

Can't send message to MUC room using "ejabberdctl send_message" or REST API since 20.01 #3485

Closed royrwood closed 3 years ago

royrwood commented 3 years ago

Environment

Configuration (only if needed): grep -Ev '^$|^\s*#' ejabberd.yml

hosts:
  - "ejabberd.roy.org"
loglevel: 4
log_rotate_size: 10485760
log_rotate_date: ""
log_rotate_count: 1
log_rate_limit: 100
certfiles:
  - "/home/rrwood/ejabberd-20.02/conf/server.pem"
ca_file: "/home/rrwood/ejabberd-20.02/conf/cacert.pem"
listen:
  -
    port: 5222
    ip: "::"
    module: ejabberd_c2s
    max_stanza_size: 262144
    shaper: c2s_shaper
    access: c2s
    starttls_required: true
  -
    port: 5269
    ip: "::"
    module: ejabberd_s2s_in
    max_stanza_size: 524288
  -
    port: 5443
    ip: "::"
    module: ejabberd_http
    tls: true
    request_handlers:
      "/admin": ejabberd_web_admin
      "/api": mod_http_api
      "/bosh": mod_bosh
      "/captcha": ejabberd_captcha
      "/upload": mod_http_upload
      "/ws": ejabberd_http_ws
      "/oauth": ejabberd_oauth
  -
    port: 5280
    ip: "::"
    module: ejabberd_http
    request_handlers:
      "/admin": ejabberd_web_admin
  -
    port: 1883
    ip: "::"
    module: mod_mqtt
    backlog: 1000
s2s_use_starttls: optional
oauth_expire: 3600
oauth_access: all
acl:
  local:
    user_regexp: ""
  loopback:
    ip:
      - 127.0.0.0/8
      - ::1/128
      - ::FFFF:127.0.0.1/128
  admin:
    user:
      - "admin@ejabberd.roy.org"
access_rules:
  local:
    allow: local
  c2s:
    deny: blocked
    allow: all
  announce:
    allow: admin
  configure:
    allow: admin
  muc_create:
    allow: local
  pubsub_createnode:
    allow: local
  trusted_network:
    allow: loopback
api_permissions:
  "console commands":
    from:
      - ejabberd_ctl
    who: all
    what: "*"
  "admin access":
    who:
      access:
        allow:
          acl: admin
      oauth:
        scope: "ejabberd:admin"
        access:
          allow:
            acl: admin
    what:
      - "*"
      - "!stop"
      - "!start"
  "public commands":
    who:
      ip: 127.0.0.1/8
    what:
      - status
      - connected_users_number
shaper:
  normal: 1000
  fast: 50000
shaper_rules:
  max_user_sessions: 10
  max_user_offline_messages:
    5000: admin
    100: all
  c2s_shaper:
    none: admin
    normal: all
  s2s_shaper: fast
max_fsm_queue: 10000
acme:
   contact: "mailto:admin@ejabberd.roy.org"
   ca_url: "https://acme-v01.api.letsencrypt.org"
modules:
  mod_adhoc: {}
  mod_admin_extra: {}
  mod_announce:
    access: announce
  mod_avatar: {}
  mod_blocking: {}
  mod_bosh: {}
  mod_caps: {}
  mod_carboncopy: {}
  mod_client_state: {}
  mod_configure: {}
  mod_disco: {}
  mod_fail2ban: {}
  mod_http_api: {}
  mod_http_upload:
    put_url: https://@HOST@:5443/upload
  mod_last: {}
  mod_mam:
    assume_mam_usage: true
    default: never
  mod_mqtt: {}
  mod_muc:
    access:
      - allow
    access_admin:
      - allow: admin
    access_create: muc_create
    access_persistent: muc_create
    access_mam:
      - allow
    default_room_options:
      allow_subscription: true  # enable MucSub
      mam: false
  mod_muc_admin: {}
  mod_offline:
    access_max_user_messages: max_user_offline_messages
  mod_ping: {}
  mod_privacy: {}
  mod_private: {}
  mod_proxy65:
    access: local
    max_connections: 5
  mod_pubsub:
    access_createnode: pubsub_createnode
    plugins:
      - flat
      - pep
    force_node_config:
      storage:bookmarks:
        access_model: whitelist
  mod_push: {}
  mod_push_keepalive: {}
  mod_register:
    ip_access: trusted_network
  mod_roster:
    versioning: true
  mod_s2s_dialback: {}
  mod_shared_roster: {}
  mod_stream_mgmt:
    resend_on_timeout: if_offline
  mod_vcard: {}
  mod_vcard_xupdate: {}
  mod_version:
    show_os: false

Errors from error.log/crash.log

No errors shown in log

Bug description

Please, give us a precise description (what does not work, what is expected, etc.)

In ejabberd 20.01, it was possible to send messages to a MUC room as admin using ejabberdctl or using the Admin REST API. That stopped working in 20.02, and continues to not work in the latest 20.12.

The following steps indicate how to test and reproduce this problem. These steps work as expected in 20.01, but stop working in 20.02 and later.

prefiks commented 3 years ago

Hello,

In your config hosts: is set to ejabberd.roy.org, but in your commands you are using debian.roy.org, i am assuming that is just edit error in that comment right?

I really don't see any changes between 20.01 and 20.02 that could affect this, in both version it should work in same way.

I just checked that on my local server with latest git version and i see that groupchat send_message are delivered to rooms, but it's important what you use as from in your requests - it must be from someone that is joined right now (you then need to use full jid), someone that is mucsub subscriber of that room, or someone that is muc admin (in that config that would be admin@ejabberd.roy.org, as this is only person that matches acl listed in access_admin option of mod_muc).

I see that psi have problem with messages that this generates - it doesn't like empty <subject/> that are sent when subject is set to "", i just handles them as subject changes with empty subject, i will try to improve this. Maybe something similar happen with your client? But i am pretty sure 20.01 did also generate this...

licaon-kter commented 3 years ago

This is not https://github.com/processone/ejabberd/issues/3474 ?

royrwood commented 3 years ago

Yes, that was a typo in the "ejabberd.roy.org" vs "debian.roy.org". (Should I go back and correct that?)

I don't think this is the same as #3474 since that issue (and patch) is focused on sending private messages from admin to a user.

I looked at the diffs between 20.01 and 20.02 and didn't see anything likely to cause the problem, unless it was in one of the libraries. I have not checked if library versions changed.

I have definitely confirmed that 20.01 does send the message to the MUC room, but 20.02 does not. And yes, for 20.01, the "subject" has to be empty or the message body is ignored, so there is some odd behaviour there.

Thanks for the quick reply.

royrwood commented 3 years ago

I'll try with a different client than profanity. It would be REALLY annoying if the XMPP client was the problem. Though profanity definitely works with 20.01 and not with 20.02 or later. Odd...

royrwood commented 3 years ago

Nope, Thunderbird shows the same behaviour-- i.e. with ejabberd 20.12, the groupchat message from admin does not show. The subject of the room can be cleared or set by admin, but the message never makes it to the clients.

royrwood commented 3 years ago

Hold on-- looking at the xmlconsole in profanity, I see this in response to my attempt to send the message using the Admin REST API:

<message id="6371662130715871347" type="groupchat" to="roy@ejabberd.roy.org/profanity.E" from="test_muc_room@conference.ejabberd.roy.org/admin"><body>Message via
           REST API</body><subject>New Subject</subject></message>

The message body is there as "Message via REST API", but profanity is not showing it. I wonder how that compares to what is sent by ejabberd 20.01? I'll have to swap the servers...

royrwood commented 3 years ago

Weird-- the only difference seems to be the "lang" attribute. Is that enough to break things for a client?!?!?! Both profanity and Thunderbird??!?!?!

20.01:
<message id="6479759090134302045" type="groupchat" to="roy@ejabberd.roy.org/profanity.E" from="test_muc_room@conference.ejabberd.roy.org/admin">
    <body lang="en">Message via REST API</body>
    <subject lang="en">Subject via REST API</subject>
</message>

20.12:
<message id="6371662130715871347" type="groupchat" to="roy@ejabberd.roy.org/profanity.E" from="test_muc_room@conference.ejabberd.roy.org/admin">
    <body>Message via REST API</body>
    <subject>New Subject</subject>
</message>
royrwood commented 3 years ago

Looking at ejabberd 20.01 vs 20.02, the code differences look harmless, so I suspect the source of the change is in the xmpp lib. It changed from version 1.4.2 to 1.4.5. Or maybe fast_xml which went from 1.1.37 to 1.1.39. For any of you guys familiar with ejabberd architecture and internals, what do you think?

Recall that this broke as of 20.02 and remains broken up to 20.12.

prefiks commented 3 years ago

So it looks like those messages are routed in new version as well, and those message looks completly fine to me. Maybe indeed problem is with having subject and body together, maybe your client ignored it previously because of that lang attribute, and now it thinks it just subject change and not regular message?

royrwood commented 3 years ago

Yes, the message stanzas seem okay, and it's just odd that the clients choose to ignore the message body because of the language attribute. I'm surprised that both Profanity and Thunderbird react the same way!

Neustradamus commented 3 years ago

@royrwood: Please edit your description with the good hostname (ejabberd vs debian), it will be better to all ^^