Category: Cookie

According to http://phplens.com/lens/adodb/docs-session.htm, garbage collection is supposed to be automatic for adodb sessions, which are used in tiki when "store sessions in db" is turned on. But it does not seem to be working. Have to figure out why first, before I can fix.

{syntax type="tiki" editor="plain"}
On many machines, and with both Firefox and IE, attempting to login as a user or admin results in an error message "You have to enable cookies to login to this site". Both in IE and Firefox cookies are enabled.

This problem has shown up recently on Tiki.org forums

"Forums » Architecture/Installation » You have to enable cookies to be able to login to this site"

It has also been reported as a bug "Cookies with Tiki 6.1"

__Off/on__

Seems to disappear when I use a different theme, "darkroom" instead of "jqui"

{syntax type="tiki" editor="plain"}
Since Tiki29 we have 4 switches on the cookies consent dialog:
* essential
* analytics
* marketing
* functional

If the usage for the "essential" cookies is clear and leave no choice, the other switches usages, except for their name, are very unclear to me. The tooltip doesn't add any useful information to help to understand more than the name of the switch. If this switches exist and are displayed, the admin should be able to find in the control panels what allow or enable them to be displayed.

Also, it seems they are displayed by default, no matter what has set the admin in his Tiki site.
In my use case I didn't set anything brand new Tiki. No analytics or marketing and the cookies consent for this Tiki shouldn't display anything about analytics and marketing. Not only it is not necessary but it can harm the image of a website where this tools are excluded.

Nothing also in the doc: https://doc.tiki.org/Tiki29

---

Additionally, the reliability of Analytics and Marketing seems to be = 0
I have Matomo tracking code in my Look&Feel -> Customization fields and they work even if the cookie Analytic switch is kept OFF.

comzone, the cookie that save the show/hide of comments on tikiWiki pages, isn't being updated properly. Once comments are shown they remain shown.

To reproduce the issue, follow the following instructions:
- activate comments for you TikiWiki page, through your admin controls
- Open a new session of your web browser. I'll assume you're using Firefox from now on
- Navigate to one of you wiki pages
- Scroll down to the bottom of your wiki page
~ Notice how the 'Post New Comments' comments section is hidden
- Click the link to add comments and make the 'Post New Comments' visible
- In Firefox, select Tools-> Options. Go to the privacy section and click on Show Cookies. Search for your site or site subdomain (type the first letter of the domain or subdomain to jump to that letter) where your tikiWiki is. Expand the folder and search for comzone. Notice that comzone is set to 'o'. Close out the cookies and option window.
- Browse to another page on your tikiWiki site and scroll down to the bottom of the page
- Notice that the 'Post New Comments' section is still visible
- Click on the add comment link to collapse the comments section.
~ At this point the comzone cookie should have changed.
- Check on the content of comzone and see if it is something other than 'o'. You will find that it doesn't change.
- Delete the comzone cookie and refresh the wikipage and you'll see that comments get hidden.

The cookie consent form doesn't work properly in MS Edge - a modal saying "Sorry, cookie consent required" appears when you click "Continue" and reappears immediately after clicking "OK", so it's impossible to proceed at the site (dev.tiki.org for example). Edge uses chromium - I didn't check other chromium-based browsers.

The cookie consent mechanism has this bold claim:

__"Complies with EU Privacy and Electronic Communications Regulations."__

First of all, let me express my thanks that someone has undertaken the task of creating a feature that at least tries to adhere to laws and regulations. Many IT systems do not even have that.

But the bold claim is only partially fulfilled. You ''can'' make cookie consent compliant with regulations, but it does not tell you how. And some defaults are ''not'' compliant.

To elaborate:
There is an option "Cookie consent disabled" with description
"Do not give the option to refuse cookies but still inform the user about cookie usage.". Enabling this would be a clear breach of regulations. In the European Union every user must be given the right to deny setting cookies. Luckily this one is default off.

This also implies that the setting "Cookie consent alert" with description "Sorry, cookie consent required" and hint "Alert displayed when user tries to access or use a feature requiring cookies." is non-compliant. The user has a right to refuse, and you cannot block his/her access upon that. It is okay if functionality is reduced (like remembering sessions), but you cannot block access.

There is a "Cookie consent question", "Specific question next to the checkbox for agreement. Leave empty to not display a checkbox." with this default text: "I accept cookies from this site.". That's not a question, that's an answer :-)

"Specific question next to the checkbox for agreement. Leave empty to not display a checkbox." Hm, no checkbox? Ask a clear question, one that users can answer binary "Yes" or "No".

The default label for consent is "Continue", which is not compliant. The label must clearly tell an medium level informed user what it does. Therefore it cannot be labelled "Continue". It can be changed, but this is the default.

Also, any kind of consent checkbox must not be preset!

So, I see the spirit of the devs to help admins be compliant, but this needs some brushing up to really enable admins to be on the right side of the law :-)

I see that for some areas outside the EU one might want to be less adherent to EU laws and therefore might want to force users to accept cookies. But a GUI of a function that claims compliance should not encourage that. So either claim this and offer only compliant options or display advice or even alerts when admins click on settings that would make them breach compliance... Or have one checkbox "compliant settings only" or something like that.

Also, inform admins that by law, site admins must inform their users about what kind of personal data is stored, where it is stored, and for how long. Commercial sites must also tell which persons are to be contacted if users want to get a copy of all that data, or who is to be contacted is someone wants that deleted.

{syntax type="tiki" editor="plain"}
1) Column colapsing is not remerbered whenever I change from one page to another.

2) And also have had some problems with their navigators saying "cookies must be on" when they are on, no matter wich browser is being used. This happends as they attemp to login. After many tries the user can login.


Using:
Tiki 6.1 fresh code install, on past 6.0 db updated to 6.1.

{syntax type="tiki" editor="plain"}
__Background:__ I'm in the process of an overdue upgrade of two Tikis from version 2.2 to the new LTS version 6.x. Testing and adaptation of styles was done on XAMPP localhost under Windows and all worked fine. Problems began with installing on public server (Debian). Installation is done from shell (tar.gz and running setup.sh) and a fresh install works fine.

__Problem:__ When I use the existing database (no problems at database upgrading to 6.2 reported) then it also works fine for anonymous user. But as soon as I try to login as admin user, I get a long wait and then:

__Fatal error:__ Out of memory (allocated 110100480) (tried to allocate 157 bytes) in /home/hrusccbo/tikitest.hruschka.com/tiki-6.2/lib/init/initlib.php on line 185
''(Note: the line number 185 varies)''

In order to locate the error, I entered the following line in initlib:

171: print ("a:$errno, b:$errstr, c:$errfile, d:$errline");

The result is that Tiki starts displaying thousands of times, in an endless loop, until memory exhaustion:
a:2, b:DateTimeZone::__construct() [datetimezone.--construct]: Unknown or bad timezone (M), c:lib/tikidate-php5.php, d:182

From that I deduct that the error originates from line 182 of tikidate-php5.php


===Some other findings which might be useful:===

The last days I tried to enter dev.tiki.org and themes.tiki.org, but could not because the sites displayed exactly the same error. Yesterday I went to IRC chat and was advised to clear the cookies of my browser. After that it worked.

Looking at the cookies now, I found that "local_tz" (I assume that has to do with timezone) of my working tw_2.2 had the content "22%3A37%3A23", the cookie from tiki.org has now the content "UTC", but the cookies from working XAMPP/localhost and from the not working Debian 6.2 installation have both the content "M".

This fits to the origin of the error, as line 182 is "function setTZbyID" which calls "function convertMissingTimezone", where "M" is used in a switch/case statement.

But probably the bug is not really in the tikidate script, but where the cookies are set !!! (see below under "workaround")

Hope that helps to locate the bug and that it can be solved in 6.3. In the meantime I'll wait with migrating.

Thanks to all of you for your great work.
Felix
(running 3 tiki sites since 2005)

The "Remember me" feature of login on tw.o sites doesn't really work as it should. On tw.o, dev.tw.o and themes.tw.o it's set via Admin > Login to values "tikiwiki, .tikiwiki.org, /, 1 week" and it lasts only some hour or so and expires then. It's annoying to relogin many times a day.

I noticed an embarrassing problem with the tiki version running on tiki.org
the problem is side of the javascript alert box that requires confirmation of the use of cookies...
normally when we click Ok, the prompt should disappear but I noticed it appears more than 6 times before leaving you alone which is a bit embarrassing.