janstoeckli

Hier treffen Gegensätze aufeinander, die sich überraschend gut ergänzen: künstlerische Freiheit, präzises Handwerk, digitale Lösungen und kulinarische Leidenschaft. All das spiegelt wider, was mich begeistert und antreibt.

Mendix Best Practice

  • Mendix Security von Beginn an im Produktionsmodus aktivieren

    Warum Security sofort eingeschaltet werden sollte

    In vielen Projekten bleibt die Mendix Security zunächst deaktiviert. Das führt dazu, dass Entwickler im späteren Projektverlauf sehr „großzügig“ Zugriff vergeben, nur um Mendix-Fehler schnell zu umgehen. Dadurch entstehen Lücken, die später viel Aufwand erzeugen.

    Wird Security dagegen von Anfang an im Produktionsmodus aktiviert, zwingt Mendix zu sauberen Entscheidungen:

    • klare Rollen
    • korrekte Objekt- und Attributrechte
    • strengere Microflow-Berechtigungen

    Fehler werden früh sichtbar statt kurz vor dem Release.

    Vorteile des Produktionsmodus

    • Entwickler denken bei jedem Schritt über Zugriff nach
    • Berechtigungen wachsen strukturiert mit
    • Domain-Model wird sicher entworfen
    • keine hektische Fehlersuche kurz vor dem Livegang

    Praxisbeispiel

    Ein Team startete mit ausgeschalteter Security. Nach Monaten wurden über 40 Meldungen sichtbar: fehlende Rechte, falsche Attribute, riskanter Zugriff. Die Reparatur dauerte Wochen.

    Ein anderes Team nutzte von Beginn an den Produktionsmodus. Ergebnis: kaum Fehler, klare Rollen, sichere Datenstruktur.

    Fazit

    Wer Mendix Security früh und im Produktionsmodus aktiviert, spart Zeit, erhöht die Datenqualität und vermeidet riskante Workarounds. Einfach einschalten – und sauber entwickeln.

  • Warum anonyme Nutzer nur nicht-persistente Entitäten erstellen dürfen

    In vielen Anwendungen spielt der Umgang mit anonymen Benutzern eine entscheidende Rolle für Sicherheit und Systemstabilität. Ein häufig unterschätztes Risiko besteht darin, anonymen Nutzern die Möglichkeit zu geben, persistente Datenobjekte zu erstellen. Was zunächst harmlos klingt, kann schnell zu einem ernsthaften Problem werden.

    Das Risiko: Unkontrolliertes Wachstum der Datenbank

    Erhalten anonyme Benutzer Schreibrechte auf persistente Entitäten, kann ein böswilliger Akteur Millionen von Objekten anlegen. Das Resultat: Die Datenbank wächst unkontrolliert an, verbraucht Speicherplatz und kann im Extremfall das gesamte System lahmlegen.

    Hinzu kommt, dass XPath-Constraints beim Erstellen neuer Objekte nicht angewendet werden. Dadurch greifen wichtige Validierungsmechanismen nicht – ein zusätzliches Sicherheitsrisiko.

    Nicht-konformer Ansatz

    Ein häufiges Anti-Pattern besteht darin, einer AnonymousUserModuleRole (also der Modulrolle für anonyme Benutzer) pauschal Create-Berechtigungen auf persistente Entitäten zu geben. Damit öffnet man Tür und Tor für Datenmissbrauch.

    Besserer Ansatz: Keine Schreibrechte oder nur nicht-persistente Entitäten

    Um das System zu schützen, sollten anonyme Nutzer:

    • entweder gar keine Create-Berechtigungen besitzen,
    • oder nur Entitäten erstellen dürfen, die nicht persistiert werden.

    Nicht-persistente (transiente) Entitäten eignen sich hervorragend für kurzfristige Interaktionen, bei denen keine Daten langfristig gespeichert werden müssen – etwa Formulareingaben, Gast-Sessions oder Vorschau-Objekte.

    Fazit

    Die Rechteverwaltung für anonyme Nutzer ist ein zentraler Bestandteil der Anwendungssicherheit. Anwendungen sollten sicherstellen, dass anonyme Benutzer nur minimal benötigte Rechte erhalten und keine persistierenden Objekte anlegen können. So bleibt die Datenbank geschützt – und das System stabil.