Showing posts with label magento. Show all posts
Showing posts with label magento. Show all posts

Sunday, March 20, 2011

Upgrade to Magento 1.5.0.1

After reading plenty of desperate forum posts on the upgrade from 1.4.2 to 1.5.0, I was reluctant to upgrade Magento.

I went to Magento Downloader and entered in "magento-core/Mage_All_Latest" in the extension key.

First, Magento Downloader wanted to update itself. Fine.

Second, I checked for updates in Channel: Magento Community Edition, ticked off all the modules to upgrade and then waited an age for everything to finish. I logged out and logged back in, cleared the cache and to my astonishment the upgrade itself went flawlessly.

At this point, the current version of the Extended CCSave extension will no longer work. It needs a simple little work around. After performing the 1.5 update, clear all the caches, and then go to System -> Permissions -> Users. From there click on each user, don't change anything, but click on save. For some reason, saving the configuration gets things working again.


P.S. I've removed some older blog posts that apply to hopelessly out of date Magento code.

Thursday, December 16, 2010

Update to Extended_Ccsave Extension for Magento 1.4.2

I updated a few things:
  1. integration into Permissions Roles
  2. control functionality through options in System Configuration
Its not completely tested (consider it beta quality), but it works well on a couple of Magento installations.

Source Code:

extended_ccsave_0_1_3.zip

Screenshots:

View of the orders grid with purge mass action


Purge button at the top of an order


Secure (SSL) view of payment information


Configuration Options:
  • Save / Don't save the card ID (if you just want to clean out Saved CC info and not save the card id)
  • Enable the Purge Saved CC button & mass action
  • Choose which Saved CC payment information you want to delete from an order


Permissions:
  • allow view of the card id
  • allow purge of Saved CC information


Known issues:
  • after copy to app/code/local, if you visit some portion of MagentoConnect, the configuration files get clobbered
  • there's some issue with the data helper object, but it doesn't cause any errors
In the pipeline:
  • more testing
  • use MagentoConnect to package extension

Thursday, December 9, 2010

Extended_Ccsave Extension for Magento 1.4.2

It took a very long time, but here is an update to the Ccsave code.

This allows Magento to save the cid from an order, and later on purge cc info from the sales record (multiple orders supported). Unlike earlier ideas, the entire thing can go into the local code pool (app\code\local) as an extension. This should make maintenance and upgrades less of a nightmare. Although there may be problems with other extensions which also modify sales order functionality.

Its not completely tested (consider it beta quality), but it works well on my development machine. (Update: fixed a typo in one of the class names)

extended_ccsave_0_1_0.zip

Some things that are missing:
- integration into the access control lists
- more testing
- put the thing into MagentoConnect one of these days

Tuesday, October 19, 2010

Version 1.4

Wow. Its been a while. I'm starting to look at Magento version 1.4 and and enabling the CCV. Stay tuned.

Sunday, June 7, 2009

Script Package (Magento v 1.3.2.1) Updated

There are some changes in Magento over the past few months, and my old patch package for v 1.2 was obsolete. I applied my code changes for temporary-CCV-storage-plus-wipe to the latest version of Magento (v 1.3.2.1 as of this writing) and prepared a zip file (see below).

This patch allows the CCV field to be saved in encrypted form (using the saved CC payment method), and then you can wipe the sensitive payment information from the order after you process the payment information by hand.

In addition to the changes I discusses in earlier posts, I made one change two changes in the behavior. Instead of completely wiping payment information from Sales Quotes, I now delete the encrypted CC info field and leave the other payment info as is. This is the same thing I do for the Sales Orders and I think it makes more sense this way. In addition card expiration date & month is also removed for security.

Here is a link to the package for your download:

magento_1_3_2_1_update_rev_2.zip
(MD5 76d70e6fad356ed2fc5da6a6ab455ccd)

To use this, copy the files over your existing development Magento installation (assuming your installation resides in "store") and run the included SQL script for your database. You will need to clear your configuration cache in the admin dashboard for changes to take effect!

In addition, the change will only affect new orders; old orders still will not have any CCV information. So after you implement changes, create a new order with CC information and verify that the information is being stored / removed as expected.

If you have not carefully reviewed the code, you are nuts to just plunk this down on a production server. Check to make sure it works in a development environment, and read some of my previous posts to see the limitations.

Thursday, February 5, 2009

Part 4: Script Package (updated)

If you are feeling brave, I packaged up everything into one file for download:
magento_1_2_1_update_rev_3.zip
(MD5 278f36480336897676a28f6561e827ec).

This contains the updates to wipe payment information from both the sales quote and the sales order tables in the database.

For your sanity here is a list of the website files:


To use this, copy the files over your existing development Magento installation (assuming your installation resides in "store") and run the included SQL script for your database. If you have not carefully reviewed the code, you are nuts to just plunk this down on a production server. Check to make sure it works, and read some of my previous posts to see the limitations.

The CCV should show up as the alt text when hovering over the CC number in the order page. However this will only be available if a secure connection (https port 443) is detected. When viewing is not secure (http port 80) then CC information is truncated. This functionality is controlled in the ./app/design/adminhtml/default/default/template/payment/info/ccsave.phtml file.

Finally, note that this modification is still a work in progress, and I may post little updates as I make changes and time permits.

Sunday, September 28, 2008

A little salt, please?

It looks like the cc_number_enc and cc_cid_enc fields in sales_flat_quote_payment table are encrypted without using any salt. This means that the same plaintext encrypts to the same cryptext, and unfortunately cc_cid is usually only 3 digits long. This makes the encrypted data somewhat vulnerable to a known plaintext attack. This was commented on in the Magento forums as well, when discussing why the cc id is not available by default. ("This method does however provide encryption but is possible to break using a code book algorithm").

Obviously, it would be best to just not store the cc_cid_enc field in the first place, which is the default secure setting for the application. In the chance that a merchant's website is hacked and their database is compromised, they are accepting a hell of a lot of unwanted liability in storing the card id since they are not PCI compliant.

Saturday, September 27, 2008

Displaying Payment Information

So, the actual task at hand is to allow administrators to store and view credit card information (including the credit card verification code) and process the order offline with their own existing authorization system before purging that information from the database.

Unfortunately, nobody in their right mind will provide this functionality because credit card companies (for good reason) do not want web applications to store the unique number identifying the card. That is the whole point of the number -- only the card owner and the credit card authorizer should know it, and maybe the merchant can temporarily look at it in order to pass it along. In fact, using the saved credit card module is not recommended at all for a live production site!

Storing the CCV number (even in encrypted form) will prevent your application from being PCI compliant, and will most likely violate the terms of service of the merchant. Even further, it may make the merchant negligent in failing to properly secure customer data. There is a lengthy discussion at the Magento forums, and the Magento developers (rightly) don't want anything to do with enabling this functionality. If I were one of them, I wouldn't either.

Nevertheless, many merchants want this functionality because they want to use their existing order process and bolt on an e-commerce site as a online-ified order catalog. Many credit card authorizers now require that merchants supply this number, or face hefty transaction fees without it. As a little side project in my free evenings, I've worked at providing the following functionality for Magento:
  • update the existing credit card module to store the card verification number in addition to just the card number
  • allow the card verification number to be displayed on the order processing page in the administration portion of the website so the customer can be charged
  • add a button to the order processing page which purges the credit card number from the system once the data is no longer needed
  • be as secure as possible while doing the above three inherently insecure, and arguably stupid, things
If you read this and decide you want to use this less secure method of storing customer data, the responsibility is completely yours. This is intended to help developers who may want to implement this functionality (for whatever crazy reason), or who may want to use these notes as the basis of enabling some completely different functionality on the order pages. I am simplying providing some notes on how I made modifications to Magento.

It would be a far better plan to just pay for the service of on-line validation with one of the many available providers, both for the security of your customer's data and for your own piece of mind.

Warning: you are reading a blog in the internet! If you need real support or advice hire a real software engineer who knows what they are doing!

Ultimately, it is your responsibility to make appropriate use of this information. I provide no support whatsoever and no assurance that making modifications to your software will not cause even the most trival inconvience nor the most dire consequences. Finally, I do not seek to profit in any way from this work and will not accept anything at all.

Magento is confusing.

This little blog is here to chronicle my efforts to configure Magento, an open-source e-commerce web application which I think has lots of promise.

Installing Magento on a LAMP server was pretty easy, as long as you have the very most up to date software. I recommend finding a VPS so you can install what you need at will. But configuring and upgrading functionality in the administrative portion of the site is astoundingly confusing and difficult. The Magento Wiki and Magento Forums offer some degree of help, but ultimately new developers are left to untangle the ./app structure themselves. Magento suffers from spaghetti code syndrome, which I think is a result of trying to impose a very well organized object-oriented structure on top of a scripting language. I think all developers who try to do this run into this problem -- I know I have. And to change functionality unfortunately means editing a zillion pages.