Jump to content

chadcloman

Members
  • Content count

    290
  • Joined

  • Last visited

  • Days Won

    6

chadcloman last won the day on September 5 2010

chadcloman had the most liked content!

Profile Information

Recent Profile Visitors

8,872 profile views
  1. [Note: I'm using an older version of osCommerce. I assume this has been fixed in newer versions.] For some time I've noticed that if I have a sufficiently complicated item description, the osCommerce item editor will not display it and just show a blank text area. In the past I've worked around this by adding the description directly to the database. Once the item description is set, it works fine, but if I revisit the editor it will be blank, and if I subsequently save the item then the description will be lost and written to the database as a blank field. Today I decided to investigate. WHY THIS IS HAPPENING: The htmlspecialchars() PHP function is used to make an output string safe, and you use it pretty much whenever you write text to a web page, and especially if the text comes from somewhere other than string literals in the source code (e.g., user input, database). One feature of htmlspecialchars() is that it understands character encodings and will output an empty string if it encounters a value that's not part of the expected encoding scheme. It does this silently, and the caller has no way of knowing it happened. Things were working reasonably well until PHP 5.4.0 was released. At that time, the default encoding used by htmlspecialchars() was changed from ISO-8859-1 to UTF-8. Apparently the osCommerce editor's item description is not encoded with UTF-8, and this broke htmlspecialchars() -- but only if the description included special characters of some sort. Instead of returning the "safe" version of the character string, htmlspecialchars() would instead return an empty string. This is the cause of the osCommerce error. The problem was noticed and quickly changed by the PHP developers. In PHP 5.6.0, the htmlspecialchars() default encoding was changed to be the default encoding defined in the 'default_charset' configuration variable. So the problem will most likely only occur if you're using PHP 5.4 or 5.5. More information about this issue can be found on the htmlspecialchars() manual page. HOW TO FIX THE PROBLEM: Method #1: Specify the correct encoding. This can be done by editing the source code to replace any use of htmlspecialchars(<string>); with htmlspecialchars(<string>, ENT_COMPAT, get_cfg_var('default_charset')); Note that if you wish to use a specific character encoding, you can replace the 'get_cfg_var(...)' part with that encoding enclosed in quotes (e.g., "ISO-8859-1"). This is what I use and is what I recommend. Method #2: Tell the function to ignore stuff it doesn't understand. This can be done by editing the source code to replace any use of htmlspecialchars(<string>); with one of the following htmlspecialchars(<string>, ENT_SUBSTITUTE); // Substitutes a Unicode U+FFFD character htmlspecialchars(<string>, ENT_IGNORE); // Ignores and discards bad characters - NOT RECOMMENDED The last one, ENT_IGNORE, is not recommended because it can cause security issues. When making these changes, you should modify every instance of htmlspecialchars() in the source. But if you wish to simply fix the item editor, here are the files that need to be changed: admin/includes/functions/database.php admin/includes/functions/general.php admin/configuration.php That's it. Hope this helps.
  2. chadcloman

    Paypal IPNs have stopped working for us yesterday

    Thank you , thank you, thank you for figuring out that it was a trim issue. Spent hours on this problem for a (non-osCommerce) script that I maintain. EDIT: In my case it appears to be an extra newline, not padded spaces. But trim() works either way.
  3. Found this out today, fortunately before too many orders were missed, and thought I'd post it here. I changed some of the session settings and ran into a problem with Authorize.net processing. What would happen is that the user would go to the Authorize.net screen, enter the data, then would get logged out and be returned to the store's login page. The order would not be finalized by checkout_process.php, and there would be no record of the order in osCommerce. But the customer would be charged by Authorize.net. Turned out that, because of the way the Authorize.net SIM payment module works, certain session settings break the order processing I fixed the problem by changing these session values to false in the osCommerce admin pages: Check SSL Session ID Check IP Address Check User Agent Not totally sure if "Check User Agent" absolutely has to be false, but it's working now and I don't want to break it again.
  4. chadcloman

    IP trap Version 3 released

    For those having problems making version 4 work (especially with whitelists), here are the fixes: In catalog/personal/index.php, lines 9, 24, and 40: Change the single quotes surrounding the filename to double quotes Put a dollar sign ("$") in front of DOCUMENT_ROOT (change DOCUMENT_ROOT to $DOCUMENT_ROOT) Change "../../" to "catalog/" (where "catalog" is the directory that your store is in -- if your store is in the root directory, then just delete the "../../") In catalog/includes/secret.php, line 11: Change the single quotes surrounding the filename to double quotes Put a dollar sign ("$") in front of DOCUMENT_ROOT (change DOCUMENT_ROOT to $DOCUMENT_ROOT) Change "../" to "catalog/" (where "catalog" is the directory that your store is in -- if your store is in the root directory, then just delete the "../") Also, there is a problem if the very last entry in the whitelist doesn't have a trailing newline. That entry is skipped. So when you add IPs to the whitelist, be sure the last line has a newline. For better security, I recommend creating an .htaccess file in the "catalog/banned" directory with the following line: Deny from all
  5. chadcloman

    New MasterCard and Discover Processing Requirements

    The partial approval requirement is what worries me. The version of osCommerce that I'm using (2.2rc2a) does not handle partial payments, at least not that I'm aware of. Is this something that's in a later version (or is in the works)?
×