Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Cancelled
    • Affects Version/s: ejabberd 2.0.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      Reported by JS:

      PEP seems to ignore mod_privacy completely.
      This is a problem, for example: invisible doesn't work when user tunes are activated - all your contacts still get your user tune and thus know you're there.

      http://www.xmpp.org/extensions/xep-0163.html#notify-when

      a PEP service MUST NOT send notifications to a subscriber if the user has blocked the subscriber from receiving all or any kinds of stanza (presence, message, IQ, or any combination thereof) using communications blocking as specified in XMPP IM.

        Activity

        Hide
        cromain@process-one.net Christophe Romain (Inactive) added a comment -

        ejabberd_c2s:get_subscribed result should be filtered
        may ejabberd_c2s's state privacy_list entry be usefull ?
        or maybe can pubsub use code like this

                              case ejabberd_hooks:run_fold(
                                     privacy_check_packet, StateData#state.server,
                                     allow,
                                     [User,
                                      Server,
                                      PrivacyList,
                                      {From, FJID, Packet},
                                      out]) of
                                  deny ->
                                      ok;  
                                  allow ->
                                      ejabberd_router:route(From, FJID, Packet)
                              end. 
        
        Show
        cromain@process-one.net Christophe Romain (Inactive) added a comment - ejabberd_c2s:get_subscribed result should be filtered may ejabberd_c2s's state privacy_list entry be usefull ? or maybe can pubsub use code like this case ejabberd_hooks:run_fold( privacy_check_packet, StateData#state.server, allow, [User, Server, PrivacyList, {From, FJID, Packet}, out]) of deny -> ok; allow -> ejabberd_router:route(From, FJID, Packet) end.
        Hide
        badlop Badlop added a comment -

        This patch checks privacy list of PEP publisher: if he blocked a contact in any way, the event is not sent to that contact.

        Some topics are not tested in this patch, so it may need some testing:

        • I tested the restriction is applied in PEP events sent immediately to online contacts, but I ddidn't test if the restriction is also applied to events sent when user comes online, etc.
        • Maybe it applies this restriction not only to PEP events, but also to general PubSub events. And I don't know if this is desired at all.
        Show
        badlop Badlop added a comment - This patch checks privacy list of PEP publisher: if he blocked a contact in any way, the event is not sent to that contact. Some topics are not tested in this patch, so it may need some testing: I tested the restriction is applied in PEP events sent immediately to online contacts, but I ddidn't test if the restriction is also applied to events sent when user comes online, etc. Maybe it applies this restriction not only to PEP events, but also to general PubSub events. And I don't know if this is desired at all.
        Hide
        cromain@process-one.net Christophe Romain (Inactive) added a comment -

        could this patch be injected in 2.0.4 ?

        Show
        cromain@process-one.net Christophe Romain (Inactive) added a comment - could this patch be injected in 2.0.4 ?
        Hide
        cromain@process-one.net Christophe Romain (Inactive) added a comment -

        i'll apply that patch for 2.1

        Show
        cromain@process-one.net Christophe Romain (Inactive) added a comment - i'll apply that patch for 2.1
        Hide
        cromain@process-one.net Christophe Romain (Inactive) added a comment -

        looking at the patch, this is really not a good idea to put pep specific code into ejabberd_c2s
        this would be perfect to create side effects.
        i reject that patch as it is now.
        will see if i can improve it, or delay that fix for 3.1

        Show
        cromain@process-one.net Christophe Romain (Inactive) added a comment - looking at the patch, this is really not a good idea to put pep specific code into ejabberd_c2s this would be perfect to create side effects. i reject that patch as it is now. will see if i can improve it, or delay that fix for 3.1
        Hide
        holger Holger Weiß added a comment -

        Just for the record, privacy lists are now always checked before accepting incoming PEP messages, but still not for outgoing items (see PR #354). The latter wouldn't work when ignore_pep_from_offline is set to false, as we currently rely on a running ejabberd_c2s process for these things.

        To fix for this and other issues properly, we'd have to make the PEP code independent of ejabberd_c2s, I think.

        Show
        holger Holger Weiß added a comment - Just for the record, privacy lists are now always checked before accepting incoming PEP messages, but still not for outgoing items (see PR #354 ). The latter wouldn't work when ignore_pep_from_offline is set to false , as we currently rely on a running ejabberd_c2s process for these things. To fix for this and other issues properly, we'd have to make the PEP code independent of ejabberd_c2s , I think.
        Hide
        cromain@process-one.net Christophe Romain (Inactive) added a comment -

        #354 was merged a year ago in 14.12.
        Holger Weiß do we still need something here ?

        Show
        cromain@process-one.net Christophe Romain (Inactive) added a comment - #354 was merged a year ago in 14.12. Holger Weiß do we still need something here ?
        Hide
        holger Holger Weiß added a comment - - edited

        There's still the problem I mentioned above that privacy lists aren't checked for outgoing PEP messages. With the current design, that's a bit ugly to implement for the case where ignore_pep_from_offline is set to false.

        However, for unrelated reasons I would suggest changing the current design anyway. I think mod_pubsub should take care of sending PEP notifications itself, without relying on ejabberd_c2s. This would fix the issue that remote contacts won't receive PEP notifications if the local user is offline, and it would save some memory to no longer duplicate the CAPS info of a given resource into the aux_fields of each and every ejabberd_c2s processes that communicates with that resource.

        So my suggestion would be to delay the fix for this issue until we change mod_pubsub to send PEP notifications directly. mod_pubsub would then also check privacy lists.

        Show
        holger Holger Weiß added a comment - - edited There's still the problem I mentioned above that privacy lists aren't checked for outgoing PEP messages. With the current design, that's a bit ugly to implement for the case where ignore_pep_from_offline is set to false . However, for unrelated reasons I would suggest changing the current design anyway. I think mod_pubsub should take care of sending PEP notifications itself, without relying on ejabberd_c2s. This would fix the issue that remote contacts won't receive PEP notifications if the local user is offline, and it would save some memory to no longer duplicate the CAPS info of a given resource into the aux_fields of each and every ejabberd_c2s processes that communicates with that resource. So my suggestion would be to delay the fix for this issue until we change mod_pubsub to send PEP notifications directly. mod_pubsub would then also check privacy lists.
        Show
        cromain@process-one.net Christophe Romain (Inactive) added a comment - follow up on https://github.com/processone/ejabberd/issues/1573

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development