[#5960] Weird behavior of CB Privacy

Hello,

we have a pretty weird problem with the CB privacy plugin. It is a bit difficult to explain. We configured additional custom tabs, like “Persönliche Daten”. This tab is set to “standard CB settings” for “display”. This tab contains additional custom fields, like cb_user_birthplace. This field is configured to be customizable by the user in regards of privacy, but “private” is set as default value, meaning that only the profile owner can see it, as long as the owner does not specify another value. No other value is specified by the owner.
But if another user requests the profile, he either gets the information of the private field “Geburtsort”. Or after a refresh, the field is gone. Or after a another refresh the complete tab is gone. Or after another refresh new fields and tabs (also private) show up.

This all happens while the privacy configuration is not changed, therefore it’s a bit weird. And I don’t have any clue why this happens…

Joomla is installed on IIS 7, with php 5.6.19 and MySQLi 5.5.46. We have Joomla 3.5.1 and CB 2.0.14 with privacy 4.0.3 installed. In addition it is a multi-site page with JMS Multisite 1.3.59 with patches 1.3.54.

Your colleague, Beat, has the corresponding screenshots, which we do not want have to be publicly accessible.

Do you have an idea why the privacy plugin behaves like this?

Thanks and regards,
Sebastian

Do you have caching of any kind on your site? If the cache file is of the profile where the field is visible that cache could be served to a user where it shouldn't be visible. Disable all caching, purge caching, then see if issue persists.

Are you using CB Conditional in addition to CB Privacy? Both can control tab and field visibility.

No, we don't have Caching enabled. But even if Caching would be enabled, this would not explain why tabs show up randomly as they are configured the same for all users. It seems as if the processing of the different tabs does not return an answer or is suddenly interrupted

The tabs not showing could be jQuery failing due to a JS error. Press F12 to open your browsers developer console then click the Console tab. Next refresh the page to see any fatal JS errors present.

I don't know what to suggest as I'm unable to confirm your issue. If no JS errors are found and you can reliably reproduce the issue then please PM login credentials with instructions to reproduce and will take a look.

SOLVED

uniqid() does not always generate unique IDs. It sometimes reuses already used IDs, which caused the mess.

We solved it by changing it to uniqid() . rand(10000,99999) (see also: stackoverflow.com/questions/29974146/multiple-uniqid-calls-not-being-unique ).

WARNING: PLEASE CHANGE THE LOGIC OF CB PRIVACY SOON. Privacy should always be set to maximum by default. This is the basic idea of privacy. At the moment the default in the logic of CB Privacy is set to minimum (checkFieldDisplayAccess $return = true; at the beginning). This is a threat to your customers, as they could be taken to court if they violate privacy laws.

In addition, it would be nice, if, even for protected fields, the field titles would be shown, even if the field content is hidden, due to privacy (like empty fields).

Finally, we encountered antoher problem in a multisite environment: You use FORCE INDEX in your code (SQL). This does not work in multisite environment as they usually use views (see: www.jms2win.com/en/forum/29-help-for-configuration/11780-community-builder--shared-extension--force-index ). Are there any plans to get rid of FORCE INDEX?

Regards,
Sebastian

uniqid() does not always generate unique IDs. It sometimes reuses already used IDs, which caused the mess.

We solved it by changing it to uniqid() . rand(10000,99999) (see also: stackoverflow.com/questions/29974146/mul...lls-not-being-unique).

WARNING: PLEASE CHANGE THE LOGIC OF CB PRIVACY SOON. Privacy should always be set to maximum by default. This is the basic idea of privacy. At the moment the default in the logic of CB Privacy is set to minimum (checkFieldDisplayAccess $return = true; at the beginning). This is a threat to your customers, as they could be taken to court if they violate privacy laws.

No PHP function guarantees uniqueness. rand() isn't unique either. It's entirely possible for it to pick the same value 100 times in a row. It's insanely hard to cause uniqid to generate the same id though so I've no idea how you're managing to reliably. At any rate I will improve the caching ID generator to be more unique for next nightly.

forge.joomlapolis.com/issues/5960

Finally, we encountered antoher problem in a multisite environment: You use FORCE INDEX in your code (SQL). This does not work in multisite environment as they usually use views (see: www.jms2win.com/en/forum/29-help-for-con...tension--force-index ). Are there any plans to get rid of FORCE INDEX?

Force Index is only used in CB Connections queries. Yes, they'll be removed once the CB Connections rewrite happens, but I've no idea when that'll happen.