In Mendix is goede validatie van gegevens essentieel voor zowel de beveiliging van uw applicatie als de integriteit van uw data. Dit artikel gaat over veelgemaakte fouten bij het valideren van entiteiten en laat drie degelijke manieren zien om uw applicatie te beveiligen.

Rond Mendix-security zijn er veel onderwerpen. Dit artikel richt zich op het belang van het valideren van entiteiten. We nemen een eenvoudig voorbeeld; in echte applicaties zijn deze situaties vaak complexer.

Stel, we hebben een entiteit Animal en we willen alleen objecten toestaan waarvan de naam met een hoofdletter “L” begint. We laten Mendix de overzichtspagina’s genereren. Als we dit draaien, is er nog geen enkele validatie. Dus voegen we een validatiemicroflow toe. Wanneer we een dier proberen toe te voegen waarvan de naam niet met een “L” begint, krijgen we een nette foutmelding.

De applicatie lijkt daarmee beveiligd: alleen dieren met een naam die met een “L” begint zijn toegestaan. Maar is dat zo? Via de client-API van Mendix kunnen we ook objecten aanmaken of bewerken. Dat proberen we in de console van de browser:

mx.data.create({
  entity: "Part2.Animal",
  callback: function (mxObject) {
    mxObject.set("StartWithL", "Elephant");
    mx.data.commit({
      mxobj: mxObject,
      callback: function () {
        console.log("Object committed");
      },
      error: function (error) {
        console.log("Could not commit object:", error);
      },
    });
  },
  error: function (error) {
    console.log("Could not create object:", error);
  },
});

We hebben nu een object aangemaakt met een dier dat niet met een “L” begint. Wat gebeurt hier? De gebruikersrol heeft lees- en schrijfrechten op het attribuut, dus de gebruiker kan het via de client-API aanpassen. Validatie achter een knop is niet genoeg voor echte beveiliging. Er zijn drie manieren om validatie wél goed te implementeren.

1. Validatie in een before-commit

Voeg een “before commit”-eventhandler toe. Proberen we het JavaScript opnieuw, dan krijgen we een foutmelding: deze aanpak werkt. In dit eenvoudige geval werkt het goed. In complexere situaties heeft u vaak extra context nodig, en kunnen er veel meer controles zijn met verschillende voorwaarden. Dat implementeren kan flink wat werk worden.

2. Een niet-persistente entiteit

Een andere optie is een niet-persistente entiteit. We passen de entiteit zo aan dat de gebruiker geen schrijfrechten op het attribuut nodig heeft; onze JavaScript-actie werkt dan niet meer. We maken een niet-persistente kopie van de entiteit, met een associatie naar het origineel. Alle interactie van de gebruiker met Animal loopt via de niet-persistente entiteit:

  • Bij het aanmaken van een nieuw object maakt u eerst de niet-persistente entiteit aan.
  • Bij het bewerken kopieert u de attribuutwaarden naar de niet-persistente entiteit en opent u die.
  • Bij het opslaan valideert u de niet-persistente entiteit. Is die geldig, dan maakt of wijzigt u het echte object.

Deze methode werkt ook, maar kan veel werk zijn en heeft mogelijk grote impact op de applicatie.

3. Een eigen Java-controle vóór de commit

Een alternatief is een Java-actie vóór de commit. Die controleert of er attributen zijn gewijzigd die niet zijn opgegeven in een nieuw attribuut “AllowedToChange”. Worden er wijzigingen gevonden in attributen die daar niet in staan, dan geeft de Java-actie een fout. Dat betekent dat elke commit in Mendix een lijst met attribuutnamen bevat, gescheiden door een puntkomma.

De opzet: een attribuut “AllowedToChange” zonder rechten voor gebruikers, een before-commit-microflow die de Java-actie uitvoert, en een extra Change Object-actie om aan te geven welke attributen mogen wijzigen. Proberen we het JavaScript opnieuw, dan krijgen we een fout in de browserconsole en uitgebreide logging in Mendix.

Dit is een veiligere en eenvoudigere manier om validatie te implementeren. Het voordeel is de kleinste impact op uw app. Het nadeel is dat het geen standaard Mendix-oplossing is: u geeft de lijst met attributen handmatig op, en attribuutnamen worden niet automatisch bijgewerkt als ze veranderen, dus “find usages” in Studio Pro werkt er niet voor. Het Mendix-project met alle bovenstaande voorbeelden staat op GitHub: StoneworxNL/Mendix-AttributeLock.

Conclusie

Goede validatie in Mendix is essentieel voor zowel data-integriteit als beveiliging. De drie methodes hierboven bieden verschillende manieren om dat te bereiken, afhankelijk van de complexiteit van uw applicatie en het vereiste beveiligingsniveau. Twijfelt u over de beveiliging van uw Mendix-app? Neem contact op; we kunnen een security-assessment van uw applicatie inplannen.