Testing to see if cookies are enabled

[HenryCan]

I want to give the visitors to my site the option of setting certain preferences and remembering what was chosen from one visit to the next. They might have the choice of setting the backgrond colour of the web page or the font or whatever.

 

I've already written and tested code to write standard cookies that preserve their choices. However, I'm wondering if that's the best way or if there is a better approach. I don't want visitors to have to re-choose their preferences every time they arrive at the site, which would appear to be the result of using a session cookie stored on the server.

 

If standard cookies ARE the best solution for my situation, how can I test if the visitor has cookies enabled on their browser? I know that some people definitely don't enable cookies and I'm quite prepared to advise them that they won't be able to save preferences until they enable cookies. However, I first need to know how I can tell definitively if cookies are enabled.

 

Most of the simple code examples I've found by googling simply try to write a cookie and then try to read it; if both succeed, they think the they've established whether cookies are enabled. The more sophisticated examples, particularly those at stackoverflow, come closer but all of them seem to be critiqued by someone to the effect that they won't work in this or that particular situation.

 

Given how long cookies and PHP have been in existence, I have to believe that SOMEONE has figured out a definitive way of testing whether cookies are enabled that works in all reasonable circumstances.  Can anyone share that technique with me?

[davidannis]

 

The more sophisticated examples, particularly those at stackoverflow, come closer but all of them seem to be critiqued by someone to the effect that they won't work in this or that particular situation.

I'm not sure what situation they won't work in, but if you can't read the test cookie you wrote then you won't be able to read the preference cookie that you wrote. The browser doesn't know that the cookie is a test. I would just have the page after they set the preference cookie try to read the preference cookie and if it is not found tell them that you couldn't store their preferences for the next time and suggest that they may need to enable cookies.

[ginerjm]

 I have never thought about testing - if my cookies don't show up, I default them to blanks and operate with those values.

 

I have to think that setting a test cookie upon startup prior to clicking on the link to open up a preferences selection page would work.  If they click to set their preferences, you simply check for the test cookie and if you fail to get it, you direct them to an 'error' page telling them they need cookies.  Otherwise you let them set away!

 

Of course if you are going to have a lot of these cookies you might want to think about a db table to contain all the settings.

[Psycho]

Most cookie checks I've seen rely on JavaScript so that the user can be alerted on the very first page load. But, that requires that JS be enabled as well. With PHP only you would only be able to check a cookie on a subsequent page load.

 

In your situation, I would simply set the cookie on the first page load and then wait until the user goes to change a setting and alert them then that they are not accepting your cookies and that their settings will not persists past the current session. Also, you don't need a "test" cookie. Have one cookie as an array with all the settings. So, on first page load, just set the initial cookie as an empty array (if it doesn't already exist).

[HenryCan]

I'm not sure what situation they won't work in, but if you can't read the test cookie you wrote then you won't be able to read the preference cookie that you wrote. The browser doesn't know that the cookie is a test. I would just have the page after they set the preference cookie try to read the preference cookie and if it is not found tell them that you couldn't store their preferences for the next time and suggest that they may need to enable cookies.

The gist of it is that you can't fetch a newly-created cookie immediately after creating it: you have to send a new batch of headers before you can possibly see the new cookie. These are the top two search engine hits to my question:

http://stackoverflow.com/questions/6663859/check-if-cookies-are-enabled  -and-

http://stackoverflow.com/questions/9448424/detect-if-cookies-are-enabled-in-php

 

All the replies seem to get criticized for something or another, although I may be misunderstanding what I'm reading.

 

As for your suggestion, I'm struggling a bit with how to distinguish between the case of:

1. no cookie has been set because the visitor has never been here before

2. no cookie has been set because the visitor has disabled cookies (or someone did it for them and they don't realize they are disabled)

 

I'd like to avoid offering the visitor a Preferences page if it isn't possible for me to save those preferences in a cookie. If they arrive on the Preferences page on their own, I'd like to be able to write code that tells them that cookies are disabled so they will need to enable them before trying to save any preferences.  I'd show that message right at the top in bold different coloured text so they couldn't miss it and would probably disable the Submit button as well, only re-enabling it if they can actually save a cookie. 

 

I'd rather not force visitors to go to the Preferences page if I can avoid it. Most of them will be perfectly happy with the default values that get set if no Preferences have been selected. I don't want to pressure them to enable cookies just so that I can store Preferences that are identical with default values. I certainly don't want to keep nagging them on every page that cookies are turned off and they should turn them on since many visitors will want to go with values that aren't the default

 

I'm fine with giving them default values if no cookies exist because they haven't been to the site before and haven't chosen any Preferences. I'd rather not force everyone to go to the Preferences page, even if all they have to do is click Submit to save the defaults. However, I might be arm-twisted into going for that if it's the only reasonable way forward.

[HenryCan]

 I have never thought about testing - if my cookies don't show up, I default them to blanks and operate with those values.

 

I have to think that setting a test cookie upon startup prior to clicking on the link to open up a preferences selection page would work.  If they click to set their preferences, you simply check for the test cookie and if you fail to get it, you direct them to an 'error' page telling them they need cookies.  Otherwise you let them set away!

 

Of course if you are going to have a lot of these cookies you might want to think about a db table to contain all the settings.

Please see my reply to Davidannis.

 

I don't think I'm likely to generate enough preferences to need a database table. In any case, I'm not awfully worried about database work; I've done lots of that. Some of it was even with PDO and MySQL, both of which are available in my current environment ;-)

 

Hmm. Am I understanding you correctly? Are you proposing a database table INSTEAD of cookies? Or are you suggesting them as a supplement to the cookies? If the latter, what is the table going to do that the cookie doesn't?

[HenryCan]

Most cookie checks I've seen rely on JavaScript so that the user can be alerted on the very first page load. But, that requires that JS be enabled as well. With PHP only you would only be able to check a cookie on a subsequent page load.

 

In your situation, I would simply set the cookie on the first page load and then wait until the user goes to change a setting and alert them then that they are not accepting your cookies and that their settings will not persists past the current session. Also, you don't need a "test" cookie. Have one cookie as an array with all the settings. So, on first page load, just set the initial cookie as an empty array (if it doesn't already exist).

Please see my reply to Davidannis. I really don't want to bring JavaScript into the situation since some visitors will certainly have it turned off.

I think your approach would make me send the visitor to the Preferences page if he hasn't already set some Preferences and I'm reluctant to do that.  Also, what do you mean be having one cookie be an array with all the settings? Is there some reason that a single complex cookie is a much better choice than several simple cookies? And aren't I going to run into issues with the max cookie size of 255 bytes? (At least I think that's what it was back in the early days; perhaps it has been increased in recent years.)

 

I don't actually know how much data I will have to save yet. I'm prototyping a design of my own creation. I may end up letting my visitors choose preferences for a whole bunch of things or maybe just a small handful. It depends on the feedback I get as I test. If they want more control, I'll have to save more data. Multiple simple cookies, each with a clear purpose, seems a little easier at first glance than having to make up a lot of very short codes for everything (assuming many values to be saved) and then packing and unpacking/parsing all of that information once I retrieve the cookie. But that's just an initial reaction. I'm open to trying to cram everything into a single cookie if there is some large benefit to it.

[kicken]

What is being suggested is you just set the cookie regardless of if they want to set custom preferences or not. You'll likely have some common file you include on each request to read the preferences. What you do is just add code there so that if your preferences cookie is not found, you set it.

if (empty($_COOKIE['preferences'])){
   setcookie('preferences', 'whatever');
}

If the cookie does not exist, you can assume that they are not allowing it. By their second page visit either it will be set already or it wont be due to being blocked. On your preferences page you can then just check if the cookie exists and if not, show your cookies must be enabled message. Unless the preferences page is their very first page visited (unlikely) your message will be more or less accurate.

 

As for the size of the cookies, my memory suggests that around 2k was the upper limit, however if you think you'll need to store a decent amount of data, I would recommend generating a random ID and storing only that in the cookie. You can then use that to look up the preferences in your database. This is essentially the same principal that sessions use.

[ginerjm]

I'll try to explain again.

 

Have your home page - or starting page of your appl - set a cookie before outputting the page  Simple.

Have a link on this  page to take the user to the preferences page. Handle it in the current page's script instead of calling the preferences page directly.  If the script detects that the preferences link was clicked, have this same script check if your previous cookie exists - if so send a header to redirect you to your preferences page (or however you will handle them).  If the cookie does not exist then simply return the user to the same page with a message. 

[Psycho]

Also, what do you mean be having one cookie be an array with all the settings? Is there some reason that a single complex cookie is a much better choice than several simple cookies? And aren't I going to run into issues with the max cookie size of 255 bytes? (At least I think that's what it was back in the early days; perhaps it has been increased in recent years.)

 

Early days? The standard (per RFC 2109) has been at least 4K for almost 2 decades. Which should be more than enough for simple preferences.

 

 

And, yes, it does make sense to create a cookie with a single array rather than having to manage individual cookies. For one, as all of us have been saying, you would just set the cookie (if it doesn't exist) on any page load. Then when the user accesses (or attempts to access) the preferences page you simple check if the cookie exists. Heck, you could even hide the link to the preferences page if the cookie doesn't exist. Otherwise you don't know "which" cookie to look for requiring you to create a "test" cookie. That only creates a dependency that isn't needed and adds complexity. Plus, with a single cookie you only have to write code to create/update the cookie once. As you add/edit the preferences it would take more time and code to implement those changes since you also need to handle the writing/reading of those new cookies. Each cookie should have a specific purpose. And, lastly, there is a limit on the maximum number of cookies that you can have per domain and you would be more likely to hit that limit than the size limit of a single cookie. Per RFC 2109 a browser only has to support 20 cookies.

 

http://support.microsoft.com/kb/306070/en-us

Edited August 14, 2014 by Psycho