[Pro] Cookies notification pop-up - EU Law

ian4 · December 8, 2013, 11:34pm

Does anyone know how to add a cookie warning notifying users that “This website uses cookies. By continuing to browse the site you are agreeing to our use of cookies”. After the ‘X’ is clicked the notification will not show again unless cookies are removed from the machine.

Is there an action or tutorial on how to do this?

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

waltd · December 9, 2013, 12:57am

There isn’t an Action. I toyed with making one a while ago, when the EU cookie law came into effect, and everyone was scrambling to fix this. The law was watered down in the end, so I never built one. You could do this quite easily with Protaculous 2 and CookieJar if you like. It’s one blob of code and one Action.

Draw an HTML box on your page somewhere, and position it where you want it to appear. Make a note of the content of the Inspector’s Name/ID field – especially note the case of the letters, as this is case-sensitive. Double-click into the box, add your text, any graphics you like (inline, please) and set the styling how you like. (Use padding to bring the text in from the edges of the box, use background color or image to make it pleasant to look at. Borders, shadows, anything you feel it needs.) Add a bit of text or a button of some sort saying “I agree” or whatever you like. They don’t have to click directly on it – any click anywhere inside the panel will do.
Click elsewhere on your page, then click once on your warning box so its corner handles are showing. From the main menu, choose Item / Extended, and click on the
segment of the dialog. Click New, and add the following name/value pair. display: none (Don’t include the colon, it’s there to show you the name and the value.)
Now apply Protaculous 2 to your page, and click the Additional JavaScript libraries disclosure triangle. In the Name field, enter cookiejar, and in the CDN URI field enter http://cdn.freewaypro.com/cookiejar/1.5.1/cookiejar.js.
Click the DOM Loaded Observer button. Paste in the following code, taking care to change the word example to match the name of the box from step 1.

var jar = new CookieJar({
expires: (525600 * 60),
path: ‘/’
});
if( ! jar.get(‘agreed’) ){
$(‘example’).show().observe(‘click’,
function(evt){
evt.stop();
jar.put(‘agreed’, true);
this.hide();
}
);
};

Now the panel will appear if the user hasn’t clicked on it in the past year, and the moment they click on it, it will not show again for a year.

Walter

On Dec 8, 2013, at 6:34 PM, ian wrote:

Does anyone know how to add a cookie warning notifying users that “This website uses cookies. By continuing to browse the site you are agreeing to our use of cookies”. After the ‘X’ is clicked the notification will not show again unless cookies are removed from the machine.

Is there an action or tutorial on how to do this?

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

David_McCallum · December 9, 2013, 2:00am

var jar = new CookieJar({ expires: (525600 * 60), path: ‘/’ });

Does this apply (will not show again for a year) even through browser sessions.

David

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

waltd · December 9, 2013, 2:13am

Yup. This is a long-lived cookie, as opposed to a session cookie, which is what you get when you set the expires to nil or an empty string. Those expire the moment the browser turns its back on the session (usually when the window closes or the browser quits).

Thanks to the cast of Rent for telling me how many minutes are in a year, so I don’t have to write this out the usual way:

(60 * 60 * 24 * 365)

Yup, now that song is stuck in YOUR head, too!

Walter

On Dec 8, 2013, at 9:00 PM, DeltaDave wrote:

var jar = new CookieJar({ expires: (525600 * 60), path: ‘/’ });

Does this apply (will not show again for a year) even through browser sessions.

David

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

David_McCallum · December 9, 2013, 2:23am

This is a long-lived cookie

Is it because it is generated by the cookiejar script

D

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

waltd · December 9, 2013, 2:38am

No, any cookie that you provide an expires attribute to will expire when you tell it to. CookieJar uses seconds, and calculates the proper date to tell the browser. The spec calls for a particularly-formatted date string as the expires value. The cookiejar script creates or modifies the cookie, but all it is doing is putting a nice object-oriented wrapper on the normal JavaScript cookie handling techniques. To create a cookie in “vanilla” JS, you would do this:

document.cookie = 'foo=bar; expires=Mon, 8 Dec 2014 02:38:11 UTC; path=/'

More examples here: JavaScript - Cookies

Walter

On Dec 8, 2013, at 9:23 PM, DeltaDave wrote:

This is a long-lived cookie

Is it because it is generated by the cookiejar script

D

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

David_McCallum · December 9, 2013, 8:57am

Am I right in saying that because you are specifying a Date specific expiry (through the cookiejar script converting the seconds to a Date) it persists whereas one just set in seconds will not.

And what is the significance in defining the path ie path=/

D

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Tim_Plumb · December 9, 2013, 9:47am

Hi Dave,
Setting any expiry date on a cookie will tell the browser to keep the cookie alive until the time in question. If you don’t specify a date then as Walter says the cookie will remain for as long as the browser needs it - generally these are destroyed when the browser window is closed. The path allows you to define the scope of the cookie and what directories in the site are covered by it. I recently had an issue with an Action that set cookies in a child directory that couldn’t be read in the parent directory because of just this issue. the answer was to specify the path of the cookie to include all of the directories that need to use it. A path of / (slash) tells the cookie to cover the whole domain (or sub domain).
If you leave the path out (it is optional) then the cookie gets set using the current directory as the path.
Regards,
Tim.

On 9 Dec 2013, at 08:57, DeltaDave wrote:

Am I right in saying that because you are specifying a Date specific expiry (through the cookiejar script converting the seconds to a Date) it persists whereas one just set in seconds will not.

And what is the significance in defining the path ie path=/

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

david.ledger · December 9, 2013, 10:08am

At 21:38 -0500 8/12/13, Walter Lee Davis wrote:

No, any cookie that you provide an expires attribute to will expire
when you tell it to. CookieJar uses seconds, and calculates the
proper date to tell the browser. The spec calls for a
particularly-formatted date string as the expires value. The
cookiejar script creates or modifies the cookie, but all it is doing
is putting a nice object-oriented wrapper on the normal JavaScript
cookie handling techniques. To create a cookie in “vanilla” JS, you
would do this:

document.cookie = ‘foo=bar; expires=Mon, 8 Dec 2014 02:38:11
UTC; path=/’

Remember that the setting of the cookie then has to be detected (or
not) by the server, and future pages generated to rely on cookies or
not. This means the server pages have to be PHP pages.

David

–
David Ledger - Freelance Unix Sysadmin in the UK.
email@hidden
www.ivdcs.co.uk

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

waltd · December 9, 2013, 3:35pm

Ordinarily, I’d agree. But in this case, the cookie is read again by JavaScript, not PHP, so the file-type extension isn’t critical here.

One little hiccup that has caught me out many times (in any language) is that the cookie isn’t read again until the page reloads. If you set the cookie, and then read it again, you will get the old (stale) value, not the value you just set. If you need to set the value and use it in the same pass, you should assign the value to a local variable and write it to the cookie, then use the local variable locally.

Walter

On Dec 9, 2013, at 5:08 AM, David Ledger wrote:

At 21:38 -0500 8/12/13, Walter Lee Davis wrote:

No, any cookie that you provide an expires attribute to will expire when you tell it to. CookieJar uses seconds, and calculates the proper date to tell the browser. The spec calls for a particularly-formatted date string as the expires value. The cookiejar script creates or modifies the cookie, but all it is doing is putting a nice object-oriented wrapper on the normal JavaScript cookie handling techniques. To create a cookie in “vanilla” JS, you would do this:

document.cookie = ‘foo=bar; expires=Mon, 8 Dec 2014 02:38:11 UTC; path=/’

Remember that the setting of the cookie then has to be detected (or not) by the server, and future pages generated to rely on cookies or not. This means the server pages have to be PHP pages.

David

–
David Ledger - Freelance Unix Sysadmin in the UK.
email@hidden
www.ivdcs.co.uk

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

ian4 · December 9, 2013, 9:45pm

Wow, thanks for such such speedy and thorough responses!
I will be adding this over the next few weeks, looks like you’ve given me everything I need to get started. Thanks!

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

david.ledger · December 10, 2013, 9:39am

At 10:35 -0500 9/12/13, Walter Lee Davis wrote:

Ordinarily, I’d agree. But in this case, the cookie is read again by
JavaScript, not PHP, so the file-type extension isn’t critical here.

I think you’re missing the purpose of the EU law. If the user doesn’t
want cookies then it’s an offense to send them. Therefore it’s the
server end that need to know not to send them. Server PHP is needed
to recognise the denial and use non-cookie techniques to do what has
to be done.

David

One little hiccup that has caught me out many times (in any
language) is that the cookie isn’t read again until the page
reloads. If you set the cookie, and then read it again, you will get
the old (stale) value, not the value you just set. If you need to
set the value and use it in the same pass, you should assign the
value to a local variable and write it to the cookie, then use the
local variable locally.

Walter

On Dec 9, 2013, at 5:08 AM, David Ledger wrote:
At 21:38 -0500 8/12/13, Walter Lee Davis wrote:
No, any cookie that you provide an expires attribute to will
expire when you tell it to. CookieJar uses seconds, and calculates
the proper date to tell the browser. The spec calls for a
particularly-formatted date string as the expires value. The
cookiejar script creates or modifies the cookie, but all it is
doing is putting a nice object-oriented wrapper on the normal
JavaScript cookie handling techniques. To create a cookie in
“vanilla” JS, you would do this:
document.cookie = 'foo=bar; expires=Mon, 8 Dec 2014 02:38:11 
UTC; path=/’
Remember that the setting of the cookie then has to be detected
(or not) by the server, and future pages generated to rely on
cookies or not. This means the server pages have to be PHP pages.

David

–
David Ledger - Freelance Unix Sysadmin in the UK.
email@hidden
www.ivdcs.co.uk

freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options

Utterchaos23 · May 10, 2018, 11:16am

Hi Waltd,

A great guide that I am just about to try to implement but I have a question if that’s ok…

Do I apply this on the master, the home page or all pages?

I want it to be seen no matter which page the user sees first, i.e. if linked to a contact page and not the Home page

But also, I don’t want them to see the pop-up once for each page they see… does that make sense?

Thanks

James

freewaytalk mailing list
email@hidden
Update your subscriptions at:

waltd · May 10, 2018, 12:57pm

You would put the same code on every page in the site, but no matter where they were when they first saw (and clicked it), they would never see it again. The cookie is for your entire domain, not a particular page.

I also see (looking back in the Web view of this thread) that the formatter didn’t recognize the JavaScript, so the code wasn’t rendered properly here.

var jar = new CookieJar({ expires: (525600 * 60), path: '/' }); 
if( ! jar.get('agreed') ){
  $('example').show().observe('click', function(evt){
    evt.stop();
    jar.put('agreed', true); 
    this.hide(); 
   });
 };

Walter

On May 10, 2018, at 7:16 AM, James I email@hidden wrote:

Hi Waltd,

A great guide that I am just about to try to implement but I have a question if that’s ok…

Do I apply this on the master, the home page or all pages?

I want it to be seen no matter which page the user sees first, i.e. if linked to a contact page and not the Home page

But also, I don’t want them to see the pop-up once for each page they see… does that make sense?

Thanks

James

freewaytalk mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk

freewaytalk mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

fay · January 27, 2022, 2:27pm

Hi Walter
I have just set up the cookie notifications on my site following your instructions above. When I try to preview in browser I am getting a Freeway error message saying:
Please link “cookiejar” to a JavaScript file
Please could you help me as I’m stuck.
Many thanks

waltd · January 27, 2022, 3:30pm

Wow, this is a blast from the past. The CDN definitely still works, and I have checked that the linked script is still there and available. If you are using an HTTPS page (secure) then you must use the HTTPS version of that script in your page:

https://dnk2vbhoq39rr.cloudfront.net/cookiejar/1.5.1/cookiejar.js

If you are not using HTTPS, then you would enter:

http://cdn.freewaypro.com/cookiejar/1.5.1/cookiejar.js

When you are previewing locally, you may need to add the HTTP address to the Action, but if you are hosting under HTTPS (normal, these days) then you must change it back to the secure address. I never set up the security certificate that would allow the URL to be interchangeable w/r/t protocol.

You enter this URL in the Protaculous 2 Action, in the Script URL field opposite the Script Name labeled cookiejar.

Then publish the page (or use Preview in Browser, which will also publish the page) and you should see no error and you should be able to test that cookie behavior. Remember, once you set a cookie, in order to read it back again you must reload the page completely. This can be maddeningly difficult when previewing locally. This may end up being something you have to test “in production”, or at least from an actual Web server somewhere.

Walter

fay · January 27, 2022, 4:21pm

Thanks Walter, I seem to have cleared the error now however the cookie warning line I have set up isn’t showing in the preview, despite being visible in FW? Presumably it works ok if the message is inline and responsive?
I have cleared my cache and cookies in safari and tried again but still not working? If this all sounds I’ll have to try an actual upload instead I guess.
Were there any FW7 templates with a cookie warning I could look at to double check my settings?
Many thanks

waltd · January 27, 2022, 4:36pm

No examples that I know of. This thread started back in 2013, so my memory is not canonical!

If you haven’t already, in the Safari preferences, advanced tab, check the “Show Develop menu” option.

Now you have access to the Develop / Web Console menu item, and you can look in the Local Storage tab to see the individual cookies that your browser has stored when you are on that page. As long as they are not secure cookies (and these would not be, by default) you should be able to read the data that they contain. Remember, the cookies only appear when the page that set them is open in the browser, and then, only after you have done a full hard reload of that page after setting the value.

Walter