Try and set a cookie, then try and read it back.
If you can do this, then cookies are not blocked.
Here is a good tutorial on how to do that: http://www.quirksmode.org/js/cookies.html
They might be if you haven’t moved to a different page between the write and the read as the saved cookies are only ever read in as the page is loaded.
The code on the page linked to can only read the cookie value back in on the current page because the cookie being created is also saved with the ones read in and so can be read back even if cookies are blocked (as can be easily demonstrated if you block cookies and then run the create and read options in the sample test on that site.
And so the solution would be what?
If I’m understanding right, you need cookies only for the session id.
If the browser blocks cookies, you can still get around this by including the session id in the URL for all of your links.
So, you do not need any JavaScript solution. Instead, from PHP you can check if cookies are supported (set a cookie, go to a new page and check if that cookie can be read in), and if they’re supported you know that the session id will be retained via the use of cookies.
If cookies aren’t supported though you can still use the session id - you just have to ensure that every single link on the page includes the session id. That is something only needs to occur if cookies aren’t supported.
An easy way to achieve this is:
- check the URL, and if it has a session id, to carry on using that technique for all of your links.
- If the URL has no session id, you can check if you can get the session id from the cookies.
- If the cookies have no session id, it might be their first time visiting your page so use a separate page load to create a new session and also at the same time check if cookies are supported.
- If cookies are not supported you know that you need to add the session id to all of your links, which will then feed right back in to step 1 above.
Information on passing the Session ID in PHP will definitely be useful.
In regard to details on how to program this sort of solution - I will happily pass the buck to our PHP forum, as it is far outside the scope of the JavaScript forum.
Then you could use setTimeout
setCookie();
setTimeout(function(){
if(readCookie()){
console.log("Om nom nom!");
} else {
console.log("No cookies for you, fatso!");
}
}, 1000);
2 Likes
Your setTimeout isn’t loading a new page so the cookies being actually read in are not being refreshed.
JavaScript only reads cookies in from the actual cookie file when the page is first loaded. That setCookie() function is adding the cookie data to the cookies read in so that it can be accessed by the current page as well as subsequent pages.
So the cookie set in your code is ALWAYS readable by readCookie() on the current page but will only be readable by subsequent pages if the cookie is actually allowed to be saved. I tested the original code with cookies blocked and the readCookie() was able to read the blocked cookie without any problem until the page was refreshed. . Your settimeout code would simply log “Om nom nom!” every second.
You can’t tell until you get to a new page whether the prior page allowed a cookie to be stored or not.
In the case of session cookies the cookie is passed from page to page in the HTTP headers but only if session cookies are enabled. I have not yet tested whether making the cookies server side only will allow them to be passed even if session cookies are disabled in the browser.
PHP has options for allowing sessions to be passed by cookie or in the URL. If either is turned off then the cookie can’t be passed that way. My understanding is that if you enable both ways then the session will be passed in a cookie if cookies are allowed and passed in the URL if cookies are blocked.
Really? Let me test that.
So this works for me on Chrome:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<title>Cookie test</title>
</head>
<body>
<script src="js.cookie.js"></script>
<script>
Cookies.set('test', 'hello');
setTimeout(function(){
var cookieValue = Cookies.get('test');
if(cookieValue){
console.log("Om nom nom!");
} else {
console.log("No cookies for you, fatso!");
}
Cookies.remove('test');
}, 1000);
</script>
</body>
</html>
When I block localhost:
I see “No cookies for you, fatso!” logged to the console:
When I remove the block (or explicitly allow cookies):
I see “Om nom nom!” logged instead:
For ease of use, I’m using this cookie library: https://github.com/js-cookie/js-cookie
How many other browsers does it not work with. It’s likely that chrome is trying to be more flexible than it should in allowing that to work
It also works in Firefox. I’m on Linux, so I can’t test in anything else.
Correct.
But as mentioned above, that is discouraged for security reasons, so I will pass on that approach.
But checking for cookies is a JavaScript issue as far as I understand.
Blocking cookies doesn’t block access to the $_SESSION variable or the ability to start a session. Blocking them will prevent session persistence between page loads but you should be logging your errors before you send the page back to the user anyway, so lack of session persistence shouldn’t be an issue.
My “errors.php” script is responsible for both displaying an error message to the end user and logging the error in my database and e-mailing the error to the Admin for immediate action.
If someone blocks cookies then error codes don’t get passed from the problematic script to the “errors.php” script and none of the above will happen which is a major issue!
If I had 100 people who blocked cookies, and they all went to “buggy-script.php”, then each user would get a message saying “Some catchall error happened” which is confusing to then, and my database would contain 100 entries of “99999_some_catchall_error” which be useless to me in trying to figure out where the original bug started.
It is your visitors who decide whether to use the less secure method though by blocking cookies. If they want their session to be more secure they can allow the sessionid to be stored in a cookie instead of forcing it into the URL.
If you disallow it in the URL and they disallow it in the cookie then there is no option left.
Okay, but what has me perplexed is why no one has just said, “Look, Mikey, just copy and paste these 10 lines of code into the top of every script and the JavaScript will identify if the user has cookies blocked and if they do then it will redirect to an error page of your choosing.”
As I have stressed, I do not know JavaScript and I am pleading for some hand-holding on this topic since it isn’t practical for me to try and learn JavaScript in order to fix one problem. (And, yeah yeah, I will try and finally learn it maybe later this summer if I have time.)
Pardon my ignorance, but I haven’t seen any response obvious like that. Instead I see lots of you debating over how things work and lots of solutions that are going all over the map.
Not being critical, but since I don’t know an ounce of JavaScript - or even what jQuery is - a lot of what you guys are debating is over my head.
To me, there should be two options…
1.) Use JavaScript to check if a user has blocked cookies, and if so display a page saying, “If you want to use the site then unblock cookies.” (Wish I could find an example of that because I have seen them before - I recall some newspaper in Australia does that?!)
2.) Come up with a better architecture for my website - which I am leaning towards - so that my website’s error messages are not dependent on Sessions (and Session Cookies)!
In fairness, Felgall, you do make some interesting points in your last post, and maybe I should listen to them. But I figured it would be supper easy to use JavaScript to do what I asked about above, yet based on my own research online and the meandering of this conversation, it apparently isn’t so black and white…
Excellent. It seems that you’re beginning to realize that JavaScript is not a good solution to your problem. The situation that you have here is one that’s best handled from the server - not the client.
Don’t do it that way. You do not want your script’s ability to log its errors to be under any control from the client - this is a severe security risk. For example, if an attacker figures out they can cause an error state to log by setting a cookie, they could DDOS you by flooding out your disk space through the error logs. Worse - if the contents of the cookie are being written to disk the system could be comprimised - COOKIE input is under client control and cannot be trusted anymore than GET or POST.
Also, if you ever choose to run your scripts from the CLI interface your error system won’t be able to work at all.
Instead of homebrewing an error logging system, take a look at Whoops or BooBoo and see if they can meet your needs. Also look at the possibilities inherent in register_shutdown_function which can log errors even in the face of parse_errors.
But whatever your doing that requires browser interaction, stop it now. It isn’t safe.
2 Likes
A couple of years ago Europe made it mandatory for all European web sites to declare if they use cookies. Most of the big sites check and show if cookies are enabled. Let us know if you find any sites that suit your requirements.
Edit:
I just followed the links from BBC.co.uk and liked this implementation.
It tells the person that the site is about to place a cookie on their computer. If the person decides not to allow it then they can block the cookie before the next page gets loaded.
This type of indication by the site HAS NOTHING WHATEVER to do with the question about testing if cookies are blocked.
Testing if cookies are blocked requires two separate web pages with the first page setting a cookie and the second trying to read the cookie the first page set. This is best done by the server.
The point I was trying to make was that all/most large European websites follow the https://ico.org.uk/ cookie guidelines.
I was trying to imply that the OP tested numerous sites, with cookies disabled, to see if there are any suitable solutions.