To customize your store Prestashop , you need to create or buy a theme. These themes are more commonly called "templates".
To treat the code of these themes, Prestashop uses a template engine: Smarty, which is also used in many other CMS or applications. (PLICI, 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 template or theme Prestashop.
The procedure described below is to be executed at your own risk. We can not in any way be held responsible if your store does not work, or your theme is no longer displayed. Remember to make backup files that you modify.
Summary
1. How can you steal your template or theme Prestashop
2. Protect themselves simply stolen by a Prestashop theme. Htaccess
3. How to protect your Prestashop template display
4. Alternative
5. Conclusion
1. How can you steal your template or theme Prestashop?
We will firstly 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 display the html code of your theme, Smarty compiles various files from your template. These files can be files with the extension. "Dwt". "Php" or other.
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 ". Tpl", 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), licensors 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 view the source of our shop (with any browser), look for the line of 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:
So we know now that our Prestashop theme is at: http://www.magavenue.com/boutique/themes/magavenue/
Once it got, nothing is easier 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/header.tpl
http://www.magavenue.com/boutique/themes/magavenue/footer.tpl
It remains for us to recover files css, javascript, and different image files. That they will always be broadcast unencrypted.
Within minutes, you will have recovered a complete Prestashop theme.
What differences between recover files. Dwt a Prestashop and directly access the source?
If you access an Prestashop and you view the source page, you will only see the compiled code of the theme, ie the html. But it will be very hard to be able to assemble so to get the theme used on another shop. While in retrieving files. Dwt, you get a complete theme that you can implement on a 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 file.
Indeed if someone test 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:
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/ by the address of your shop.
If 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 from your theme, we will redirect to the index of your shop.
However the problem is not solved, this protection can be circumvented easily, so you have come to protect files. Dwt display.
3. How to protect your Prestashop template or theme of the display
As we explained in the first part, the problem that we highlight, is that the files of the templates are the basis Prestashop files. Dwt that appear clear. It should therefore come to ensure that if we access the file, it is not considered a plain file "text", but is executed by the server on which it stands.
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, redirect the user to directly access the file of your template. You must delete in order to rename the file index.tpl in index.php. The. Htaccess redirecting the user already.
If one accesses a file. Php not containing php, 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 template source.
This requires that the code runs as PHP code.
We'll add the top of each file. "Dwt" the following code:
<?
{/ If}
What does 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 point 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 sum through the use of the template by Prestashop and thus Smarty, 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 display the "<?". The display of the template can then be done properly without the added code is not a problem.
How to change it for Prestashop takes into account the file. Php instead of. Dwt?
The main issue for secure templates, was able to easily modify to accommodate PrestaShop templates with files. Php files instead. Dwt.
Indeed in every page of your shop, you have functions calling Smarty files. Dwt. It would therefore be very long for all changes one by one, not to forget, and repeat this every update.
Therefore the function between intercept and Smarty invoking Prestashop files to redirect requests to 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 we must initially modify any files. Dwt file in our theme. Php. But we must also change all the files. Dwt in the modules, do this each time you install a new module. In short it also seems very complicated to implement.
So we will redirect our request to establish a condition. This will test whether a file. Dwt exists, and if a file called. Php.
So if your theme files, are. Php Prestashop will take them into account, but it will also take into account files. Dwt in the modules, without you needing to rename them.
How to make the redirect Smarty?
We must change the Smarty.class.php file contents in the / tools / smarty / your PrestaShop store.
At line 1106, you must change the display function and add:
$ 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:
$ 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-> debug? 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-> debug? error_reporting (): error_reporting (isset ($ this-> error_reporting)
? $ This-> error_reporting: error_reporting () & ~ E_NOTICE);
[...]
And finally the function _smarty_include at line 1854 and add:
$ 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 problem highlighted above.
Aware that the approach outlined is complicated, we can execute the procedure for you. You can order this service in our shop .
4. Alternative
Another solution might 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 highlighted.
It should however 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.
- Warning your Paybox Module for Prestashop is probably not secure enough Feel free to sign up for RSS feeds do not miss any article.Nous recently had the opportunity to experience one of our customers a module with many Paybox security holes. We wanted to alert our readers ...
Items on the same subject:
Keywords:
copy , pirate theme , Prestashop , protect , template , flight













I also install prestashop modules. I want to change things templete using the example of making the rename Entreneurs I want is what I can and if so how??
thank you in advance.
Hello and congratulations for this POST.
To overcome the plundering of *. Dwt (I did not know it was possible for that matter) I installed all the files of classes and templates outside the / www / public directory server. Apparently it works. The server I use is a shared OVH.
I prestashop install WampServer wampmanager but can not execute, I seek your help :)
@ Cedric the confusion is that this is not the server that makes HTTP requests but the client.
If thou mayest dev version on your machine, the client and the server will match the same machine. Thus, an "Allow from localhost" well you open access to resources.
But if you sail on the live site, the customer is your PC and the server is another machine in a datacenter. These are then two different machines.
Thus your "Allow from localhost" as you put in your. Htaccess allows the server to make HTTP requests to itself ... which is of limited interest (as I said, it is the customer who requests HTTP).
@ Poulpillusion
Production or dev, localhost means the same thing: the machine where the script is running in production ... so this is the server itself, I do not see where there is confusion?