Updates, back-ups en rollen

Module 6: Beheer en veiligheid · Leestijd: 11 minuten

Leerdoel: Na deze les kun je een WooCommerce-shop bijwerken en back-uppen zonder bestellingen kwijt te raken, en rechten zo verdelen dat iedereen alleen kan wat nodig is.

Kernbegrippen: grote en kleine update, databasebijwerking, uitbreidingen en compatibiliteit, sjabloonoverschrijvingen (template overrides), verouderde sjablonen, back-up vóór de update, bestellingen tussen back-up en terugzetten, HPOS-tabellen, rollen Winkelmanager (Shop manager) en Klant (Customer), minste rechten, versies tonen, xmlrpc.php

Waarom een shop anders is dan een gewone site

In de WordPress-cursus (les 7.2, 8.1 en 8.2) staat hoe je WordPress bijwerkt, hoe je back-ups maakt en hoe je terugzet. Bij een shop geldt dat allemaal, met één groot verschil: de database verandert de hele dag door. Elke bestelling, elke klant, elke voorraadwijziging en elke betaling komt erin. Bij een informatiesite verlies je met een back-up van gisteren hoogstens een bericht. Bij een shop verlies je bestellingen die al betaald zijn.

Daarom twee vuistregels voor deze les:

1. Terugzetten is bij een shop de laatste stap, niet de eerste.
2. Werk bij met een plan, niet "even tussendoor op vrijdagmiddag".

Updates van WooCommerce

WooCommerce brengt regelmatig nieuwe versies uit, met tussendoor kleine reparaties. Het versienummer heeft drie delen, zoals 11.2.2. Een verandering in het laatste getal is een kleine reparatie of beveiligingsupdate; een verandering in het eerste of tweede getal brengt nieuwe functies en soms veranderingen waar uitbreidingen of je thema op moeten aanpassen.

Drie dingen gebeuren bij een update van WooCommerce die je bij een gewone plugin minder ziet:

• Een databasebijwerking. Soms moet WooCommerce de tabellen aanpassen. Je ziet dan een melding in het beheer dat de database wordt bijgewerkt; dat loopt op de achtergrond via de geplande acties (les 7.3). Breek dat niet af en kijk bij WooCommerce > Status of het klaar is.
• Uitbreidingen moeten mee. Betaalplugins, verzendkoppelingen en boekhoudkoppelingen geven aan tot welke WooCommerce-versie ze getest zijn. In het pluginscherm zie je een waarschuwing als een uitbreiding een nieuwere versie niet noemt. Lees de wijzigingen van je betaalplugin vóór je bijwerkt: een betaalplugin die stuk gaat, betekent een shop die niet verkoopt.
• Sjabloonoverschrijvingen. Veel thema's hebben eigen kopieën van WooCommerce-sjablonen (de map woocommerce/ in het thema). Verandert WooCommerce het origineel, dan raakt de kopie verouderd. Bij WooCommerce > Status (Systeemstatus) staat onderaan bij het thema welke sjablonen het overschrijft en welke verouderd zijn. Verouderde sjablonen kunnen nieuwe velden missen of fouten geven. Werk het thema bij, of vraag de maker om een update.

Kleine updates (laatste getal) zet je bij voorkeur snel door, het liefst automatisch, omdat ze vaak beveiligingsfouten repareren. Grote updates test je eerst op staging (les 7.3), op een rustig moment, met een back-up direct vooraf.

Back-ups: wat er verdwijnt bij terugzetten

Een voorbeeld. Theehuis Example maakt elke nacht om 03.00 uur een back-up. Op dinsdag om 10.00 uur werkt de beheerder WooCommerce bij en daarna toont de productpagina een fout. Tussen 03.00 en 10.00 kwamen zes bestellingen binnen, betaald via de betaalprovider. Zet je nu de back-up van 03.00 terug, dan:

• zijn die zes bestellingen uit de database verdwenen, terwijl het geld wel bij de provider staat;
• weet de shop niet meer dat de voorraad lager is;
• krijgt de shop later misschien nog meldingen (webhooks) van de provider over bestellingen die hij niet kent.

Daarom:

• Maak een back-up direct vóór een update, niet alleen 's nachts. Dan is het gat zo klein mogelijk.
• Noteer bij terugzetten welke bestellingen na de back-up kwamen (uit de mails "Nieuwe bestelling" en het dashboard van je provider) en zet ze daarna met de hand terug, of exporteer ze vooraf.
• Zet bij voorkeur alleen de bestanden terug (de oude plugin- of themamap) als het probleem in de code zit, en laat de database staan. Een update terugdraaien kan vaak door de vorige versie van de plugin te installeren; de WordPress-cursus, les 8.2, laat zien hoe je gericht terugzet. Heeft de update de database al bijgewerkt, dan werkt de oude versie daar misschien niet meer mee: daarom eerst testen op staging.
• Back-up vaker dan bij een gewone site: een shop met de hele dag bestellingen wil minstens dagelijks, liefst vaker een database-back-up, en een kopie buiten de server (3-2-1-regel, WordPress-cursus les 8.1).

Sinds WooCommerce 8.2 staan bestellingen bij nieuwe winkels in eigen tabellen (HPOS, les 1.2), zoals wp_wc_orders. Een back-upplugin die alleen "berichten" meeneemt of tabellen op naam kiest, moet die tabellen ook pakken. Controleer bij een terugzettest (WordPress-cursus, les 8.2) of de bestellingen er echt in staan.

Bij WebOké maakt WebOké Backups elke nacht een back-up die 30 dagen bewaard wordt in een ander datacenter (DA 16.1); daarnaast kun je zelf vóór een update een back-up maken in DirectAdmin of Installatron. Bij andere hosters werkt dat vergelijkbaar; vraag na hoe vaak en hoe lang.

Rollen: wie mag wat

WooCommerce voegt twee rollen toe aan WordPress (WordPress-cursus, les 3.3):

• Klant (Customer): een klant met een account. Kan alleen zijn eigen bestellingen en gegevens zien. Geef deze rol nooit beheerrechten.
• Winkelmanager (Shop manager): kan producten, bestellingen, klanten, coupons en de instellingen van WooCommerce beheren, maar geen plugins installeren of het thema veranderen.

Voor medewerkers die bestellingen inpakken, klantvragen beantwoorden of producten invoeren, is Winkelmanager genoeg. Beheerder is alleen voor wie de techniek doet. Elke medewerker een eigen account, met tweestapsverificatie (WordPress-cursus, les 7.3); geen gedeeld account "winkel". Een winkelmanager ziet alle klantgegevens, dus haal accounts weg als iemand vertrekt.

API-sleutels (les 2.4) zijn ook een vorm van rechten: geef een koppeling alleen lezen als ze niets hoeft te schrijven, en verwijder sleutels die niet meer gebruikt worden.

Wat je shop aan iedereen laat zien

Aanvallers zoeken naar shops met een oude versie van WooCommerce of een betaalplugin met een bekend lek. WooCommerce zet standaard een regel <meta name="generator" content="WooCommerce 11.2.2"> in de broncode, en de versie zit ook achter stylesheets (?ver=). Verbergen is een kleine winst; bijwerken een grote. Een shop die netjes bij is, hoeft zich over een zichtbaar versienummer weinig zorgen te maken. Een shop die achterloopt, verraadt het.

Het bestand xmlrpc.php is een oude koppeling waarmee apps op WordPress inloggen. Het wordt veel misbruikt om wachtwoorden te raden. Gebruik je geen app of dienst die het nodig heeft, dan zet je het dicht (bij WebOké staat het standaard dicht, KB 169). Een open xmlrpc.php antwoordt op een gewone opvraging in de browser met "XML-RPC server accepts POST requests only." en status 405. Dicht geeft 403 of 404.

Samenvatting

• Een shopdatabase verandert de hele dag: terugzetten kost bestellingen die al betaald zijn.
• Kleine updates snel, grote updates eerst op staging; let op de databasebijwerking, uitbreidingen en verouderde sjablonen bij WooCommerce > Status.
• Back-up direct vóór een update en vaker dan bij een gewone site; controleer dat de bestellingstabellen meegaan.
• Medewerkers krijgen Winkelmanager, niet Beheerder; elk een eigen account met tweestapsverificatie.
• Versies verbergen helpt weinig, bijwerken veel; zet xmlrpc.php dicht als je het niet gebruikt.

Quiz

Opdracht

Opdracht A6.2: Laat je shop versies zien? Vul het adres van je shop in, je WordPress-versie (Dashboard > Updates) en je WooCommerce-versie (Plugins). Het programma vraagt de homepage en de feed op, en het bestand /wp-content/plugins/woocommerce/readme.txt (alleen de eerste 2 kB, de regel "Stable tag"). Het zoekt versienummers van WordPress en WooCommerce in de generator-regels en achter ?ver= bij de stylesheets van WooCommerce, en vraagt bij wordpress.org de nieuwste versies op. Groen als je versies de nieuwste zijn en wat zichtbaar is daarmee klopt. Oranje als alleen een kleine update openstaat, of als de versie zichtbaar is maar wel actueel. Rood als je een grote versie achterloopt, als de zichtbare versie anders is dan wat je invulde (er draait iets anders dan je denkt), of bij ongeldige invoer.

Opdracht A6.2b: Staat xmlrpc dicht? Vul het adres van je shop in en vink aan als je een app of dienst gebruikt die xmlrpc.php nodig heeft. Het programma vraagt /xmlrpc.php op met een gewone GET, zonder iets te versturen. Groen bij 401, 403, 404, 410, een doorsturing of een gewone HTML-pagina. Rood bij 405 met de tekst "XML-RPC server accepts POST requests only." zonder vinkje; oranje als je aangaf dat je het nodig hebt. Het kijkt ook of de lijst met gebruikersnamen via /wp-json/wp/v2/users openbaar is (oranje als er namen zichtbaar zijn).

Een groen vinkje betekent dat deze controle nu klopt, niet dat je shop veilig is.

Verder lezen

Stappen in een paneel gelden voor WebOké; bij andere aanbieders werkt het vergelijkbaar.

• Gratis WordPress-cursus 7.2: Updates bijhouden
• Gratis WordPress-cursus 8.1: Back-ups: wat, waar en hoe vaak
• Gratis WordPress-cursus 8.2: Terugzetten en testen
• Gratis WordPress-cursus 3.3: Gebruikers en rollen
• DirectAdmin handleiding 16.1: Welke back-ups er zijn bij WebOké
• WebOké Backups: een backup bekijken, terugzetten of downloaden
• WordPress: toegang tot xmlrpc.php lukt niet
• High Performance Order Storage (developer.woocommerce.com, Engels): https://developer.woocommerce.com/docs/features/orders/high-performance-order-storage/