Logged in cookies incorrectly added to cookie policy

  • Resolved Ian Pegg

    (@ianpegg)


    2 years, 2 months ago

    Hello,

    I’ve been using your plugin on many sites for a year or two now and usually recommend it to my clients so thanks for all the effort you’ve put into it!

    However, I’m having a problem with logged in cookies being displayed in the cookie policy when they shouldn’t be.

    I’ve configured the plugin like so:

    • Answered ‘no’ to “Does your site have visitors with log-in access to a restricted area of the website?”
    • Unticked “Show cookie on cookie policy” for the logged in cookies in question. In fact, all of these cookies are already showing “Logged in users only, will be ignored” next to their names.

    And yet still, all of these cookies are listed under section 6 “Placed cookies” in the cookie policy that Complianz generates. I am logged out when viewing this page and have cleared the page cache and opcode cache. I cleared all my cookies for the domain in question before running the wizard in the first place.

    One of the cookies listed is the wordpress_logged_in_ cookie (which is suffixed with a random string that uniquely identifies me as an admin on the system). Naturally I’ve logged out and destroyed that cookie to remove any potential security risk but this cookie shouldn’t be listed by name. If the site doesn’t allow visitors to log in then I believe it shouldn’t be necessary to list at all.

    Thanks for your help!

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Contributor Rogier Lankhorst

    (@rogierlankhorst)

    Hi @ianpegg,

    Glad to hear you like the plugin! Your description of what you expect is also exactly how it should work. I just checked this on our own website. As we also have logged in users, it was set to show also logged in cookies. But after changing the setting, the entire WordPress categorie was removed. So on our website it seems to work as expected. Please note that these queries are cached for about an hour, in transients.

    The wordpress_logged_in_12345 cookie should normally be “asterisked” after the sync with cookiedatabase.org. The result is then wordpress_logged_in_*. The contents of this cookie (or any cookie) is of course never stored anywhere.

    If you can’t get those cookies from the policy, there might be something in the server setup which is interfering with the filtering. This could be object caching, some sort of server side caching, that is hard to say.

    If you have this same issue over different websites, please try for example if you have the same issue on a sandboxed website on instawp.com. If so, we could use that as a starting point.

    Thread Starter Ian Pegg

    (@ianpegg)

    Thanks @rogierlankhorst. I noticed this morning that those cookies disappeared from the policy by themselves. I then ran the wizard again because I’d made some changes to the site and they reappeared. However, after clearing the transients and page cache they disappeared again so this ties in with what you’ve said.

    I notice now that the policy includes Complianz’s own cookies as I’d interacted with the consent popup before running the wizard a second time. This is the correct and complete behaviour I believe but is it intentional for these to be left out of the policy after the initial setup?

    Whether the admin has these cookies set or not when they run the scan, I believe most of these cookies will be set for every user to indicate whether or not they have consented to tracking etc.

    Plugin Contributor Rogier Lankhorst

    (@rogierlankhorst)

    @ianpegg This behaviour has two causes:

    • The order in which the wizard is completed at the moment.
    • The possibility that no cookie banner is required.

    As we don’t want to start adding a cookie banner while the user is configuring the wizard, it is only activated on the last page, after the user explicitly chooses this. But the cookie is has already run at that point.

    The cookie scan does accept the banner when running the scan, but if there is no banner, there is nothing to accept.

    After completing the wizard, on the next cookie scan, the cookies will be detected. We’ve planned a version 7.0 where most of these inconveniences will be fixed, by changing the order of questions.

    Force adding these cookies also would be an option, but as there are several combinations of cookies possible, with different prefixes, an scan of the actual cookies seems most elegant.

    A quick fix for now could be to always run the cookie scan again after completing the wizard.

    Thread Starter Ian Pegg

    (@ianpegg)

    That makes perfect sense, @rogierlankhorst, thanks for the explanation! It sounds like any assumptions the plugin makes might turn out to be unfounded until the wizard has been completed, at least up to a certain point.

    If v7 can resolve this, that would be fantastic! In the meantime, perhaps the wizard could make it clear that the scan will need to be run again after the admin interacts with the banner?

    Plugin Author Aert Hulsebos

    (@aahulsebos)

    Hi @ianpegg,

    Noted, and this will be solved in 7.0. Thanks for your feedback!

    regards Aert

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Logged in cookies incorrectly added to cookie policy’ is closed to new replies.