Hi Damian, On Tue, 23 May 2023 at 23:20, Damian Minkov <damen...@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 -- 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+unsubscr...@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.
