preevents in stanzarouter

[Damian Minkov]

Hi all,

I have a question about this commit:

https://hg.prosody.im/0.12/rev/067ada779ea5

What was the reasoning behind it? 

We have currently problem where we don't have control over some presences that are coming over the s2s connection and are immediately routed to the muc occupants without any event or a way to either to filter them or to change them.

Any ideas?

Thank you

 

[Matthew Wild]

Hi Damian,

On Tue, 23 May 2023 at 23:20, Damian Minkov <dame...@damencho.com> wrote:
>
> Hi all,
>
> I have a question about this commit:
> https://hg.prosody.im/0.12/rev/067ada779ea5
>
> What was the reasoning behind it?

That commit was made on the same day that the pre-stanza event was
introduced ( https://hg.prosody.im/0.12/rev/08e3063eb1ac ).

I should have included the reasoning in the commit message, but it was
because receiving a stanza over s2s after that commit would result in
the following traceback:

Traceback[s2s]: ./core/stanza_router.lua:177: attempt to index a nil
value (field '?')
stack traceback:
./core/stanza_router.lua:177: in upvalue 'core_post_stanza'
./core/stanza_router.lua:128: in upvalue 'core_process_stanza'
plugins/mod_s2s/mod_s2s.lua:570: in upvalue 'func'
./util/async.lua:127: in function <./util/async.lua:125>

The line it failed on was:
https://hg.prosody.im/0.12/file/08e3063eb1ac/core/stanza_router.lua#l177

s2s sessions don't have a 'host' property (they have 'to_host' and
'from_host'). The original purpose of this event was access control,
ensuring local sessions could be restricted based on their role. The
current pre events did not suffice for a number of reasons, partly
because the logic to ensure that a stanza sent and received by the
same same user was only processed once was very complex. This event is
designed to only fire once per stanza generated by local users.

> We have currently problem where we don't have control over some presences that are coming over the s2s connection and are immediately routed to the muc occupants without any event or a way to either to filter them or to change them.

Any stanza that is received over s2s and delivered to a local JID will
fire other events. If they're addressed to occupant MUC JIDs, the MUC
is handling those events for example. If they are addressed to the
user's real JID, they are being handled by mod_presence. You can load
mod_log_events to log all events that are fired.

I'd be very surprised if no existing events were suitable for your
use-case, but if you're convinced they're not, I'm certainly curious
to hear more (such as some example to/from JIDs).

Regards,
Matthew

[Damian Minkov]

Hi Matt,

Yeah it is a strange situation in our environment. We have some jid rewriting and it turns out that s2s is coming in and its destination is a remote ... yeah, I will further debug it ... but yeah I was surprised I cannot get events for those stanzas.  But maybe because our from was broken ... as you have pointed 

So this is what we are hitting:

stanzarouter error No hosts[from_host] (please report) <presence....

 /usr/share/lua/5.2/prosody/core/stanza_router.lua:210: in function 'core_route_stanza'
/usr/share/lua/5.2/prosody/core/stanza_router.lua:192: in function </usr/share/lua/5.2/prosody/core/stanza_router.lua:150>
(...tail calls...)
/usr/lib/prosody/modules/muc/muc.lib.lua:1371: in function 'route_stanza'
/usr/lib/prosody/modules/muc/muc.lib.lua:140: in function 'route_to_occupant'
/usr/lib/prosody/modules/muc/muc.lib.lua:312: in function 'publicise_occupant_status'
/usr/lib/prosody/modules/muc/muc.lib.lua:744: in function </usr/lib/prosody/modules/muc/muc.lib.lua:618>
(...tail calls...)
/usr/share/lua/5.2/prosody/util/events.lua:81: in function </usr/share/lua/5.2/prosody/util/events.lua:77>
(...tail calls...)
/usr/share/lua/5.2/prosody/core/stanza_router.lua:188: in function 'core_post_stanza'
/usr/share/lua/5.2/prosody/core/stanza_router.lua:128: in function 'core_process_stanza'
/usr/lib/prosody/modules/mod_s2s.lua:733: in function 'func'
/usr/share/lua/5.2/prosody/util/async.lua:144: in function </usr/share/lua/5.2/prosody/util/async.lua:142>

I will further debug and will update the thread.

--
You received this message because you are subscribed to the Google Groups "prosody-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prosody-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prosody-dev/CAJt9-x7n4%3Ddme0ZD_5FF-NQB3-7tQERMOaqk4%3D5CWwZaaYimgw%40mail.gmail.com.