Houd orders uit meerdere webshops gescheiden met een vaste werkruimte-identiteit die bij ontvangst, opslag, zoeken, workflowselectie en iedere externe actie opnieuw wordt gecontroleerd. Een uniek ordernummer is daarvoor onvoldoende: twee winkels kunnen allebei order 10047 hebben, dezelfde klantmail gebruiken of naar hetzelfde ERP schrijven.
De fout ontstaat vaak na de webhook
Veel teams controleren bij de ingang van een koppeling uit welke webshop een bericht komt. Daarna wordt de winkelcontext impliciet: een achtergrondtaak bevat alleen het ordernummer, een zoekscherm zoekt in alle winkels of een retry gebruikt de standaardconfiguratie. Juist daar kan een geldige order aan de verkeerde configuratie worden gekoppeld.
Veilige scheiding is een keteneigenschap. De werkruimte hoort bij het ontvangen event, de lokale order, de gekozen workflow, providercredentials, serviceactie en auditregel. Iedere query en achtergrondtaak gebruikt die sleutel. Een mismatch wordt niet “slim” opgelost door de eerste gevonden order te nemen; de verwerking stopt en wordt apart gezet.
Vier lagen om te controleren
- Ingang. Koppel ondertekening, endpoint en winkel-ID aan één toegestane werkruimte.
- Data. Sla winkel- en werkruimtecontext naast het externe ordernummer op en gebruik samengestelde unieke sleutels.
- Uitvoering. Geef iedere job de werkruimte mee en laad providers uitsluitend vanuit die context.
- Bediening. Scope zoekresultaten, acties, exports en AI-tools op de actieve werkruimte en bevoegde gebruiker.
Deze vier lagen maken Connect geschikt als gedeelde integratielaag zonder dat “gedeeld” hetzelfde betekent als “door elkaar”. Voor medewerkers geldt hetzelfde: ordercontext in klantenservice is pas betrouwbaar als duidelijk is uit welk merk en verkoopkanaal de order komt.
Fictief voorbeeld: hetzelfde nummer, andere klant
Fictief voorbeeld: groep Buitenblik beheert een consumentenwinkel en een zakelijke onderdelenwinkel. Beide WooCommerce-installaties hebben order 8451. Een servicemedewerker zoekt op het nummer vanuit de zakelijke werkruimte. Het systeem vindt daar één order en toont alleen die klant. De consumentenorder wordt niet als tweede suggestie getoond, ook al bestaat hij technisch in hetzelfde platform.
Later probeert een vertraagde achtergrondtaak uit de consumentenwinkel de zakelijke AFAS-configuratie te gebruiken. De werkruimtecontrole ziet dat event, order en providerinstelling niet overeenkomen. De taak gaat naar quarantaine met een technische reden en er wordt niets extern geschreven. Dit voorbeeld is fictief, maar illustreert waarom fail-closed gedrag belangrijker is dan een poging om automatisch de “waarschijnlijk juiste” configuratie te kiezen.
Tenantgrenzen-checklist voor acceptatie
| Test | Verwachte uitkomst |
|---|---|
| Gelijk ordernummer in twee winkels | Elke werkruimte toont exact één eigen order |
| Zelfde klantmail in twee merken | Geen ongevraagde profielvermenging |
| Job met verkeerde werkruimte | Stop en auditmelding, geen providercall |
| Gebruiker wisselt werkruimte | Nieuwe autorisatie en gescope data |
| AI-vraag noemt een vreemd ordernummer | Geen bestaan of klantdetails prijsgeven |
Voer deze tests niet alleen uit in de interface. Test ook imports, geplande taken, retries, exports en supporttools. Let op samengestelde indexen in de database en op cachesleutels; een cache op alleen ordernummer kan een verder correct ontwerp alsnog doorbreken. Leg bovendien vast of een centrale servicemedewerker meerdere werkruimtes bewust mag combineren en maak die bevoegdheid expliciet.
Beoordeel ook meldingen en exports vanuit het perspectief van de ontvanger. Een e-mail met alleen “order 8451 mislukt” kan bij een gedeeld beheerteam alsnog tot handelen in de verkeerde winkel leiden. Neem daarom merk, winkel en werkruimte op in taaklabels, deep links en auditregels, zonder meer persoonsgegevens te tonen dan nodig. Laat iedere deep link na openen opnieuw autoriseren; een correct opgebouwd URL-pad is geen toegangscontrole. Bij het wisselen van werkruimte moeten oude zoekresultaten, browserstaat en tijdelijke selecties worden leeggemaakt. Daarmee bescherm je niet alleen data, maar voorkom je ook de alledaagse bedieningsfout waarbij een medewerker met goede bedoelingen de juiste actie in de verkeerde winkel uitvoert.
Plan ten minste jaarlijks een negatieve autorisatietest. Laat een tester bewust identifiers van een andere werkruimte aanbieden via zoekveld, API, herhaalpoging en achtergrondtaak. Het juiste resultaat is overal hetzelfde: geen data, geen externe wijziging en een bruikbare beveiligingsmelding voor de beheerder. Zo toets je het complete pad in plaats van alleen het zichtbare scherm.
Wil je meerdere webshops veilig in één operationele omgeving beheren? Laat Yindle jouw werkruimte- en ordergrenzen toetsen.