Are you still vulnerable after applying a Magento security patch?

Screenshot of the popin displayed in your back-office which notify about security patches

I salute Magento and all its partners for the notifications about security issues found.
Magento notify you in the back-office with some notifications.

These patchs are all available from the Magento download page and are distributed under a .sh file. You have just to run mypatchfile.sh and that’s it, you are secured!?

NO! Continue reading “Are you still vulnerable after applying a Magento security patch?”

Cancel commits on Magento core files with subversion hooks

As a best practice, it is not recommended to update Magento core files. This can be done by Magento overloading mechanism

This morning, an old colleague of mine mentioned that a developer committed some updates in the app/code/core files.

This could be blocked by subversions hooks scripts

What is a subversion hook?

Introduction to subversions hooks: the hook events

Subversion implement a hook mechanism which allows to call some externals scripts on some repository events. This functionality allows you to customize your repository work-flow. The most common hook usages are:

  • Sending email notification (on each commit, when a tag is done, …)
  • Control access to repository (when locking files, …)

List of available hooks events can be found in the subversion documentation

Hook event we’ll use to control our commit must be executed before transaction is completed: the pre-commit hook

What subversion does on a subversion hook event?

On this predefined event list, Subversion will check if there is an executable script in the hooks folder of your subversion repository with the name of the event

If yes, subversion user will call this script with some arguments. Arguments list sent to this script depends on the hook event. For example, for the pre-commit hook script, arguments are:

  • Full path to repository involved
  • Current transaction number
  • With these arguments, you can do what you want within, especially calling all the administrative subversion commands:

    • svnadmin
    • svnlook

    Setting up a subversion hook which cancels the transaction in case core files are updated

    Here’s an example of the script you can use as pre-commit hook for Magento projects

    #!/bin/bash
    ##################################
    # render more readable parameters
    ##################################
    REPOS="$1"
    TXN="$2"
    ################
    # configuration 
    ################
    # path to svnlook script
    SVNLOOK=/usr/bin/svnlook
    #############
    # librairies
    #############
    # a method to send message to client and end transaction
    show_error_message() {
        echo $1 1>&2;
        exit $2;
    }
    ###############################
    # run
    ###############################
    # fetch the account user from the current transaction informations
    AUTHOR=`$SVNLOOK author -t "$TXN" "$REPOS"`
    
    # check if we do not updating file in core files
    $SVNLOOK changed -t "$TXN" "$REPOS" | grep "^U \+app/code/core" > /dev/null
    if test $? -eq 0 
    then 
        show_error_message "$AUTHOR, You cannot update Magento core files" 2
    fi
    

    This script will look for files involved in current transaction with the svnlook script and look for path app/code/core in the output answer. (this svnlook command lists all files and their state in a transaction). If we find something matching, we send a message on the STDERR (STDERR will be sent to subversion client) and exit script with a non 0 error code, which will cancel the transaction and so block the commit

    To use it, just copy this script content in a hooks/pre-commit file of your repository folder and make it executable by the system

    Conclusion about usage of hooks on Magento scripts

    No more reasons to leave developers committing app/code/core files with this script!

    But you can extend hooks to do many other things on your repository: block Magento core files commit, block update on tagged versions, notifications of branch creation, block commit of PHP files which contains parse errors, etc…

    Do you use these events on your Magento repositories?

    Update Magento page structure by overloading the layout content

    There are many ways to update Magento page structure content: all lead to the same thing, a custom page, but not in the same ways. Each method has its own advantages and drawbacks.

    Within this topic we’ll overview overloading page structure by overloading native Magento layout files

    How to overload Magento page structure using loading mechanism ?

    All this process is based upon template loading mechanism which I explained before:

    • You define your design through back-office
    • You copy the Magento layout file to update in the layout folder of your custom design folder

    For example, if you want to overload Magento customer account page content, you can do it by copying the original customer.xml into your custompackage layout folder

    When Magento will be looking for the customer.xml file it will find yours before the default one: this is yours which will be used instead of the native one

    Very easy and quick method to update Magento layout…

    Advantages of updating Magento page content by overloading native layouts

    You are totally independent of the native page structure

    With this method, you are totally independent of the existing page structure: you can do what you want inside

    Quick way to update page structure content

    This is also the quickest way to update page structure: you’ve found which layout file contains the element you want to update, you just have to copy it and update it. No layout update definition, no new module to load to embed some update

    Code more clear

    Almost everybody knows now which files describe Magento page structure. Using this method makes the code reading easier: no many layout update to find which are involved in a page, this is our layout copy which is involved in your page. There are also less treatments to build your page because there are less files to parse to build your page

    Drawback of updating Magento page content by overloading native layouts

    Difficult to capitalize

    Your new layout page structure depends on the design applied. Even if you can add files of some specific packages in a Magento connect package, it’ll only work if the Magento has configured the same design: force users to use a specific value of design is a difficult choice and will make all other modules installation harder

    Difficult to maintain

    Creating a fork makes it more difficult to take advantage of developments that may contain Magento updates, and generally the community.

    Do you use this kind of method to overload Magento page structure?

    Magento tutorial: how to overload a Varien class?

    If you have read my previous post about Magento overloading mechanism, you’ll see that there is two existing mechanisms to overload classes in Magento

    But these two mechanisms are only available for classes which are instantiated.

    Many of Varien classes are not loaded directly through a new. So how we can overload them?

    If class is only used when using extends, we have only one way to overload it’s content: the passive overload

    This mechanism is based upon the auto-loading mechanism embedded with Magento

    • Loading first from app/code/local folder
    • Then first look for classes in app/code/community
    • If always not found, look for the app/code/core folder
    • Always not found? look for lib folder

    The only way you can use to overload a Varien class is to use this mechanism to provide your own functionalities by copying Varien class in app/code/community or app/code/local folder (we do not touch at the app/code/core)

    By using this method, this is your class which will be loaded, instead of Varien one

    Magento Overloading mecanisms

    Magento is a really rich software application. However, its management rules may be diffrent from your own management.
    Varien, Magento’s editor, forecasted this case and offers 2 overloading methods of its native working to allow you to adapt the solution to your specificities.

    One of these mechanism is a passive overloading, whether the other needs your intervention.

    Passive overloading

    This overloading mechanism is closely related to Magentos’s autoload management.

    Source code organization in Magento & Autoload

    Reminder of source code organization in Magento

    For recall, autoload is a mechanism born with PHP5 which embeds a dynamic class loader manager.
    That is to say, if a class was never loaded, it’s the __autoload method which will search and find in which source if the required class exists. This method may be redefined to adapt your needs.

    Magento’s source code is organized according to four repositories

    • Libraries. That’s where you will find, in particular, the Zend Framework which is a referencial for librairies in Magento
    • Magento’s core. It’s in the folder app/code/core
    • Community enrichment. They’re in the folder app/code/community
    • Local enrichment. They’re in the folder app/code/local


    So these four folders are : lib, app/code/core, app/code/community, app/code/local

    Magento defines its own autoloader in the Autoload class, located in the folder lib/Varien.

    This autoloader will first look for classes in app/code/local, and then if it doesn’t find them, in app/code/community, and lastly in app/code/core if it still hasn’t found the right file. After all, if the file is still not found, it will be searched in the libs.

    Working of passive overloading in Magento

    Everything bases on this autoloader’s working : it’s therefore possible, by acting on the autoload priorities, to make a preferential choice about a local adaptation (which would be in app/code/local), rather than the native file which is in app/code/core.

    This requires however that the local adaptation contains fully all the methods that are in the overloaded class.

    An example of this kind of overloading is the file app/code/core/Zend/Mime.php which is used instead of the file lib/Zend/Mime.php.

    Active overloading

    This overloading mechanism is related to instanciation mechanism used in Magento.

    Instanciation mechanism in Magento

    For recall, Magento uses three generic methods to load its classes :

    Mage::getModel() (and Mage::getSingleton)
    Mage::getBlockSingleton
    Mage::helper()

    These methods will be in charge of determining the name of the class to be loaded.

    What happens in case of two active overloading of the same class ?

    Magento’s rules manager is confused and doesn’t know which class it has to load anymore. In this case you will surely note stange behaviours.

    It’s then higly recommanded that you never fall in this case, and be therefore most carefull when you install modules from the community which might already overload the same objects as you.

    Which overloading mechanism choose ?

    It depends on what you wish to implement, and also on the type of class you wish to overload. Abstract classes for example cannot be overloaded with the active overloading mechanism, because they don’t have a real instanciation. To overload them, you have to choose passive overloading. With active overloading you don’t have to rewrite the full content of the overloaded class, unlike in the passive overloading case.
    You also will have less compelling maintenance of your source code referring to this overloading concerning Magento upgrades.

    This loading mechanism break also a common bias we can heard: “community folder is only for sources code coming from magento connect”. In this case, if we put our own development only in local folder, we avoid usage of passive overload. is it really the thing you wants?