Guest Posted December 28, 2004 Posted December 28, 2004 I have not changed anything on my forum, but as of today my store is down and this error comes up: FATAL ERROR: register_globals is disabled in php.ini, please enable it! I can't access any part of my admin panel, and am not sure how to approach this issue.....my biggest fear is losing the contents of my store. http://www.reefnut.com/reefshop
Guest Posted December 28, 2004 Posted December 28, 2004 ask your host to reenable register_globals if they wont then you need to install the register_globals contribution. you will not lose your store. did you back it up locally by the way?
ozcsys Posted December 28, 2004 Posted December 28, 2004 I have not changed anything on my forum, but as of today my store is down and this error comes up:I can't access any part of my admin panel, and am not sure how to approach this issue.....my biggest fear is losing the contents of my store. http://www.reefnut.com/reefshop <{POST_SNAPBACK}> Chances are it was caused by a change your hosting company made. The first thing I would do is ftp a copy of all your files to your local computer if you do not have a recent copy and using phpmyadmin from your hosting control panel backup your database and also save it to your local computer. Then I would apply the register globals fix that can be found in the contribution section of the site. The Knowledge Base is a wonderful thing. Do you have a problem? Have you checked out Common Problems? There are many very useful osC Contributions Are you having trouble with a installed contribution? Have you checked out the support thread found Here BACKUP BACKUP BACKUP!!! You did backup, right??
Guest Posted December 29, 2004 Posted December 29, 2004 Thanks for the super prompt reply! They did make some changes, due to a major PHPBB hack that occurred over the holidays. I will have to make the changes mentioned and things should be fine. I had backed up the database, but used the admin directory to do so. I am now doing the phpmyadmin dump as well.
♥Vger Posted December 29, 2004 Posted December 29, 2004 If the forum software you are running is phpBB then you do need to upgrade to the very latest version. I would also suggest that in addition to the login screen for the 'admin' folder that you make the folder Password Protected via your web hosting control panel. If you have a modern enough version of MySQL then I would also recommend adding the SSLRequireSSL command to the admin folders' .htaccess file, to force it behind https. Vger
Guest Posted January 3, 2005 Posted January 3, 2005 I have noticed a fairly serious problem, since adding the fix neither I nor my customers can log onto their accounts. It does not give an error, it just reverts back to the login screen. I'm unsure exactly where to look for the problem, I have gone back over the install but don't see anything different from the install instructions. An example can be seen here: www.reefnut.com/reefshop login: [email protected] psswd: testy
♥Vger Posted January 3, 2005 Posted January 3, 2005 The first time I installed the register_globals contribution I overlooked the fact that when it gave a list of entries to be edited on one page, there were two entries in the middle of that list which were to be left alone, and I deleted them while copying and pasting the list of entries from the install file. I then got the error you did. Vger
Guest Posted January 4, 2005 Posted January 4, 2005 The first time I installed the register_globals contribution I overlooked the fact that when it gave a list of entries to be edited on one page, there were two entries in the middle of that list which were to be left alone, and I deleted them while copying and pasting the list of entries from the install file.? I then got the error you did. Vger <{POST_SNAPBACK}> Oh geez......... :'( Time to go hunting. I may have to replace the files and then reinstall the fix because I have no idea what might have been omitted. Anyone want to take a stab if it was in the admin or catalog patch most likely?
♥Vger Posted January 4, 2005 Posted January 4, 2005 /catalog/includes/functions/sessions.php /admin/includes/functions/sessions.php Sorry, but this section in both patches. Vger
Guest Posted January 4, 2005 Posted January 4, 2005 Yeah, that is where I figured it to be. I just went over all the coding and it reads as the hack instructs it to. I'm going to have to replace the files with the old backups and redo it again (tonight or tomorrow). If I end with the same problem, would it be possible to paste the code here to be reviewed?
Guest Posted January 4, 2005 Posted January 4, 2005 I'm going to take the chance that posting the code is the best way to go, I already have customers asking why they can't log in so hopefully someone can pick out the issue. I replaced the admin and catalog sessions.php with backups and redid the patch on both. I am still not able to log onto accounts. Admin Sessions - Starting at line 63 right before tep_session_start() 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) { // >>> BEGIN REGISTER_GLOBALS // -skip-? return session_register($variable); ? ? // Work-around to allow disabling of register_globals - map session variable ? ? link_session_variable($variable, true); ? ? return true; // <<< 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_globals - 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 ? // 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 variable. 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 ($sessid != '') { ? ? ? return session_id($sessid); ? ? } else { ? ? ? return session_id(); ? ? } ? } ? function tep_session_name($name = '') { ? ? if ($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 REGSTER_GLOBALS ? ? if (function_exists('session_close')) { ? ? ? return 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 ($path != '') { ? ? ? return session_save_path($path); ? ? } else { ? ? ? return session_save_path(); ? ? } ? } ?>
Guest Posted January 4, 2005 Posted January 4, 2005 Catalog Sessions - Starting also at line 63 right before tep_session_start 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 REGSITER_GLOBALS if (PHP_VERSION >= '4.0.4') { return session_write_close(); } elseif (function_exists('session_close')) { return 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'll "owe one" to anyone that can figure out what isn't clicking.
Guest Posted January 4, 2005 Posted January 4, 2005 Is anyone available to review this that has installed the register_globals contribution to compare their session files to it? I have installed it twice by replacing the files with backups, and I am having the same problems with logging into accounts.
Guest Posted January 5, 2005 Posted January 5, 2005 If no one can review the files, would someone be willing to email me their sessions.php files instead that have the register_globals contribution on them?
etepalusip Posted January 7, 2005 Posted January 7, 2005 hmmmm.....i compared both session.php files with the zipped downloads from Andreas Larsson (couldn't unzip the tar.gz, bad header?) and everything was kosher. did you happen to make any changes to the config file afa session storage? or change session usage in the administration? pete http://www.RouseArtCo.com
Guest Posted January 7, 2005 Posted January 7, 2005 No Pete, I only did the exact changes called for in the register_globals contribution(ver. 1.2.1). I'm not proficient in PHP enough to be monkeying around elsewhere (of course, apparently shouldn't be monkeying at all!)....I only added this contribution because I had no choice (host turned off r_g). This mimics when you don't have cookies enabled...where you go to log in and it simply disregards the information. When you try to log in, it just takes you right back to the catalog index page....just not logged in. :angry:
Recommended Posts
Archived
This topic is now archived and is closed to further replies.