B2B e-Commerce Knowhow (Teil 1): Sicherheit

7 Mrz

Abbildung digitale Sicherheit, Quelle: pixabay.com

Das Thema Sicherheit ist für Onlineanbieter ein Dauerbrenner. Hacker und Softwarehersteller befinden sich in einem ewigen Wettrennen. Fast im Wochentakt werden Berichte zu kritischen Sicherheitslücken in CMS- und Shop-Lösungen publik. Gerade erst wies sogar die Stiftung Warentest erneut auf ein bereits seit Monaten bekanntes Sicherheitsproblem bei einem großen Open-Source-Shopsystem hin, welches in den einzelnen Shops bis heute nicht vollständig ausgeräumt ist. Betroffen von Sicherheitslücken sind kleine Shopbetreiber ebenso wie große Player, wie der Fall Yahoo zeigt.

Sicherheit in B2B Onlineshops

Alles nicht relevant für B2B e-Commerce? Selbstverständlich sind kompromittierte Kundendaten auch im B2B e-Commerce ein Problem und müssen so gut es geht verhindert werden. Darüber hinaus hat das Thema jedoch noch eine viel größere Dimension: im Zeitalter der integrierten Systeme, in denen der Onlineshop Daten direkt in interne Firmensysteme wie ERP, CRM oder PIM einbindet, sind die Risiken von Sicherheitslücken unternehmenskritisch. Einen B2B Onlineshop als Standalone-Lösung zu betreiben ist jedoch auch keine Option. Die Frage ist also, wie schützen Sie Ihr ERP und die wichtigen Daten?

Das richtige Konzept bei der direkten Anbindung an firmeninterne Systeme

Viele Systeme bieten heute von Haus aus die Anbindung über offene Standardschnittstellen wie z.B. Web Service oder die REST API. Dies ist praktisch und erleichtert die Integration verschiedener Systeme. Der Nachteil ist jedoch, dass diese Schnittstellen auch Einfallstore für einen Angriff darstellen, wie erst kürzlich im Fall der WordPress REST API gesehen.

Eine bewährte Lösung stellt hier das Zwischenschalten einer Sicherheitsinstanz dar. So fungiert im Fall unserer Shoplösung silver.eShop der eingesetzte web.connector als Sicherheitsinstanz. Es erfolgt kein direkter Zugriff vom Onlineshop (DMZ) auf das ERP. Es werden nur  definierte Nachrichten zum ERP oder CRM übergeben. Darüber hinaus beinhaltet der Shop ein Monitoring, welches bei Unregelmäßigkeiten den Administrator informiert.

Neben fehlenden technischen Massnahmen führen oftmals konzeptionelle Fehler zu hohen Sicherheitsrisiken: bei vielen Online Shops werden Daten aus ERP oder CRM Systemen importiert. Dies kann im Falle eines Angriffs zu einem massiven Sicherheitsproblem führen. Wenn 10.000 vollständige Kundendatensätze in den Shop importiert werden, dann stellt dies bereits ein hohes Risiko dar. Allerdings unterstützen viele Standard Shops nur diese unsichere Import Variante.

Moderne und sichere Software-Plattformen

Entscheidenen Einfluss auf die Sicherheit hat die verwendete Software oder Platform. Je älter die Platform, umso kritischer ist in der Regel die Sicherheitsfrage. Es gibt zudem unterschiedliche Modelle, wie Zugriffsrechte und Sicherheit  geregelt werden.

Das in silver.eShop integrierte CMS eZ Platform setzt so z.B. auf ein rollenbasiertes Zugriffsmodell, welches den ohne Zuweisung einer entsprechenden Rolle zunächst einmal keinerlei Zugriff auf Inhalte order Funktion irgendwelcher Art gestattet. Dieses Sicherheitskonzept wird per Definition für alle Funktionen und Inhalte der Plattform genutzt.  eZ Plattform wird in sicherheitsrelevanten Bereichen wie bei Banken eingesetzt und regelmäßig überprüft.

Auch das eingesetzte Framework Symfony gilt gemeinhin als eines der modernsten und sichersten, jedoch können Entwickler auch hier schwerwiegende Fehler machen, die Hackern Tür und Tor öffnen.

Viele Anpassungen machen Systeme unsicher

Bei vielen Integrierten B2B  e-Commerce Projekten wird keine Standardlösung für B2B eingesetzt und die Entwickler passen das Produkt so stark an, dass Sicherheitslücken entstehen. Technische Restriktionen zwingen oftmals zu ungewöhnlichen Lösungen: viele an sich sichere Module werden komplett neu entwickelt, zu viele Daten aus dem ERP müssen importiert werden. Dies kann zu erheblichen Sicherheitsrisiken führen.

Häufig wird auf Basis eines VW Golf (=B2C Shop) ein LKW gebaut (=komplexer und integrierter B2B Shop). Für den Strassenverkehr unterbindet zumindest in Deutschland der TÜV oder die Dekra dies. Für Online-Shops gibt es entsprechende Prüfungen leider nicht.

Achten Sie also darauf, dass Sie eine B2B-Lösung einsetzten, die auch dafür entwickelt wurde.

Updates, Updates, Updates

Im Wettlauf von Sicherheitsexperten, Entwicklern, Hackern und Datendieben wird es zwangsläufig immer wieder Situationen geben, in denen Sicherheitslücken aufgedeckt werden. Wenn das der Fall sein sollte, dann hat ein Sicherheitsupdate oberste Priorität. Regelmäßige Sicherheitsupdates müssen zeitnah eingespielt werden. Wenn möglich, greifen Sie auf automatisierte Updates zurück.

Im Rahmen eines eZ Enterprise Vertrags erhalten Sie Sicherheits-Updates automatisch, im Gegensatz zur Open Source Version.

Zum Weiterlesen: Das Blog onlineshop-basics.de hat vor einiger Zeit in einem Artikel die verschieden Risiken für Onlineshops und mögliche Lösungsansätze informativ und übersichtlich zusammengestellt.

How-To: Tips for Performance Optimization for Content & Commerce Sites

29 Jul

Statistics from a fairly recent Comscore report show that mobile usage now represents 65 percent of all digital media time. Nonetheless mobile data plans still come with a steep price tag and are limited in data volume. At the same time modern web design for the last couple of years has been focussing on establishing a story telling approach, building brand worlds and delivering real life experiences online. This relies on an enormous amount of pictures, videos, sounds and graphics. Delivering as much high quality content as possible with the least of amount of data therefore seems to be more important than ever. Google has reacted early on by figuring in page load times as one of their many ranking factors.

Our front-end developer Marcin Krzemiński has taken the time and compiled some interesting statistics regarding file sizes and delivery times. He also shows in detail how the front-end team has optimized the performance of our Symfony based shop. They are also interesting for content sites using eZ Platform/eZ Enterprise.

Intro

As web developers we are responsible for delivering content fast, keeping in mind the balance between speed and quality of all the assets including text. As of June 2016 an average page size is 2.4 mB (2486 kB) which is quite a lot considering considering the above mentioned 65% digital media time and the still expensive mobile data plans.

  • HTML – 58 kB
  • CSS – 76 kB
  • Scripts – 402 kB
  • Fonts – 74 kB
  • Videos – 302 kB
  • Other – 11 kB
  • Images – 1522 kB (1.5MB!)

Source: http://httparchive.org/interesting.php?a=All&l=Jun%201%202016

Comparison of asset sizes over the last years

Jun 2015 – 2087 kB / http://httparchive.org/interesting.php?a=All&l=Jun%201%202015

  • HTML – 55 kB
  • CSS – 63 kB
  • Scripts – 334 kB
  • Fonts – 98 kB
  • Video – 208 kB
  • Other – 4 kB
  • Images – 1312 kB

Jun 2014 – 1783 kB / http://httparchive.org/interesting.php?a=All&l=Jun%201%202014

  • HTML – 56 kB
  • CSS – 51 kB
  • Scripts – 287 kB
  • Fonts – 62 kB
  • Other – 123 kB
  • Images – 1128 kb
all assets size in last 3 years

Average Page Size

assets size in last 3 years

Here’s a chart with last 3 years compared. As you can see every year amount of data per asset type is growing. No matter if it’s CSS, JavaScript and especially images. Look how big number is taken by images.

assets-size

Comparing those stats we can clearly see that as developers we write more CSS, JavaScript but the biggest numbers comes to images size which is about 200 kB bigger every year. These numbers show clearly how important performance optimisation is.

In order to improve performance there is a lot factors including:

  • compress (uglify) CSS and JavaScript files
  • concatenate (merge multiple into one) CSS and JavaScript files
  • reduce number of HTTP requests (CSS, JavaScript, images, Fonts, etc)
  • Gzip / deflate data over the wire
  • image optimisation

Performance optimisations for silver.eShop and eZ Platform/eZ Studio based sites

Assetic

Assetic helps us compress and concat CSS and JavaScript files. Using assetic is beneficial for reducing number of HTTP request as well as number of data that is transferred during request / response tango. Here’s how we keep it:

CSS
{% block stylesheets %}
 {% stylesheets
 'bundles/silversolutionseshop/css/style.css'
 %}
 {% endstylesheets %}
{% endblock %}

Note: We use Sass to manage our Stylesheets

JavaScript
{% block javascripts %}
 {% javascripts
 ...
 'bundles/silversolutionseshop/vendor/jquery-2.1.3.min/index.js'
 'bundles/silversolutionseshop/vendor/foundation/js/foundation/foundation.js'
 'bundles/silversolutionseshop/vendor/underscore/underscore.js'
 'bundles/silversolutionseshop/vendor/backbone/backbone.js'
 ...
 'bundles/silversolutionseshop/js/app.js'
 %}
 {% endjavascripts %}
{% endblock %}

In order to compress files we use some useful and well known NPM packages:

We keep those packages inside ezpublish/Resources/node_modules directory and here’s how our config_prod.yml file is configured:

assetic:
    filters:
        uglifycss:
            bin: '%kernel.root_dir%/Resources/node_modules/.bin/uglifycss'
            node: '%siso_eshop.nodejs%'
            apply_to: \.css$
        uglifyjs:
            bin: '%kernel.root_dir%/Resources/node_modules/.bin/uglifyjs'
            node: '%siso_eshop.nodejs%'
            apply_to: \.js$

As you may notice NPM has a dependancy of Node.js which also needs to be installed on the environment where our shop instance is running.

Related links:

Charts

Before / after assetic filters

Before and after assetic filters

Asset type Before After % saved
JavaScript 751 kB 486 kB ~35%
CSS 414 kB 325 kB ~22%

data excluding third party assets like Facebook, Olark chat, etc

Number of HTTP requests

Number of HTTP Requests saved using Assetic

For CSS number is the same since we use Sass. On the output we always have one CSS file. When it comes to JavaScript the difference is huge. Using assetic and server configuration properly we reduced number of HTTP request from 48 to 3 in production mode.

Sass and Gulp

This is not directly related to the performance topic but it’s worth to mention that we use Sass in order to keep our stylesheets nice and organised. Thanks to Gulp and some packages we are able to deliver well organised CSS including always up to date vendor prefixes.

Components driven front-end

When working on a complete redesign and rework of our front-end layer both technically and visually we had to take a lot of things into the consideration. On of them was if we should help ourselves and use one of the popular frameworks out there. We decided to go with ZURB’s Foundation for Sites which is really nice to work with. One of the nicest things about it is that we can create a custom build out of components we really need. Having this principal in mind we have extend a lot of Foundation’s components as well as created a bunch of our own which are missing. Thanks to this approach our standard design is divided into small components which is beneficial in terms of file size for client’s work. We can easily enable / disable a component when it’s required. This leads to smaller file size on the end which is beneficial from the performance perspective.

Headers

Each type of assets wheatear it’s an HTML file, JavaScript, CSS or image should have different expiration time. It means that over certain amount of time the asset should be taken from the server, not from browser cache. It can have huge impact on the site performance and that’s why it so important. For files that are not changed often you should set long expiration time. We recommend using longer expiration for files like images, fonts.

This is usually done in the VirtualHost configuration and may look like:

ExpiresActive On
ExpiresByType application/x-javascript "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType application/x-shockwave-flash "access plus 1 hour"
ExpiresByType application/shockwave-flash "access plus 1 hour"
ExpiresByType text/css "access plus 1 year"
<LocationMatch "^/var/[^/]+/storage/images/.*">
# eZ Publish appends the version number to image URL (ezimage
# datatype) so when an image is updated, its URL changes to
ExpiresActive on
ExpiresDefault "now plus 10 years"
...

Mod deflate

Apache configuration can be powered by a mode_deflate module which can be used to compress data using gzip compression before the data is send to the user. Having data compressed on the server means there is less data to transfer which results into faster page lead. Here’s how you can configure this in your Virtual Host:

AddOutputFilterByType DEFLATE text/css application/x-javascript application/javascript text/plain text/html text/xml application/xml

Using this approach we can gzip all CSS, JavaScript, HTML as well ass XML files.

Related reading:

Image optimisation

As mentioned at the beginning of this blog post images is the asset that is growing every year in terms of file size. That’s why it is super important to approach images topic the right way. In terms of project from front-end perspective there are two types of images.

First we have all static images like logo, favicon, spinners etc. To optimise these kind of images we use tools like ImageOptim (https://imageoptim.com/mac) or TinyPNG (https://tinypng.com/). If you’re not fan of these just Google for „optimise images“ or any similar search term and I bet you’ll find the right tool for your needs.

Second we have product photos. We tend to use a few image sizes for these files. In order not to load one huge file for each product or article we have couple of different configurations and serve proper files based on the view requirement. For example we might need different file for product list than for product detail page. Our team has developed and image converter tool that is using ImageMagick (http://www.imagemagick.org/script/index.php) and some .yml configuration. On top of it it’s important to set the quality for the output image. We suggest to set the quality between 60-75% in terms of JPEG compression.

Example of .yml configuration:

image_variations:
    thumb_smallest:
        reference: null
        filters:
            - { name: geometry/scalefillarea, params: [81, 61] }
            - { name: geometry/crop, params: [81, 61, 0, 0] }
    thumb_small:
        reference: null
        filters:
            - { name: resize/both, params: [150, 113] }
            - { name: background/white, params: [] }
            - { name: gravity/center, params: [] }
            - { name: extent, params: [150, 113] }
    image_zoom:
        reference: null
        filters:
            - { name: geometry/scaledownonly, params: [1600, 1200] }

Here’s how we use it in Twig:

<img src="/{{ st_imageconverter(product_image, 'thumb_small') }}" alt="Product name">

Conclusion

As an e-commerce platform manufacturer we feel responsible for delivering products that loads fast on every device. We make sure that mobile experience is as pleasant as desktop. In order to make it work as we expect we optimise performance on each layer: front-end, backend, server. Here’s what you should think about in terms front-end performance optimisation:

  • Reduce number of HTTP request by merging (concatenation) multiple files into one.
  • Reduce the number to bytes that are send over the wire by compressing files.
  • Optimise images for different views.
  • Enable gzip for CSS, JavaScript, HTML.
  • Set proper expiration time for files.

eZ Publish 5: Custom tags with Symfony services

13 Feb

How to render a custom tag for XML Text using your Symfony services and templates

One of my favorite features of eZ Publish is the ability to create nice-looking content with various nicely formatted blocks. That makes reading more interesting for the user. Due to storing content as XML it is possible to present information however you want. Along with a big number of standard tags like paragraph, image or table you are free to create your own custom tags: an embedded YouTube video, Google Maps, a sllideshare presentation, a source code block with syntax highlighting, QR-code etc. This article will show you how to use Symfony services to render custom tags.

Continue reading “eZ Publish 5: Custom tags with Symfony services” »

Neun Gründe für eZ Publish als CMS für das nächste Web-Projekt

22 Aug

Auf SitePoint hat netgen Entwickler Ivo Lukac einen interessanten Artikel veröffentlicht, der sich speziell an PHP-Entwickler richtet und ein paar interessante Fakten und Erfahrungen zusammenfasst, um bei der Auswahl eines Web-CMS eZ Publish ganz oben auf die Liste zu setzen.

Continue reading “Neun Gründe für eZ Publish als CMS für das nächste Web-Projekt” »

eZ Publish Platform 5.3 – Ventoux Release

4 Jun

eZ Publish Platform 5.3 Ventoux Release

Das Warten hat ein Ende. Die neue Version von eZ Publish – nun bereits mit dem Zusatz „Platform“ – wurde Ende Mai veröffentlicht. Waren wir im März noch verwundert über die kurze Support-Zeit für die Version 5.2 so kommt mit Version 5.3 nun endlich auch der Longterm-Support (LTS). Laut eZ Systems erwarten den Nutzer 59 neue Features, 233 Bugfixes und 69 Verbesserungen.

Continue reading “eZ Publish Platform 5.3 – Ventoux Release” »

eZ Publish Version 2012.9 – nun mit Symfony

12 Okt

Nun geht es wirklich los! Wir merken uns den 09.10.2012. eZ Publish stellt auf Symfony um! Dies ist die erste Community Version, die auf Symfony basiert. Ein Traum wird wahr!

Denkt sich wohl jetzt jeder eZ Entwickler 🙂 Also ich bin definitiv einer davon 🙂 Dazu möchte ich dem gesamten eZ Systems Team für die tolle Arbeit danken. Also ich kenne kein Team weltweit, das dies in so kurzer Zeit geschafft hätte.

Continue reading “eZ Publish Version 2012.9 – nun mit Symfony” »