--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/Vv7Zw1oakSIJ.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/VkAeK3oTaBoJ.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.
@Sam, Can that patch be added to the core so you can easily turn it on/off from mysite/_config.php?
Also, If someone from the community would like to write about how cookies are used in an average Silverstripe session please contact me to help setup; http://silverstripe.cookiestatement.eu/ or if another SS community developer could provide another loophole to get round this stupid law?
As you say Michael, the key thing is that technically required cookies can be placed without permission (http://www.opta.nl/nl/actueel/alle-publicaties/publicatie/?id=3647). Are there any instances within the SS core where it places a technically not-required cookie (be it in 2.4 or 3.0?)."5 Juni 2012 is de nieuwe cookiebepaling van kracht geworden. Kort gezegd moeten websites bezoekers informeren en toestemming vragen voordat zij een cookie of andere gegevens op bijvoorbeeld een computer, laptop of mobiele telefoon plaatsen of lezen. Dit hoeft niet voor cookies die strikt noodzakelijk zijn voor de werking van de website, aldus de wet. OPTA handhaaft deze bepaling en kan zo nodig boetes opleggen van maximaal 450.000 euro"
Here is the wording we settled on regarding SS:
== Content Management System ==
The content management system we use to publish our website uses cookies to store some basic, essential data on your interactions with it, such as whether you have logged in. Other cookies tell us if you have previously logged into the website, and are optionally used to remember your login details for future visits if you ask us to.
* PHPSESSID: this is used during your visit to remember any preferences and settings you might ask us to set, such as whether or not you are logged in. If you block this cookie parts of the site will not work properly or will be inaccessible to you. Deleted when you leave the site.
* PastMember: used to remember if and when you have previously logged in. This cookie does not store personal information about you, but if you are a registered user it is used to update your personal record in our database. Stored for 90 days.
* alc_enc: only set if you tick the "Remember email and password for next time" box when you login. Stored for 90 days.
- ends -
Assuming the above is accurate I'm happy for this to form the basis for some standard wording in docs.
See http://www.ouem.co.uk/cookies/ for the full thing which also covers the site's use of GA.
OTHER SOURCES
In preparing the above I found these to be very useful:
Action for Blind People cookie policy (their site uses SS)
http://www.actionforblindpeople.org.uk/member-pages/register/terms-and-conditions/privacy-and-cookies/
Cookie Policy Template
http://www.keymultimedia.co.uk/2012/05/22/eu-cookie-law-template-privacy-wording/
Sophie
---------------
Sophie Dennis, Cayenne
Content Strategy & UX Design | DEVON & OXFORD www.cayenne.co.uk
t: 0845 486 0108
tw: @sophiedennis
skype: cayenneweb
blog: www.sophiedennis.co.uk
Legal bits: Cayenne Web Development Limited is registered in England & Wales no 4502369, at Bloxham Mill, Barford Road, Bloxham, Oxfordshire OX15 4FF.
--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/Z-f5hu4uPM0J.
The approach would need to be different in the session because the session are currently bound to the controller, and constructed in Director::direct(). Dependency injection is probably your best bet here, so that the Injector is used to construct the session object in both Director::direct() and Session::current_session().
You will also need to refactor Session::start() so that Director::direct() calls a new method, inst_start() on the instance it creates, and that Session::start() calls inst_start(). In fact, the code that checks the $_COOKIE and $_REQUEST in Director can be moved to be within the default Session implementation.
I can't comment on the code as it's beyond my expertise, but if this is *just* for the php session, then I think the consensus was that this can be classed as "strictly necessary" for the site to function. So you do not need consent to set it. So there is no need to refactor the session-related code.
All you need to do is explain its use in a cookie/privacy policy or similar.
Have I got that right?
Sophie