Possible problem with privacy lists

Dear sirs,

i am working with Wildfire 3.1.0 beta and currently i am implementing privacy list on a xmpp client.

It seems that wildfire won’'t store privacy lists items.

The lists and their names seems to be stored ok but the items in them won’'t be stored.

I tryied to work with other clients that support privacy lists (Miranda) and it won’'t work either with wildfire.

Can you give me some help?

Thanks in advance!

Hi

Have you checked that the server is configured to store them ?

Under Admin Console > Server > Private Data Storage and set it to enabled.

Martyn

Thanks for the help Martyn,

Are you sure that privacy lists are stored in the private data storage location of each user?

Hi MG,

All users’’ jabber:iq:private data is stored in jivePrivate table of Wildfire database.

ok Martyn, i checked the property you said and it is enabled normally.

Is there something else i should check?

Hi

Server should be OK - what client are you using ? I use Exodus 0.9.1.0 and it works OK.

Can you enable debug and examine the stanza’‘s to see if you’'re getting any erros back when to attempt to set a bookmark or something ?

Martyn

I use exodus 9.1.0 too, but it does not support invisibility…

It has only the “send invisible” command which won’'t work because it sends custom “invisible” presence not by using the privacy and invisibility lists…

The only client i have found working with invisibility is miranda …

I found out that exodus does blocking on the client side which is totally wrong.

Isn’'t that right?

Message was edited by: mayprog

Hi,

could you please try to use Ad-hoc commands (Spark: F12) and send this to your server:

<iq from=''admin@example.com/spark'' type=''set'' id=''edit1''>
  <query xmlns=''jabber:iq:privacy''>
    <list name=''public''>
      <item type=''jid''
            value=''spam@example.com''
            action=''deny''
            order=''3''></item> <item action=''allow'' order=''68''></item>
    </list>
  </query>
</iq> <iq from=''admin@example.com/spark'' type=''set'' id=''active1''>
  <query xmlns=''jabber:iq:privacy''>
    <active name=''public''></active>
  </query>
</iq>

The content of the first packet should be stored in the database in table JIVEPRIVACYLIST.

The 2nd packet activates the list, and Wildfire does not store this as a list must be activated for each session to become active. “spamexample.com” is no longer be able to send messages to "admin@example.com/spark". But is still can send messages to admin@example.com/home.

So if you re-login or if you login with another resource you need to activate it again.

LG

Hi LG,

well finally i figured out that i was wrong.

Wildifre does store the lists and there was a problem with my xmpp packets.

I would like to ask you a question about the jep that i havent understand,

if a jave activayed a list which i change later do i gave to reactivate it, or wildfire is ‘‘clever’’ to aply the changes as this list is already the active one?

Thank yoy very much again LG.

Hi May,

which JEP are you refering to if I may ask? It’‘s within http://www.xmpp.org/specs/rfc3921.html#privacy and reading through it I’'m pretty sure that one can change (but not delete) the active list without problems.

LG

I used JEP-0016: Server-Based Privacy Rules and JEP-0126: Invisibility.

I haven’'t looked at you reference but i will.

Thank you very much.

Hi,

JEP-0016 has been retracted so we’'ll hopefully not see it in Wildfire.

I’'m not sure if one will implement support for JEP-0126 as JM-747 exists for experimental “[JEP-0186|http://www.jabber.org/jeps/jep-0186.html]: Invisible Command” support.

As RFC3921 also allows to block outgoing presence notifications - which is very similar to invisibility - I really wonder why JEPs 0016, 0126 and 0186 were created.

edited: JEP-0126: “However, RFC 3921 also defines a privacy lists protocol (i.e., the ‘‘jabber:iq:privacy’’ namespace) that can be used to implement invisibility in an XMPP-compliant manner. This JEP documents how to do just that.” - so Wildfire supports JEP-0126.

LG

it2000 wrote:

I’'m not sure if one will implement support for JEP-0126 as JM-747 exists for experimental “[JEP-0186|http://www.jabber.org/jeps/jep-0186.html]: Invisible Command” support.

I’'ve implemented JEP-0186 in my client (a new Smack-based plugin for Adium).

As RFC3921 also allows to block outgoing presence notifications - which is very similar to invisibility - I really wonder why JEPs 0016, 0126 and 0186 were created.

edited: JEP-0126: “However, RFC 3921 also defines a privacy lists protocol (i.e., the ‘‘jabber:iq:privacy’’ namespace) that can be used to implement invisibility in an XMPP-compliant manner. This JEP documents how to do just that.” - so Wildfire supports JEP-0126.

Well, I chose not to implement JEP-0126, since Adium also supports block lists. When someone goes invisible, I would have to modify the active block list on the server to match both the requirements for invisibility and that original block list itself (which is kinda ambiguous by itself). If my client crashes, it would have to clean that mess up after logging in again. I decided that this is way too messy for me, and simply implemented JEP-0186, even though I don’'t know of any implementation for it.

Well you opened a new world to me!

I didn’'t knew the existanse of JEP-0186 and it is really interesting.

I have tried to implement jep126 and it is just too much!

My problem is that my client should go out on the market soon, so i really need a way to support invisibility asap.

I can see that no server haven’'t yet support for jep126 and this could be a problem.

Do you think i should go on with jep126 in order for my app to have that invisibility support or to implement jep186 and wait for the servers to support it too?

Thank you LG very much.

Hi May,

every server which fully supports RFC 3921 does also support JEP-0126. Wildfire does not yet support JEP-0186 so I’'d implement RFC 3921/JEP-0126. Looking at the JEPs one will see that “Invisibility” is for the server a little more complex than just blocking IQ and Presence packets so I wonder if one will really implement it as tracking single sessions is not really kind. Doing the work (creating the proper list) on the client saves a lot of resources on server side.

LG

it2000 wrote:

Doing the work (creating the proper list) on the client saves a lot of resources on server side.

Yes, but it requires some crazy AI on the client side to be implemented properly (taking into account the existing block list, which can be very complex).

Hi Andreas,

I thought of something like

<iq from=''inv@example.com/spark'' type=''set'' id=''v1''>
   <query xmlns=''jabber:iq:privacy''>
      <list name=''inv''>
         <!-- block outgoing presence notifications,
               type="subscribe" does pass this filter -->
         <item action=''deny'' order=''1''>
            <presence-out></presence-out>
         </item>
         <!-- one can not block _outgoing_ IQ -->
         <!-- make search, conference, ... available (allow _incoming_ IQ) -->
         <item action=''allow'' order=''2'' type=''jid'' value=''search.example.com''>
            <iq></iq>
         </item>
         <item action=''allow'' order=''3'' type=''jid'' value=''conference.example.com''>
            <iq></iq>
         </item>
         <!-- TODO: 4..99 insert pubsub, ... here -->
         <!-- TODO: 100..998 allow IQ for special JID''s here -->
         <!-- block all other _incoming_ IQ -->
         <item action=''deny'' order=''999''>
            <iq></iq>
         </item>
         <!-- TODO: the customized privacy list, for me just ''allow'' -->
         <item action=''allow'' order=''1000''></item>
    </list>
  </query>
</iq>

. It doesn’'t seem to be too complex.

LG

it2000 wrote:

I thought of something like

It doesn’'t seem to be too complex.

Should people on your whitelist see you when you’'re invisible? You also have to re-arrange the order number of the existing list.

Plus, what happens when you go offline while being invisible? You will leak that list.

My basic gripe with it is, that you mess with the user’‘s data there, the block lists should be fully configurable by the user, and the application shouldn’'t be messing around with it automatically.