comparison mod_firewall/README.markdown @ 4966:4ffd6551f4bb

mod_firewall: README: Clarify when storage access can occur with roster checks
author Matthew Wild <mwild1@gmail.com>
date Tue, 28 Jun 2022 16:39:44 +0100
parents d7684aa81d8f
children 1e8381f0d0a8
comparison
equal deleted inserted replaced
4965:d7684aa81d8f 4966:4ffd6551f4bb
358 condition checks where possible (e.g. in the example above we first checked KIND, 358 condition checks where possible (e.g. in the example above we first checked KIND,
359 TYPE and PAYLOAD matched what we wanted before reaching the INSPECT rule). 359 TYPE and PAYLOAD matched what we wanted before reaching the INSPECT rule).
360 360
361 ### Roster 361 ### Roster
362 362
363 These functions access the roster of the recipient (only). Therefore they cannot (currently) 363 These conditions access the roster of the recipient (only). Therefore they cannot (currently)
364 be used in some [chains](#chains), such as for outgoing messages (the recipient may be on another server). 364 be used in some [chains](#chains), such as for outgoing messages (the recipient may be on another server).
365 365
366 Performance note: this check can potentially cause storage access (especially if the recipient 366 Performance note: these checks can potentially cause storage access (especially if the recipient
367 is currently offline), so you may want to limit its use in high-traffic situations, and place 367 is currently offline), so you may want to limit its use in high-traffic situations, and place rules
368 it below other checks (such as a rate limiter). 368 containing a roster check below other rules (such as a rate limiter). The storage access is
369 performed unconditionally before the first rule that contains a roster-based condition, even if earlier
370 conditions in that rule do not match.
369 371
370 #### IN ROSTER 372 #### IN ROSTER
371 373
372 Tests whether the sender is in the recipient's roster. 374 Tests whether the sender is in the recipient's roster.
373 375