Bug or not supported? (privacy lists)

Openfire Openfire Support
1

I’m developing a client, based on JSJaC 1.3, and have run into a problem regarding Privacy Lists.

XEP-0016 (link) specifies that if you want to get a list of Privacy Lists from the Jabber server you have to send this to the server:

    <iq from='romeo@example.net/orchard' type='get' id='getlist1'>

<query xmlns=‘jabber:iq:privacy’/>

</iq>

But if you send this iq to Openfire you always recive this response:      &lt;iq type="result" to="brick@192.168.0.111/ourClient"&gt;
          &lt;query xmlns="jabber:iq:privacy"/&gt;
     &lt;/iq&gt; If I do the same with Ejabberd I get a response with the Privacy Lists. Is this a bug is this just something that ain't supported in Openfire?
2

Hey noise,

Privacy lists are supported by Openfire. The IQ packet that you pasted looks fine to me. Could you verify that rome has a list of privacy lists stored in the database?

Execute the following SQL statement on your database:

SELECT name, isDefault FROM ofPrivacyList WHERE username='romeo'

The server is returning whatever is returned from that DB query as the answer to your IQ packet.

Regards,

– Gato

3

Hey noise,

I said romeo in my previous post since that is what you are sending in the IQ packet. But you later say that the IQ reply says brick. In the above SQL statement replace romeo with the username of the sender of the IQ packet.

– Gato

4

That’s odd… I don’t even have the ofPrivacyList table in my database. I’m running Openfire against an external MSSQL database. What other tables am I missing?

These are the table that I have

jiveExtComponentConf

jiveGroup

jiveGroupProp

jiveGroupUser

jiveID

jiveOffline

jivePresence

jivePrivacyList

jivePrivate

jiveProperty

jiveRemoteServerConf

jiveRoster

jiveRosterGroups

jiveSASLAuthorized

jiveSecurityAuditLog

jiveUser

jiveUserFlag

jiveUserProp

jiveVCard

jiveVersion

mucAffiliation

mucConversationLog

mucMember

mucRoom

mucRoomProp

ofConParticipant

ofConversation

ofMessageArchive

ofRRDs

pubsubAffiliation

pubsubDefaultConf

pubsubItem

pubsubNode

pubsubNodeGroups

pubsubNodeJIDs

pubsubSubscription

5

Hmm… I must have done something wrong because now it is working. But I still would like to know if I’m missing a table.

6

Whoops! The correct table name is jivePrivacyList. The of prefix is part of Openfire 3.6.0 that has not been released yet.

Thanks,

– Gato

7

Haha!

Just one more question, does XMPP support multiple active list?

I’ve got these four cases

  1. Block all

  2. Block all minus buddies

  3. Block no one

  4. Block specific users

The block specific users list should always be active. But I would like to switch between the other rules. Is this possible?

8

Hey Noise,

Just one more question, does XMPP support multiple active list?

I’ve got these four cases

  1. Block all
  1. Block all minus buddies
  1. Block no one
  1. Block specific users

The block specific users list should always be active. But I would like to switch between the other rules. Is this possible?

In XMPP a user may be connected from many places at the same time. Lets say that we have a user (bare JID = john@server.com) connected from home (full JID= john@server.com/Home) and from work (full JID= john@server.com/Work). The user can define the default list to use for his sessions. That means that unless a session specifies something else its default privacy list will be used. Moreover, each session/connection can only have one privacy list active at a time (aka active list). Each session may have a different active list. The user can keep changing the list to have active for a given session all the times that he wants.

A privacy list is composed of a set of rules. The rules have a certain order. So rule 1 is applied first and then rule 2 and so on. You can define in that way how you want to block/allow traffic.

Regards,

– Gato

9

Hi,

you must include rule 4 in all other rules, this is something the client must support as the server does not. You may also want to take a look at Privacy Lists.

LG

10

Thanks. This was what I suspected.