To customize your store Prestashop , you need to create or buy a theme. These themes are more commonly called "templates".

Code to treat these themes, Prestashop uses a template engine: Smarty, which is also used in many other CMS or applications. (Plica, Pligg, Joomla, Wordpress with a plugin, etc ...).

The problem we want to describe today is that a Prestashop template may be copied, stolen, stolen in seconds.
We will see how to protect your Prestashop template or theme.

The procedure described below is to run at your own risk. We can not in any way be held responsible if your store does not work, or your birth no longer appears. Consider making a backup of the files you modify.

Summary

1. How can you steal your template or theme Prestashop?

We will initially explain where the problem lies in the use of Smarty by Prestashop.
Be aware that any CMS that would use Smarty to how this problem would use Prestashop. This is neither a fault of Smarty, or Prestashop. It's just an awkward use.

To view the html code of your theme, Smarty compiles the various files from your template. These files can be files with the extension. "Dwt". "Php" or otherwise.
This is where the problem lies. Prestashop uses templates based files with the extension. "Dwt".

Why is this a problem?

When trying to directly access a file with the extension ". DWT", its contents are displayed in "clear".

With the code of Prestashop, we know that in a chart, there are files required to display the theme of the store (unless you have changed several parts of the code Prestashop, which sounds complicated). So we know that Prestashop files called: "index.tpl", "header.tpl", "footer.tpl", "404.tpl" etc..

We will take a concrete example, our team has a shop running Prestashop http://www.magavenue.com/boutique/
We know the style files (css) to stylize the theme, are located in a subfolder of the theme (folder / css /). It is the same for images related to the theme, or javascript files.

So just to show the source of our shop (with any browser) to look for the line indicating the address of the css file to load and we have the address where the theme used by our shop. (We could do the same with an image for example).
If we show the source of our shop we have at the very beginning of the code, the following line:

<link rel="stylesheet" type="text/css" href="/boutique/themes/magavenue/css/global.css" media="all" />

So we know now that our Prestashop theme is at: http://www.magavenue.com/boutique/themes/magavenue/

Once it got, it's easy to retrieve files from the theme of our shop. Just add the different file names following this address.
For example:

http://www.magavenue.com/boutique/themes/magavenue/404.tpl
http://www.magavenue.com/boutique/themes/magavenue/header.tpl
http://www.magavenue.com/boutique/themes/magavenue/footer.tpl

It only remains for us to recover files css, javascript, and different image files. That they will still be broadcast in the clear.
Within minutes, you have collected a complete theme Prestashop.

What's the difference between recovering the files. DWT of a Prestashop and access the source directly?

If you go to a shop Prestashop and you view the source page, you will see only the compiled code of the theme, ie the html. But it will be very hard to be able to assemble so as to obtain the theme used on another shop. While in retrieving files. DWT, you get a complete theme that you can set up a shop on Prestashop, to generate the html code easily.

2. Protect themselves simply stolen by a Prestashop theme. Htaccess

One way to prevent theft of your Prestashop template is to use a. Htaccess.
Indeed, if someone tries to directly access different files. DWT as we have shown above, it is redirected to another page (the index of your website for example).
To do this, you must create a. Htaccess file in your theme and then re-enter the following code:

RewriteEngine on
RewriteCond% {HTTP_REFERER}! Http://magavenue.com/boutique/ ^ .* $ [NC]
RewriteCond% {HTTP_REFERER}! Http://magavenue.com/boutique ^ $ [NC]
RewriteCond% {HTTP_REFERER}! Http://www.magavenue.com/boutique/ ^ .* $ [NC]
RewriteCond% {HTTP_REFERER}! Http://www.magavenue.com/boutique ^ $ [NC]
RewriteRule .* \. (Jpg | jpeg | gif | png | bmp | swf | dwt | css) $ http://www.magavenue.com/boutique/ [R, NC]

You will of course understand, need to replace http://www.magavenue.com/boutique/ with the address of your shop.
If the images, or the theme of your PrestaShop store no longer displayed, then you have probably entered the wrong address at this stage.

The. Htaccess is not reliable, and your Prestashop template can still be stolen.

You set up a first barrier. If we try to directly access a file in your theme, we will redirect to the index of your shop.
However the problem is not solved, this protection can be overcome easily, so you have come to protect files. DWT of the display.

3. How to protect Prestashop theme or template of the display

As we explained in the first part, the problem that we highlight, is that the files of templates Prestashop form the basis of. Dwt that appear clear. It should therefore come to ensure that if we access the file, it is not considered as a single file "text", but is executed by the server on which it is located.
Should be more clearly so that the template files or files with the extension. "Php", so that they can not be displayed directly, but executed.

To protect our Prestashop theme of flight, so we will change all our files in the file of our theme. By changing their extensions. "Dwt" to ". Php". There is already an index.php file, to redirect the user direct access to the file of your template. So you must remove in order to rename the file index.tpl in index.php. The. Htaccess redirect the user already.

If you access a file. Php php does not contain, it will display the template code anyway.
Indeed, if we access directly to a file. Dwt renamed. Php, we will always have access to the source of the template.
This requires that the code runs as PHP code.
We will therefore add to the top of each file. "Dwt" code:

{If $ magavenueblog == 1}
<?
{/ If}

What is this code?

If we access a file directly containing this code, the "{if $ magavenueblog == 1}" is treated as plain text and simple, it will not be interpreted as PHP.
By cons from the time where the interpreter will fall on the "<?", the file will be interpreted as PHP, and an error will occur. Indeed the code "{/ if}" is not a valid statement in PHP. It will no longer be possible to display the template code directly.

By cons, if we are part of the template by using the Smarty Prestashop and therefore, when the interpreter arrives on "{if $ magavenueblog == 1}", it will look if there is a theme in the variable $ magavenueblog. It does not exist it will not show the "<?". The display of the template can then be conducted properly, without the added code is too much trouble.

How do I change Prestashop so that it takes into account the file. Php instead of. Dwt?

The main problem to secure the templates, was able to easily modify to accommodate PrestaShop templates with files. Php instead of. Dwt.
Indeed, in every page of your shop, you call functions Smarty files. Dwt. It would be very long all the changes one by one, not to forget, and repeat this for each update.
Therefore the function between intercept and Prestashop calling Smarty files to redirect requests for a file. DWT to a file. Php.

Should I modify the. Dwt contained in the modules and other Prestashop?

Another problem in our solution is that you initially change all the. Dwt file in our theme. Php. But we must also change all the. Dwt contained in the modules, do this each time you install a new module. In short it seems also very complicated to implement.

So we will redirect our request to establish a condition. This will test if a. Dwt exists, and if not call a. Php.
Thus, if the files in your theme are. Php Prestashop will take them into account, but it will also take into account, the. Dwt contained in the modules, but you need to rename them.

How to redirect Smarty?

We must change the Smarty.class.php file in the file / tools / smarty / your PrestaShop store.

In line 1106, you must change the display function and add:

if (file_exists ($ resource_name))
$ Resource_name = substr ($ resource_name, 0, -4).. 'Php';

Before:

function display ($ resource_name, $ cache_id = null, $ compile_id = null)

{

$ This-> currentTemplate = substr (basename ($ resource_name), 0, -4);

$ This-> fetch ($ resource_name, $ cache_id, $ compile_id, true);

}

After

function display ($ resource_name, $ cache_id = null, $ compile_id = null)

{

if (file_exists ($ resource_name))

$ Resource_name = substr ($ resource_name, 0, -4).. 'Php';

$ This-> currentTemplate = substr (basename ($ resource_name), 0, -4);

$ This-> fetch ($ resource_name, $ cache_id, $ compile_id, true);

}

We must then modify the function to fetch the line 1123 and add:

if (file_exists ($ resource_name))
$ Resource_name = substr ($ resource_name, 0, -4).. 'Php';

Before:

function fetch ($ resource_name, $ cache_id = null, $ compile_id = null, $ display = false)

{

static $ _cache_info = array ();

_smarty_old_error_level $ = $ This-> debugging? error_reporting (): error_reporting (isset ($ this-> error_reporting)
? $ This-> error_reporting: error_reporting () & ~ E_NOTICE);
[...]

After:

function fetch ($ resource_name, $ cache_id = null, $ compile_id = null, $ display = false)

{

static $ _cache_info = array ();

if (file_exists ($ resource_name))

$ Resource_name = substr ($ resource_name, 0, -4).. 'Php';

_smarty_old_error_level $ = $ This-> debugging? error_reporting (): error_reporting (isset ($ this-> error_reporting)
? $ This-> error_reporting: error_reporting () & ~ E_NOTICE);
[...]

And finally the function _smarty_include line 1854 and add:

if (file_exists ($ params ['smarty_include_tpl_file']))
$ Params ['smarty_include_tpl_file'] = substr ($ params ['smarty_include_tpl_file'], 0, -4).. 'Php';

Before:

_smarty_include function ($ params)

{

$ Backup = $ this-> currentTemplate;

$ This-> currentTemplate = substr (basename ($ params ['smarty_include_tpl_file']), 0, -4);
[...]

After:

_smarty_include function ($ params)

{

$ Backup = $ this-> currentTemplate;

if (file_exists ($ params ['smarty_include_tpl_file']))

$ Params ['smarty_include_tpl_file'] = substr ($ params ['smarty_include_tpl_file'], 0, -4).. 'Php';

$ This-> currentTemplate = substr (basename ($ params ['smarty_include_tpl_file']), 0, -4);
[...]

Your template is protected from the problems identified above.

Aware that the approach described is complicated, we can perform the procedure for you. You can order this service in our shop .

4. Alternative

Another solution could be to move the folders containing templates, in a part of the server is not accessible via the Internet. But this can be done only by people with a server able to do this (for example, a dedicated server). It will then edit the configuration file for Smarty, and give the address of the folder to access the theme.

5. Conclusion

These solutions can protect your template or theme of your shop, the problem we have identified.
We must be aware that this does not mean that your template is completely secure. You will not be protected if you have:

  • a flaw in your server
  • made a mistake
  • or if there is a problem not yet updated.

    Articles on this topic:

  1. Warning your Paybox module for Prestashop may not be secure enough Feel free to sign up for RSS to not miss any article.Nous recently had the opportunity to experience one of our customers with many module Paybox security breaches. We wanted to alert our readers ...

35 comments why not leave yours?

We will not support for comments for a technical problem with one of our modules. Thank you contact us directly with our contact form !

@ Cedric the confusion is that this is not the server that makes HTTP requests, but the client.

If you are hosting the dev version on your machine, the client and the server will match the same machine. Thus, an "Allow from localhost" access to open many resources.

But if you sail on the live site, the customer is your PC and the server is another machine in a datacenter. The question then two different machines.

So your "Allow from localhost" as you put in your. Htaccess allows the server to make HTTP requests to itself ... which is of limited value (as I said, it is the customer who requests HTTP).

poulpillusion August 29, 2011 at 17 h 17 min

@ Poulpillusion

Production or dev, localhost means the same thing: the machine where the script is running in production ... so it is the server itself, I do not see where there is confusion?

Cédric August 29, 2011 53 min to 6 h

@ VitamineSeb: where FilesMatch directives (who had jumped in my first comment)

The prohibited They allow access to files. Dwt, which are anyway only loaded by Smarty, and never by an HTTP request. They should never be services by Apache, and that's what these guidelines. They have also been integrated into the dev version of prestashop (see file themes / .htaccess), but not in the stable releases.

I also think your "Allow from localhost" is useless on a live site, and may t'induire error if you develop a local version.

poulpillusion August 29, 2011 at 0 h 02 min

@ Poulpillusion 'Deny from all' will prevent the display of the template at all.

Personally I chose a htaccess:

deny from all
allow from localhost

Can not access the file or files and prestashop continue to read and can display the template as before ;)

VitamineSeb August 25, 2011 at 11 am 38 min

Indeed, the images are often copied ... attention to copyright ... interesting to implement. Htaccess

Ergonomics website 5 July 2011 to 22 h 36 min

Write a review