Can't login or checkout without cookies plus other misc problems

AJRYAN · April 10, 2013

Back in December my hosting service decided to upgrade to PHP 5.3.19 and that's when the problems began. Since then I have cleaned up most of all the deprecated code and now my logs look normal with some exceptions which I'll list below. But my biggest immediate problem is with sessions and/or cookies. I just discovered that there is no way to login or checkout without having cookies enabled.

My shop was up and running back in 2004, (2.2) and I kept up with all of the security updates and patches, It is heavily modified, and has Chemo's SEO contribution.

Here's the section of my phpinfo related to cookies/sessions:

session.auto_start Off Off session.bug_compat_42 On On session.bug_compat_warn On On session.cache_expire 180 180 session.cache_limiter nocache nocache session.cookie_domain no value no value session.cookie_httponly Off Off session.cookie_lifetime 0 0 session.cookie_path /cccccccccc/ / session.cookie_secure Off Off session.entropy_file no value no value session.entropy_length 0 0 session.gc_divisor 100 100 session.gc_maxlifetime 1440 1440 session.gc_probability 1 1 session.hash_bits_per_character 4 4 session.hash_function 0 0 session.name osCAdminID PHPSESSID session.referer_check no value no value session.save_handler user files session.save_path /tmp /tmp session.serialize_handler php php session.use_cookies On On session.use_only_cookies On On session.use_trans_sid 0 0

I don't know what the setup was like prior to the upgrade, but I have a suspicion that session_use_only_cookies was probably set to off, or something. But anyhow something doesn't appear right here for the cart to operate normally without cookies useage being forced in the cart. Would my assumptions be correct and which of these should be changed, and should I be able to expect cooperation from my hosting service? They are going downhill fast and I am about to jump ship because of both degrading server performance and technical competence. I would prefer not to have to force cookies. The way things are setup now, if my customers try to login or checkout, they receive no warning if forced cookie useage is set to false in the admin side of things.

Lastly, the following log errors are persistent even after the updates but I still cannot find or figure out solutions for them and I have looked everywhere. I am hoping someone can shed some light on these for me, point me to the right solutions or help me figure them out.

PHP Notice:  Undefined index: 99.36.176.228 in /home/ccccccc/public_html/includes/functions/user_tracking.php on line 58
PHP Notice:  Undefined index: cPath in /home/ccccccc/public_html/includes/functions/user_tracking.php on line 45
PHP Notice:  Undefined index: products_id in /home/ccccccc/public_html/includes/functions/user_tracking.php on line 41
PHP Notice:  Undefined variable: container in /home/ccccccc/public_html/includes/functions/html_output.php on line 29
PHP Notice:  Undefined variable: recently_viewed in /home/ccccccc/public_html/includes/boxes/recently_viewed.php on line 16
PHP Notice:  Undefined variable: rewrite_category in /home/ccccccc/public_html/includes/functions/html_output.php on line 101
PHP Notice:  Undefined variable: rewrite_product in /home/ccccccc/public_html/includes/functions/html_output.php on line 101
PHP Warning:  mysql_num_rows() expects parameter 1 to be resource, null given in /home/ccccccc/public_html/includes/functions/database.php on line 107
PHP Warning:  call_user_func() expects parameter 1 to be a valid callback, function 'header_tags_reset_cache' not found or invalid function name in /home/ccccccc/public_html/ccccccc/includes/functions/general.php on line 1241

I think some of this, at least, is related to categories, since when I click on various categories which have no subcategories is when I get the mysql_num_rows() error.

I am a bit of a hack when it comes to programming in general, but a careful one, and I am afraid this stuff is above my level of comfort to tackle without some guidance at least.

If anyone can help me on any of this I would be most grateful and want to thank you in advance!

AJRYAN · April 10, 2013

One other error just cropped up in the log which I also have no idea where it comes from or how to fix:

Undefined variable: _SESSION in /home/cccccc/public_html/includes/functions/sessions.php on line 186

Thanks

AJRYAN · April 10, 2013

UPDATE;

It turns out that I have access to a php.ini file. Just in case anyone else runs into this, it appears that I fixed it by setting session.use_only_cookies = 0

Prior to that it was commented out and set to 1. The file claims that it defaults to 0 but it appears that this is not the case.

Anyhow, I would still appreciate some help with my other issues, please.

Thanks

MrPhil · April 12, 2013

$_SESSION should be built into PHP ever since 4.1.0 (and was $HTTP_SESSION_VARS before that). Are you sure you're still running at PHP 5.3? Is there anything in php.ini that you don't know the reason for? Maybe there are other things commented out (or in) in your php.ini that are wrong. It sounds like you're using a php.ini that is a copy of the master, or something. php.ini files should have only those settings in them that you're trying to override. Run

<?php phpinfo(); ?>

before and after a php.ini change to see what's changed.

Note that some hosts don't allow you to change PHP settings via php.ini. I take it you've checked that you're able to?

All the "undefined" stuff means code errors in osC (nothing to do with the PHP version). The "parameter" problems? I dunno. Fix the other stuff first and maybe those will resolve themselves.

AJRYAN · April 12, 2013

Strange thing about the _SESSION thing in the log. It is most definitely 5.3.19 I am on. And yes I do have access to php.ini which is how I

was able to fix the cookie/sessions pronblem. These other things have me stumped though.

Thanks

MrPhil · April 13, 2013

Can you post here the line that it's complaining about, and 5 or more lines before and after? Did the original osC that old have $_SESSION in it, or is that your edit? You don't have both $HTTP_SESSION_VARS and $_SESSION in use at the same time, do you? In your editing, could TABLE_SESSIONS have become _SESSION somehow?

AJRYAN · April 16, 2013

Thanks for you help MrPhil. Sorry I was able to get back to you sooner but I've been pretty sick.

Here is some code from sessions.php - I wonder if you can judge by looking at it where there might be a problem. I wonder if it has anything to do with register globals. The other possibility I wonder about is a patch by FWR which monkeys with long vs short built in variable names

The other stuff is puzzling because those files have never been touched that I can remember, but perhapsthe way the code is writen around some of these functions was impacted by the change to 5.3

Thanks again..

function link_session_variable($var_name, $map)
 {
   if ($map)
   {
  // Map global to session variable. If the global variable is already set to some value
  // then its value overwrites the session varibale. I **THINK** this is correct behaviour
  if (isset($GLOBALS[$var_name]))
  {
    $_SESSION[$var_name] = $GLOBALS[$var_name];
  }
  $GLOBALS[$var_name] =& $_SESSION[$var_name];
   }
   else
  {
  // Unmap global from session variable (note that the global variable keeps the value of
  // the session variable. This should be unnecessary but it reflects the same behaviour
  // as having register_globals enabled, so in case the OSC code assumes this behaviour,
  // it is reproduced here
  $nothing;
  $GLOBALS[$var_name] =& $nothing;
  unset($GLOBALS[$var_name]);
  $GLOBALS[$var_name] = $_SESSION[$var_name];
   }
 }
// <<< END REGISTER_GLOBALS
 function tep_session_id($sessid = '') {
   if (!empty($sessid)) {
  return session_id($sessid);
   } else {
  return session_id();
   }
 }
 function tep_session_name($name = '') {
   if (!empty($name)) {
  return session_name($name);
   } else {
  return session_name();
   }
 }
 function tep_session_close() {
// >>> BEGIN REGISTER_GLOBALS
   // Work-around to allow disabling of register_gloabls - unmap all defined
   // session variables
   if (count($_SESSION))
   {
  $session_keys = array_keys($_SESSION);
  foreach($session_keys as $variable)
  {
    link_session_variable($variable, false);
  }
   }
// <<< END REGISTER_GLOBALS

MrPhil · April 16, 2013

You have register global variables turned OFF, and an add-on installed to eliminate the need for them? Possibly your PHP is getting confused if you still have the switch in php.ini to turn them off. Try commenting it out -- register globals OFF should be the default for quite a while.

Exactly which line in the file you gave is it complaining about? Is that the complete file, or just a piece of it?

AJRYAN · April 17, 2013

This is all a bit confusing. It look to me like there are a few parts related to globals = off. My bran cannot decipher this and was hoping you could take a look

I wish I were skilled enough to trace all this stuff back to the original code called from I might be better adept at dealing with this. Anyhow here is my sessions.php file:

<?php
/*
 $Id: sessions.php,v 1.19 2003/07/02 22:10:34 hpdl Exp $
 osCommerce, Open Source E-Commerce Solutions
 http://www.oscommerce.com
 Copyright (c) 2003 osCommerce
 Released under the GNU General Public License
*/
 if (STORE_SESSIONS == 'mysql') {
   if (!$SESS_LIFE = get_cfg_var('session.gc_maxlifetime')) {
  $SESS_LIFE = 7880;
   }
   function _sess_open($save_path, $session_name) {
  return true;
   }
   function _sess_close() {
  return true;
   }
   function _sess_read($key) {
  $value_query = tep_db_query("select value from " . TABLE_SESSIONS . " where sesskey = '" . tep_db_input($key) . "' and expiry > '" . time() . "'");
  $value = tep_db_fetch_array($value_query);
  if (isset($value['value'])) {
    return $value['value'];
  }
  return false;
   }
   function _sess_write($key, $val) {
  global $SESS_LIFE;
  $expiry = time() + $SESS_LIFE;
  $value = $val;
  $check_query = tep_db_query("select count(*) as total from " . TABLE_SESSIONS . " where sesskey = '" . tep_db_input($key) . "'");
  $check = tep_db_fetch_array($check_query);
  if ($check['total'] > 0) {
    return tep_db_query("update " . TABLE_SESSIONS . " set expiry = '" . tep_db_input($expiry) . "', value = '" . tep_db_input($value) . "' where sesskey = '" . tep_db_input($key) . "'");
  } else {
    return tep_db_query("insert into " . TABLE_SESSIONS . " values ('" . tep_db_input($key) . "', '" . tep_db_input($expiry) . "', '" . tep_db_input($value) . "')");
  }
   }
   function _sess_destroy($key) {
  return tep_db_query("delete from " . TABLE_SESSIONS . " where sesskey = '" . tep_db_input($key) . "'");
   }
   function _sess_gc($maxlifetime) {
  tep_db_query("delete from " . TABLE_SESSIONS . " where expiry < '" . time() . "'");
  return true;
   }
   session_set_save_handler('_sess_open', '_sess_close', '_sess_read', '_sess_write', '_sess_destroy', '_sess_gc');
 }
 function tep_session_start() {
// >>> BEGIN REGISTER_GLOBALS
   $success = session_start();
   // Work-around to allow disabling of register_globals - map all defined
   // session variables
   if ($success && count($_SESSION))
   {
  $session_keys = array_keys($_SESSION);
  foreach($session_keys as $variable)
  {
    link_session_variable($variable, true);
  }
   }
   return $success;
// <<< END REGISTER_GLOBALS
 }
 function tep_session_register($variable) {
   global $session_started;
// >>> BEGIN REGISTER_GLOBALS
   $success = false;
   if ($session_started == true) {
// -skip-   return session_register($variable);
  // Work-around to allow disabling of register_globals - map session variable
  link_session_variable($variable, true);
  $success = true;
   }
   return $success;
// <<< END SESSION_REGISTER
 }
 function tep_session_is_registered($variable) {
// >>> BEGIN REGISTER_GLOBALS
//    return session_is_registered($variable);
   return isset($_SESSION[$variable]);
// <<< END REGISTER_GLOBALS
 }
 function tep_session_unregister($variable) {
// >>> BEGIN REGISTER_GLOBALS
   // Work-around to allow disabling of register_gloabls - unmap session variable
   link_session_variable($variable, false);
   unset($_SESSION[$variable]);
//  return session_unregister($variable);
   return true;
// <<< END REGISTER_GLOBALS
 }

// >>> BEGIN REGISTER_GLOBALS
 // Work-around function to allow disabling of register_globals in php.ini
 // This is pretty crude but it works. What it does is map session variables to
 // a corresponding global variable.
 // In this way, the main application code can continue to use the existing
 // global varaible names but they are actually redirected to the real session
 // variables
 //
 // If the global variable is already set with a value at the time of the mapping
 // then it is copied over to the real session variable before being mapped back
 // back again
 //
 // Parameters:
 // var_name - Name of session variable
 // map - true = map variable, false = unmap varaible
 //
 // Returns:
 // None
 function link_session_variable($var_name, $map)
 {
   if ($map)
   {
  // Map global to session variable. If the global variable is already set to some value
  // then its value overwrites the session varibale. I **THINK** this is correct behaviour
  if (isset($GLOBALS[$var_name]))
  {
    $_SESSION[$var_name] = $GLOBALS[$var_name];
  }
  $GLOBALS[$var_name] =& $_SESSION[$var_name];
   }
   else
  {
  // Unmap global from session variable (note that the global variable keeps the value of
  // the session variable. This should be unnecessary but it reflects the same behaviour
  // as having register_globals enabled, so in case the OSC code assumes this behaviour,
  // it is reproduced here
  $nothing;
  $GLOBALS[$var_name] =& $nothing;
  unset($GLOBALS[$var_name]);
  $GLOBALS[$var_name] = $_SESSION[$var_name];
   }
 }
// <<< END REGISTER_GLOBALS
 function tep_session_id($sessid = '') {
   if (!empty($sessid)) {
  return session_id($sessid);
   } else {
  return session_id();
   }
 }
 function tep_session_name($name = '') {
   if (!empty($name)) {
  return session_name($name);
   } else {
  return session_name();
   }
 }
 function tep_session_close() {
// >>> BEGIN REGISTER_GLOBALS
   // Work-around to allow disabling of register_gloabls - unmap all defined
   // session variables
   if (count($_SESSION))
   {
  $session_keys = array_keys($_SESSION);
  foreach($session_keys as $variable)
  {
    link_session_variable($variable, false);
  }
   }
// <<< END REGISTER_GLOBALS
   if (PHP_VERSION >= '4.0.4') {
  return @session_write_close();
   } elseif (function_exists('session_close')) {
  session_close();
   }
 }
 function tep_session_destroy() {
// >>> BEGIN REGISTER_GLOBALS
   // Work-around to allow disabling of register_gloabls - unmap all defined
   // session variables
   if (count($_SESSION))
   {
  $session_keys = array_keys($_SESSION);
  foreach($session_keys as $variable)
  {
    link_session_variable($variable, false);
    unset($_SESSION[$variable]);
  }
   }
// <<< END REGISTER_GLOBALS
   return session_destroy();
 }
 function tep_session_save_path($path = '') {
   if (!empty($path)) {
  return session_save_path($path);
   } else {
  return session_save_path();
   }
 }
 function tep_session_recreate() {
   if (PHP_VERSION >= 4.1) {
  $session_backup = $_SESSION;
  unset($_COOKIE[tep_session_name()]);
  tep_session_destroy();
  if (STORE_SESSIONS == 'mysql') {
    session_set_save_handler('_sess_open', '_sess_close', '_sess_read', '_sess_write', '_sess_destroy', '_sess_gc');
  }
// >>> BEGIN REGISTER_GLOBALS
//    tep_session_start();
//    $_SESSION = $session_backup;
  session_start();
  $_SESSION = $session_backup;
  // Work-around to allow disabling of register_globals - map all defined
  // session variables
  if (count($_SESSION))
  {
    $session_keys = array_keys($_SESSION);
    foreach($session_keys as $variable)
    {
	  link_session_variable($variable, true);
    }
  }
// <<< END REGISTER_GLOBALS
  unset($session_backup);
   }
 }
?>

I checked my server and RG is set to off. I'm wondering if I should set it to on and see what happens.

My store is heavily modified, so I would prefer to fix the error and bring it up-to-date rather than resinstalling a new

up to date cart.

Do you think these errors could all be session related? I haven't verified this but I have a hunch the _session error

may only show up when cookies are off

Anyhow, thanks again for your help!

MrPhil · April 17, 2013

I'll try to take a look at it tonight. I'm not sure how far back I can go in osC versions... it sounds like your base is 2.2 MS2 at the latest, or possibly MS1 or even earlier.

Something written for PHP 4 (or maybe even PHP 3) needs a LOT of patching to get up to PHP 5.3 compatibility. Why don't you go ahead and install a test copy of osC 2.3.3 off to the side, try importing your database, and see just what you're lacking in your new shop? Then you can investigate whether the mods you need are available, or whether you have to port over your custom code (you did mark it and document it against just such a future need, didn't you?). The odds are high that you've overlooked something in trying to manually bring your old code up to date.

My suggestion in my previous post was to remove the explicit switch to turn register global variables OFF. That should be the default in PHP 5, and your command to turn it off might be confusing PHP.

AJRYAN · April 18, 2013

It started out as 2.2, but I kept up with the patches and all and thought at one point I applied the changes to bring it up to 2.3, but honestly all the numbers confused me and I was too busy running my business to pay attention too closely. Anyhow, I'm interested to know what you find out.

I should mention, I did change a few of the files longhand versions of Sessions to the shorthand version, but it wasn't until upgrading to php 5 that I started experiencing the problems. I'll dig into my logs a little bit if I have them back that far to see what I can.

Looking at all of that particular code confuses me. Which line(s) do you suggest I comment out?

Thanks, I really appreciate your generosity with your time!

AJRYAN · April 18, 2013

Hi MrPhil

Just wanted to let you know that unlesss you can think of quick answere/solutions, don't spend any time on this. I have come to the conclusion that as hard as it would be to start fresh with a new install, the more I hear from others like yourself it would be time better spent in the end. I just hope that I don't run into any trouble integrating my back end software which does all my order processing. Since it is an access db I suspect it shouldn't be an issue as not much will have changed.

So, Thanks again for your help You are most gracious with your time.

AJ

Can't login or checkout without cookies plus other misc problems

Recommended Posts

AJRYAN

AJRYAN

AJRYAN

MrPhil

AJRYAN

MrPhil

AJRYAN

MrPhil

AJRYAN

MrPhil

AJRYAN

AJRYAN

Archived

Browse

Activity