There have been reports of the Sage Pay Server payment module not working and failing with the following error message:
Unable to redirect to Vendor’s web site. The Vendor failed to provide a RedirectionURL
The problem was introduced with v2.3.0 where tep_href_link() returns HTML formated URLs and the RedirectionURL value containing & instead of & in the URL.
This has been fixed in v1.2 of the payment module and can be downloaded here:
This will also be included in osCommerce Online Merchant v2.3.4.
If you’re using an earlier version of osCommerce Online Merchant before v2.2 Release Candidate 1 (July 2007), please make sure the “extras” directory is not publicly accessible on the server if it has been copied over. This directory is not part of the installation and had to be separately copied over if upgrades were being performed from even earlier releases.
A list of affected servers has recently been published that unfortunately still have the “extras” directory publicly accessible.
If left on the server, the scripts in the directory may allow any file on the server to be read due to an insecure directory listing implementation.
More information at:
osCommerce Online Merchant v2.3.2 has just been released which improves the customer password forgotten routine and generation of random strings.
Previously, when the customer requested a new password, their password was instantly updated to a random string and was e-mailed to the customer. The length of the random password was based on ENTRY_PASSWORD_MIN_LENGTH which by default is 5 characters long.
Although it is strongly recommended to use longer passwords, the real problem was that the random string generated for the new password was not random enough to use in a secure manner due to a weak seeding of the random number generator.
This has now been improved by using Phpass' get_random_bytes() method to generate cryptographically secure random strings based on /dev/urandom, openssl_random_pseudo_bytes(), and mcrypt_create_iv() where available. Phpass was introduced in osCommerce Online Merchant v2.3.0 to replace the older password hashing algorithm.
Also new to the customer password forgotten routine is that the customers password is no longer instantly updated with a random string, but a personal link is generated and e-mailed to the customer and gives them 24 hours to update their own password. Customers can ignore the e-mail if they did not request a new password themselves, and can continue to use their existing password if they have remembered it. New password requests are protected by an Action Recorder module to limit requests to once every 5 minutes (this is configurable).
Once the customer has updated their password via their personal link, they are redirected to the login page to login using their new password. There are advantages and disadvantages to automatically authenticate the customer as soon as they’ve updated their password or to make them login again. We chose a manual login due to technical issues:
- We did not want to duplicate the core login code as it would have missed on Add-On or custom changes made to the login routine.
- We did not want to have an automatic redirect page pointing to login.php with the customers e-mail address and password in plain-text within hidden fields in a form.
The advantage to a manual login is it gives the customer an opportunity to save their new credentials in their browsers password management feature.
We wanted to make updating to these improvements as easy as possible and have placed these improvements in v2.3.2 only. Additional bug fixes will soon arrive in v2.3.3, and a PHP 5.4 compatible release will arrive shortly after in v2.4.
A new discussion channel has been added to the forum to discuss upgrades from earlier versions.
Lots has happened during the week! Here is a summary of some of the events:
- UTF-8 issues: Laurent discovered that PHP does not report errors in UTF-8 and brings problems to our custom ErrorHandler class which logs errors in an SQLite3 database and is retrieved via JSON. Both SQLite3 and JSON require valid UTF-8 sequences. This problem can arise if PHP reports errors in a foreign language. The bug report is #259. A solution is still being looked into.
- Some reports of MYSQL_ATTR_INIT_COMMAND being undefined have been submitted. This is a PHP v5.3.0 bug that only affects Windows. No work around will be provided so the solution is to upgrade the WAMP solution being used to a version using PHP v5.3.1 or later.
- Our Bug Reporter now has separate categories for OSCOM v2.x and v3.x.
- SessionAbstract now checks if the supplied session ID in GET/POST/COOKIE exists. If it does not exist, it ignores the supplied value and generates a new session ID to use.
- Support for Site Domains will be introduced in v3.0.2, which allows each Site to have its own http server and cookie domain settings. For example, this allows Shop and Admin to be called as:
http://admin.oscommerce.com/index.php (?Admin is not needed)
Sites that require cookies to be shared must have proper cookie domain settings (eg, “.oscommerce.com”).
OSCOM::getDefaultSite() now checks against $_SERVER[‘SERVER_NAME’] to load the appropriate Site and default Site Application.
OSCOM::getLink() automatically generates correctly formed URLs to Sites with different domains.
- Some reports of OSCOM v3.0 not working with PHP v6.0-dev have been submitted. This is due to an old version of PHP v6.0-dev being used that does not support namespaces. According to this LWN article from March 2010, work on PHP v6.0-dev has been pushed to a separate branch and is no longer part of the main PHP development path. I downloaded the latest trunk version of PHP from their subversion development repository, compiled it, installed it, ran OSCOM v3.0.1 on it, and can happily report that it works superbly without any errors being reported! The version PHP reported is PHP v5.3.99-dev / Zend v2.4.0 and will be PHP v5.4 once released. This version finally removes deprecated functions and settings that still exist in PHP v5.3.
- Work on a Phing build script has been started to build, test (PHPUnit), and package (ZIP) OSCOM download releases. Ultimately this will automatically build full download release packages, manual upgrade packages, and CoreUpdate Phar update packages.
- The list of files and source code changes from v3.0.1 leading up to v3.0.2 can be viewed here.
One of the great new features of our framework is the ability to perform upgrades via the Admin Dashboard, where update packages are listed, modified files can be seen, and upgrades can be performed at the click of a button.
Unfortunately not everyone will get to experience how great this can work with the v3.0.1 release as CoreUpdate in v3.0 can detect incorrect file permissions under certain server environments during an upgrade procedure, and reports back of a successful upgrade when no files were updated at all. This affects you if after the upgrade to v3.0.1, v3.0.1 is still listed as an available update package to upgrade to.
Those affected can download the manual v3.0-to-v3.0.1 upgrade package to extract and copy over to their installation via FTP. Although also an easy procedure, this is not the kind of experience we want to share with you when upgrading.
We’ve taken this opportunity to improve CoreUpdate in v3.0.1 and are extremely pleased with how it now handles upgrades.
CoreUpdate utilizes Phar to download signed phar update packages from our server, to list the contents of the update package to show which files are going to be modified, and to extract the files over the installation to perform the upgrade.
It sounds easy, but when file permissions become an issue, Phar panics and produces a fatal error that can stop further processing of PHP code.
We’ve improved CoreUpdate to better handle file permissions and situations where Phar can produce unexpected errors. Instead of just extracting files in an update package to the installation, CoreUpdate now tracks which files are going to be modified, backs those files up, extracts the updated files in place, and if all files have been successfully updated, goes back and deletes the older files no longer necessary. If an unexpected error occurs, CoreUpdate deletes the files that have been extracted and restores the original files automatically reverting to the original state.
There are a lot of server environments and file permissions CoreUpdate has to handle, and we’re striving to make it “just work” to provide the best user experience as possible.
CoreUpdate is still in its infancy. We imagine that update packages can first be tried before an actual upgrade is performed, to test and make sure customizations continue to function as normal in a live environment. Phar allows this and we look forward to taking advantage of its full feature set to make this possible.
We know that feeling of pushing an “Upgrade” button and want to turn that fear into a pleasurable moment. We enjoy the challenges working with the strictest levels of error reporting to richen our creativity and produce even better code.
And we can’t wait to bring CoreUpdate to Add-Ons!