Cookies or PHP Sessions - Save within MySQL table

Hi,

How do I generate a cookie or PHP Session id depending on whether the user has cookies enabled and store ‘either’ within a MySQL table?

I would like to design a shopping basket that uses cookies to remember what the user has added to the basket. If they do not have cookies enabled I want the basket to work with PHP Sessions instead. I know it is possible but I do not understand how to code it. What code do I use to add a cookie or start a PHP session if cookies disabled? And how do I ‘post’ (or add) the cookie, or PHP Session to a MySQL table?

Matt.

Sessions will need to use cookies to work anyway (ideally) - passing the session id in the URL is insecure.

I advise you to just use sessions. A shopping basket is not really suited to cookies. Cookies will persist when the browser is closed (unless you set them to be session cookies, in which case you should just use sessions anyway).

It would be a minimal amount of people using the Sessions as most people enable cookies. I want people to be able to comeback a week later and purchase with the items they previously added to the basket. But i do not want to lose customers who do not enable cookies (this will be between 1 and 5% of customers).

How do I code it to say add a cookie to the users computer, if cookies disabled start a session instead. And then add the cookie or session information to a MySQL database?

Matt.

Sessions need cookies to work - unless you want to add ?PHPSESSID=etc to every link and URL (http://php.net/manual/en/session.idpassing.php)

You should store the shopping basket in a database and reinstate when the user logs back in. That is the only secure way.

The only way to ensure that the user accepts cookies is to set a cookie and then try to read it.

Something like:


if  ( ! isset($_COOKIE['testcookie']) & ! isset($_SESSION['cookie']))
{   
   setcookie('testcookie', 'foobar');
   $_SESSION['cookie'] = true;
}
else
{
   $_SESSION['cookies_allowed'] = (isset($_COOKIE['testcookie'])) : true : false;
}

I do not understand the code. What does the ‘else’ bit do? Also, it says there is an error with the else statement too so maybe it features an error?

Matt.

Sorry, typo. Here is the correct code:


if  ( ! isset($_COOKIE['testcookie']) & ! isset($_SESSION['cookie']))
{   
    setcookie("testcookie", 'foobar', time()+3600, '/', '.example.com', false, true);
   $_SESSION['cookie'] = true;
}
else
{
   $_SESSION['cookies_allowed'] = (isset($_COOKIE['testcookie'])) ? true : false ;
}

It just sets a cookie and then tries to read the cookie on the next page load. It uses sessions to only set the cookie once, and to store whether cookies are available or not.

http://php.net/manual/en/function.setcookie.php

It is not any more insecure than session use in the first place. The session value must be transmitted somehow - if not in the URL then in the header as a “cookie”. Hackers can falsify a cookie as easily as they can modify a URL. Do not get the false impression that passing the session id in a cookie gives added security - it doesn’t.

Nothing is secure :slight_smile: Using cookies for sessions is not “secure”, but it’s slightly more secure than exposing the session id in the URLs/links.

There are several reasons why it’s preferable to use cookies rather than URLs to transport the session id.

I get another error now: It says this when uploaded and loaded in web browser:

Warning: setcookie() expects at most 6 parameters, 7 given in /home/content/J/a/m/JamesBent/html/addcookie.php on line 4

Oh sorry, you must be using a version of PHP less than 5.2.

Just remove the last argument then:


setcookie("testcookie", 'foobar', time()+3600, '/', '.example.com', false);

Obviously you need to change .example.com to whatever your domain is (keep the leading dot).

The code needs to be run on every page load. Then you can know whether cookies are available by checking the $_SESSION[‘cookies_allowed’] variable.

I wouldn’t agree that it is even slightly more secure. Tools to modify session cookies are widely available to the script kiddie set. Ironically, many of those kiddies are incompetent enough that moving the session to the URL would throw them off.

There are several reasons why it’s preferable to use cookies rather than URLs to transport the session id.

Agreed, but security isn’t one.

It’s more visible in the URLs - and doesn’t require any special tools to view, especially if it’s embedded in the actual HTML links where it might be indexed by search engines etc.

Obviously if a hacker is determined to steal a session id then using cookies instead of the URL will not make much difference.

Well, it’s certainly true that passing data in the URL is more exposed than passing data in HTTP headers. You’re making a broad statement based on a narrow concern (an attacker modifying data).

The biggest concern with a session identifier is exposure. You’re right that an attacker can falsify a session identifier, but who cares? The real concern is whether the attacker can determine the session identifier of another user, otherwise the “attack” is no more dangerous than session_regenerate_id().

Creating a new secret key each request just about eliminates that possibility. So the session ID is persistent but a key that goes along with it changes. In order to access the session you need to know both the session ID and secret key. The secret key can either be stored in the session data itself of db depending on how session data storage is being managed.

You would override the default session handlers with your own routines to store the data in the persistent mechanism of your choice.

If you want a working example, I am doing just that in my framework.

Which I believe I built after reading this article as its based on the same principles. That was about two years ago so I could be wrong but I believe that was the article.