Cookie Law Support in Kentico CMS 6

Hi there,

I won't be explaining what "Cookie law" is or my opinion on it. That would be completely different discussion and has also been covered online quite enough. Anyway, as you know, the grace period for compliance is coming to an end on May 26^th, 2012, so whether we like it or not, something must be done about it.

I requested some feedback about it quite some time ago, but since the feedback was quite fuzzy, and there are lots of opinions about how to properly comply, we have created something that we think should give you enough flexibility to cover your needs.

If you are interested, apply hotfix 6.0.32 to your web site. The hotfix contains two important items:

• Kentico CMS v7 Cookie helper - We have been able to extract this from v7 and inject into v6, so it pretty much supports what will be available in v7
• A set of two web parts that you can use to provide your site visitors with a nice way of allowing cookies on your web site

Let's see that in more details now...

What's New in Cookie Helper v7 (and 6.0.32)?

As we continue to provide more and more flexibility for our internal classes, the CookieHelper class has been rewritten to support customization. Similar to other helper classes, you may now override the default helper object with your custom inherited one. You can also change its default behavior, if needed, as for other providers and helpers as described here:

http://devnet.kentico.com/docs/devguide/index.html?custom_providers_overview.htm

However, this is not really necessary. It would  only apply if you needed deep customization. Consider it a bonus that comes with this update. It's the cookie levels what are most important.

Cookie Levels

We now split cookies into several levels to differentiate their purpose and allow the settings of a border line to which the user allows cookies. We provide more levels than you actually need, in order to offer more options for configuration and future updates. Default levels available in Cookie helper API (CookieLevel class) are as follow:

• None (-1000) - Absolutely no cookies are allowed, including the state which cookie level user allows. This makes sense only in the case that you want to disable absolutely every cookie by default, but I don't recommend using it for now.
• System (-100) - This level allows the session cookie (due to security on postback), and CookieLevel cookie which remembers the level of cookies that the user allowed. In terms of the end user and Cookie law, this means "Cookies are not allowed"
• Essential (0) - Cookies which are required for all web-site functionality needed by site visitors. This includes authentication, shopping cart, etc. From the visitor perspective, this means "Allow only cookies that I may need, but do not track me". Based on the particular cookie legislation in your country you may or may not be required to allow this option.
• Editor (100) - Cookies which are needed for the admin UI to work properly. This mainly includes the view mode, remembering tabs and sliders and a few others.
• Visitor (200) - All cookies which aren't assigned with any explicit level (which includes your custom cookies if you use any) are considered to be cookies to identify the visitor, i.e. the user tracking cookies not really needed, but useful for the site owner if using EMS.
• All (1000) - This is a system level, not a particular cookie level. This level allows all cookies not matter what their level is. From the site visitor perspective this means simply "Allow all cookies now and in future".

You may notice that there are numbers associated with each cookie levels. Levels are not enumeration, but rather integer constants, to allow you to further customize or make custom levels should you need it. Also, for that reason the levels "None" and "All" have absolute value of 1000, to provide enough space for potential future updates.

We suspect that you may be only interested in 3 main levels, which are:

• Do not allow any cookies (level System) - Which means the minimum cookies required for the web site to work, and which remember whether the user allows cookies or not.
• Allow only essential cookies (level Essential) - Which means all cookies required for web-site functionality, but no "evil" tracking cookies.
• Allow all cookies (level All) - Which means all cookies will be allowed as if no Cookie law existed.

These levels are also implemented in our new web parts. If you need more, you may use our API to extend the user options. Items that may be of interest in the API are:

• CookieHelper.CurrentCookieLevel - Provides cookie level settings of the current user. If no level is set, the default system level (All) is used.
• CookieHelper.GetCurrentCookieLevel(...) - Similar to previous, but in this case you may initialize the default level if not set.
• CookieHelper.ChangeCookieLevel(...) - This will change the cookie level and remove all user cookies above the newly-set level.

In case you would be using your own cookies (which must be read and written by CookieHelper), you may want to change their level from default Visitor to another, for that you may use method:

• CookieHelper.RegisterCookie(name, level, defaultValue) - Which changes the cookie level for a particular cookie. Note that the defaultValue parameter is now not implemented and serves for future purposes.

If you want to do this, do it in the Init method of your custom module file which is called upon application start. You may use the code piece from this documentation, remove the contents of the methods, and add calls to RegisterCookie to the Init method: http://devnet.kentico.com/docs/devguide/index.html?event_handlers_overview.htm

In typical situations, you probably won't need any of this, but I wanted to give you a bit of system background in case our assumption of your requirements is wrong. But in any case, most important are the new web parts which are leveraging all of this.

Cookie consent web parts

We provide two new web parts within the hotfix package. If you apply hotfix 6.0.32, you should have file ~/CMSSiteUtils/Import/CookieLawWebParts.zip in your project. Then you need to import the web parts' definitions. To do this, simply go to the Site manager -> Sites -> Import web site or objects, and import the package with the default settings (just click Next, Next ... until the package is imported).

Now you can find the following web parts if you click Add web part in design mode:



Technically, it is a single web part implemented in ~/CMSWebParts/General/CookieLaw.ascx and the "simple" one is just a preconfigured version of the same web part. Here is what the web parts offer by default:

Cookie law consent

Offers the visitor the option of switching between three states - Cookies not allowed, Only essential and All cookies. In each state, actions to switch to the remaining states are offered. You may customize the text message, available actions and the texts for each of these states individually. As a base, there is a cookie level setting to which the current level compares. One state is when the current level is below the selected level, the second is when the level exactly matches it, and the last is when the level is above it. We believe that this should give you enough options to configure it to your needs.

Note that changing the cookie level works only in live site mode, as you obviously don't want to clear your cookies in design mode. For designing purposes, there is another property which simulates the user level in design mode.

The default cookie level is currently not set in this web part so it keeps the level "All" as the starting level, but you may also change this setting.

Here is how the web part content looks by default if you add the web part:



Simple cookie law consent

This is a preconfigured version of the previous web part so you can see how flexible it is. It also allows you to implement the simplest way of the cookie law consent very easily. The behavior is: Disable cookies by default, request allowing, and once allowed, hide the web part.

Here is how the web part looks in its default configuration:



As it doesn't make sense to offer you default styles, because you have your own web-site design, web parts are not visually designed, and you need to update your CSS to get the desired look and feel.

What else?

Now the best thing to do, should your web-site need to be compliant with cookie legislation, is to take this, implement it as you need, and if you run into any trouble in becoming compliant, let us know ASAP. We are able to provide you with an update in hotfix 6.0.33 this Friday (May, 26) prior to the deadline, with final changes. So if you ca get enough details to us by Wednesday May 23, midday, we can put your changes into the hotfix. Any further feedback based on its importance can be implemented in later hotfixes or in Kentico CMS version 7.


There is just one remaining question that I can think of, which is "Can I disable all cookies by default, including the session cookie, but remember the cookie level?". There has not been enough time for us to run proper simulations, so technically it could be possible, and I will tell you how. I just cannot, however, promise it will work with the current hotfix. Let me know how important this would be for you.

What you can do is to set the default cookie level system-wide by using the web.config app settings key so that CookieLevel cookie is not needed until someone enables the cookies:

<add key="CMSDefaultCookieLevel" value="None" />

You may use either integer value,however, if you do this, request validation may be causing problems on postbacks, so you may also need to disable ViewStateUserKey:

<add key="CMSUseViewStateUserKey" value="false" />

However if not absolutely necessary, I don't recommend this, because then you may compromise web-site security. Proper security requires at least the session cookie to handle all cases; therefore if you need a system-wide default value for disabling cookies by default, I recommend setting this:

<add name="CMSDefaultCookieLevel" value="System" />

 
Actually, there is one more thing you should know: If a user logs in to admin UI, all cookies are automatically enabled for the user to provide full editing functionality. We expect that that login to admin UI identifies the user as staff; therefore there is no need for cookie consent in this case.


I will follow up with an updated list of all cookies that Kentico CMS v6 uses, including their levels, so you can provide users with the complete information about cookie consent.

That is all from me now. Go ahead, hit me with questions or feedback if any, and test whether you are good to go with this from May 26th.