slidge: add required access_rule for mod_privilege in ejabberd v2 APPLIED

Jonny Rimkus: 2
 add required access_rule for mod_privilege in ejabberd
 add required access_rule for mod_privilege in ejabberd

 2 files changed, 28 insertions(+), 12 deletions(-)

[PATCH slidge v2] add required access_rule for mod_privilege in ejabberd Export this patch

add some more explanation
---
 docs/source/admin/xmpp_server.rst | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/docs/source/admin/xmpp_server.rst b/docs/source/admin/xmpp_server.rst
index ebd372f..2687c18 100644
--- a/docs/source/admin/xmpp_server.rst
+++ b/docs/source/admin/xmpp_server.rst
@@ -79,8 +79,9 @@ ejabberd
 Slidge uses different containers/processes for each gateway. Therefore administrators
 should setup these steps for each individual gateway. This is because each gateway
 makes use of an individual JID (such as telegram.example.com, whatsapp.example.com, etc).
-Only exceptions are the 'mod_http_upload', 'mod_privilege' and 'mod_roster', these modules
+Only exceptions are the 'mod_http_upload', 'mod_privilege', 'mod_roster' and 'access_rulees', these 
 stay the same for each gateway you add. So, there is no need to repeat these steps for new gateways.
+For the 'slidge_acl' add each new Gateway as a new 'server:' entry.
 
 
 Add the slidge component
@@ -124,14 +125,21 @@ These same principles also apply to ACL.
 ACL
 ***
 
-Create a policy for the component:
+Create an `acl <https://docs.ejabberd.im/admin/configuration/basic/#acl>`_ for the component:
 
 .. code-block:: yaml
 
     acl:
-      slidge:
+      slidge_acl:
         server: superduper.example.com
 
+Create an access_rule `access_rule <https://docs.ejabberd.im/admin/configuration/basic/#access-rules>` for the component:
+.. code-block:: yaml
+
+    access_rules:
+      slidge_rule:
+        - allow: slidge_acl
+
 mod_privilege
 *************
 
@@ -142,9 +150,9 @@ Make slidge a "privileged entity" and enable roster versioning.
     modules:
       mod_privilege:
         roster:
-          both: slidge
+          both: slidge_rule
         message:
-          outgoing: slidge
+          outgoing: slidge_rule          
       mod_roster:
         versioning: true
 
@@ -172,7 +180,7 @@ so you need to use a pseudo user on the component domain, eg,
         put_url: "https://@HOST@:5443/upload"
         access:
           - allow: local
-          - allow: slidge
+          - allow: slidge_acl
 
 
 To get more information about component configuration, see `ejabberd's docs
-- 
2.34.1

builds.sr.ht <builds@sr.ht>

1 year, 7 months ago

slidge/patches: SUCCESS in 1h11m21s

[add required access_rule for mod_privilege in ejabberd][0] v2 from [Jonny Rimkus][1]

[0]: https://lists.sr.ht/~nicoco/public-inbox/patches/38897
[1]: mailto:jonny@rimkus.it

✓ #938371 SUCCESS slidge/patches/container.yml https://builds.sr.ht/~nicoco/job/938371
✓ #938370 SUCCESS slidge/patches/ci.yml        https://builds.sr.ht/~nicoco/job/938370
✓ #938372 SUCCESS slidge/patches/debian.yml    https://builds.sr.ht/~nicoco/job/938372

[PATCH slidge v3] add required access_rule for mod_privilege in ejabberd Export this patch

add some more explanation


fix typo
---
 docs/source/admin/xmpp_server.rst | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/docs/source/admin/xmpp_server.rst b/docs/source/admin/xmpp_server.rst
index ebd372f..4253c08 100644
--- a/docs/source/admin/xmpp_server.rst
+++ b/docs/source/admin/xmpp_server.rst
@@ -79,8 +79,9 @@ ejabberd
 Slidge uses different containers/processes for each gateway. Therefore administrators
 should setup these steps for each individual gateway. This is because each gateway
 makes use of an individual JID (such as telegram.example.com, whatsapp.example.com, etc).
-Only exceptions are the 'mod_http_upload', 'mod_privilege' and 'mod_roster', these modules
+Only exceptions are the 'mod_http_upload', 'mod_privilege', 'mod_roster' and 'access_rules', these 
 stay the same for each gateway you add. So, there is no need to repeat these steps for new gateways.
+For the 'slidge_acl' add each new Gateway as a new 'server:' entry.
 
 
 Add the slidge component
@@ -124,14 +125,21 @@ These same principles also apply to ACL.
 ACL
 ***
 
-Create a policy for the component:
+Create an `acl <https://docs.ejabberd.im/admin/configuration/basic/#acl>`_ for the component:
 
 .. code-block:: yaml
 
     acl:
-      slidge:
+      slidge_acl:
         server: superduper.example.com
 
+Create an access_rule `access_rule <https://docs.ejabberd.im/admin/configuration/basic/#access-rules>` for the component:
+.. code-block:: yaml
+
+    access_rules:
+      slidge_rule:
+        - allow: slidge_acl
+
 mod_privilege
 *************
 
@@ -142,9 +150,9 @@ Make slidge a "privileged entity" and enable roster versioning.
     modules:
       mod_privilege:
         roster:
-          both: slidge
+          both: slidge_rule
         message:
-          outgoing: slidge
+          outgoing: slidge_rule          
       mod_roster:
         versioning: true
 
@@ -172,7 +180,7 @@ so you need to use a pseudo user on the component domain, eg,
         put_url: "https://@HOST@:5443/upload"
         access:
           - allow: local
-          - allow: slidge
+          - allow: slidge_acl
 
 
 To get more information about component configuration, see `ejabberd's docs
-- 
2.34.1