Power Pages Suchfilter validieren und OData sicher erzeugen

Inhalt

• Warum ein Power Pages Filter noch keinen gültigen Datenvertrag bildet
• Welche drei Prüfungen braucht die Power Pages Filtervalidierung?
• Wie wird der unterstützte Power Pages Filterumfang definiert?
• Wie repariert Power Pages URLs und erhält gültige Teilwerte?
• Wie validiert Power Pages Suchtext und Maximallänge?
• Wie validiert Power Pages Zahlen und Wertebereiche?
• Warum sind URL- und Payload-Sanitization getrennte Prüfungen?
• Wie validiert Power Pages Server Logic Filter unabhängig vom Browser?
• Warum ersetzt CSRF-Schutz keine Geschäftsregel?
• Warum darf Autorisierung nicht aus einem Browserfeld kommen?
• Wie erzeugt Power Pages OData-Filter aus festen Bausteinen?
• Was schützt OData-Escaping und was nicht?
• Wie verhindern Locale-Regeln falschen Power Pages Support?
• Wie trennt die Support-Matrix UI-Werte und Dataverse Filter?
• Power Pages Suchfilter validieren: Erfahrungen aus dem Enterprise-Projekt

Warum ein Power Pages Filter noch keinen gültigen Datenvertrag bildet

Ein Filter kann im React Formular sichtbar sein und trotzdem keinen bestätigten Weg bis Dataverse besitzen.

Das klingt zunächst widersprüchlich. Die Oberfläche kennt den Wert. Der Zustand speichert ihn. Vielleicht erscheint er sogar als aktive Auswahl.

Aber erst die vollständige Kette entscheidet, ob der Filter fachlich wirkt.

Die URL muss den Wert eindeutig serialisieren. Der Browser muss ihn wiederherstellen können. Power Pages Server Logic muss ihn unabhängig prüfen. Der OData-Aufbau braucht ein festes Feld und einen festen Operator. Die Dataverse Custom API muss diesen Parameter nachweislich unterstützen.

Fehlt eine dieser Grenzen, ist der Filter nicht vollständig umgesetzt.

Ich dokumentiere deshalb nicht nur Eingabefelder. Ich dokumentiere den Weg jedes Filters vom Browser bis zum Backend. Die Architekturübersicht der Power Pages Enterprise-Suche zeigt diesen Datenfluss im Gesamtbild.

Power Pages Suchfilter validieren heißt für mich deshalb, jede Grenze getrennt zu benennen und keine Browserprüfung als serverseitige Garantie darzustellen.

Welche drei Prüfungen braucht die Power Pages Filtervalidierung?

In meiner Suche durchläuft ein Wert drei Prüfungen.

Die erste Prüfung liegt im React Formular. Sie verhindert vermeidbare Bedienfehler. Ein zu langer Suchtext erhält eine verständliche Meldung. Auswahlfelder bieten nur bekannte Optionen an.

Die zweite Prüfung liegt beim Lesen und Schreiben der URL. Sie trimmt Text, parst Zahlen, entfernt unbekannte Listenwerte und erzeugt eine vereinheitlichte Query. Diese Schicht hält Reload, Teilen sowie Vor und Zurück konsistent.

Die dritte Prüfung liegt in Power Pages Server Logic. Sie beginnt unabhängig vom Browser. Sie prüft Body, Operation und jeden unterstützten Filter erneut. Erst danach entstehen die Parameter für Dataverse.

Nur diese serverseitige Prüfung ist für den Backend-Vertrag verbindlich.

Clientseitige Validierung kann Requests reduzieren und Fehler früher zeigen. Sie kann keine Autorisierung garantieren. Ein Browserwert bleibt veränderbar.

Microsoft beschreibt Power Pages Server Logic als serverseitige Ausführungsumgebung für Geschäftslogik, Validierung und Dataverse-Operationen. Genau dort liegt in meiner Architektur die Grenze zwischen hilfreicher Normalisierung und verbindlicher Entscheidung.

Wie wird der unterstützte Power Pages Filterumfang definiert?

Die Support-Matrix beschreibt den Vertrag jeder Filtergruppe vom Browser bis zur Dataverse Abfrage.

Die Tabelle beschreibt den Filterumfang dieser Power Pages Suche. Die Feldnamen und Katalogwerte sind für den Artikel generalisiert.

Bei der Branchenauswahl serialisiert der Browser die bekannten IDs. Server Logic prüft sie unabhängig gegen die eigene Allowlist und übersetzt die gültigen Werte in einen Dataverse Branchenfilter.

Die ausgewählten Branchen-IDs grenzen die Suchergebnisse ein. Clusterlabels und Gruppierungen bleiben eine Aufgabe der Oberfläche.

Wie die editierbare Gruppierung zwischen Web Template, Landingpage JavaScript und React geteilt wird, ohne die Server-Allowlist zu ersetzen, dokumentiere ich im Beitrag über Power Pages React JSON Konfiguration.

Ein sichtbares Steuerelement, ein TypeScript-Feld und eine serverseitige Allowlist ersetzen keinen bestätigten API-Vertrag.

Wie repariert Power Pages URLs und erhält gültige Teilwerte?

Geteilte URLs sind externe Eingaben.

Ein Nutzer kann einen Query-String bearbeiten. Ein alter Link kann Werte enthalten, die nicht mehr unterstützt werden. Eine Liste kann gültige und ungültige Einträge mischen.

Ich verwerfe deshalb nicht automatisch den gesamten Suchzustand.

Ein generalisierter Listenparser arbeitet pro Mitglied:

function parseAllowedNumbers(
  value: string | null,
  allowed: readonly number[]
): {
  readonly values: readonly number[];
  readonly changed: boolean;
} {
  if (value === null || value.trim() === '') {
    return { values: [], changed: false };
  }

  const values: number[] = [];
  let changed = false;

  for (const item of value.split(',')) {
    const normalizedItem = item.trim();
    const parsed = Number(normalizedItem);

    if (normalizedItem === '' || !Number.isInteger(parsed) || !allowed.includes(parsed) || values.includes(parsed)) {
      changed = true;
      continue;
    }

    values.push(parsed);
  }

  return { values, changed };
}

Wenn eine Liste drei Werte enthält und nur einer ungültig ist, bleiben die beiden gültigen Werte aktiv.

Leere Mitglieder, unbekannte Werte und Duplikate verschwinden. Die URL wird anschließend in vereinheitlichter Form geschrieben.

Bei Branchen-IDs gilt eine zusätzliche Regel. Die gültigen Werte werden nicht in zufälliger Eingabereihenfolge serialisiert. Sie folgen der Reihenfolge des bekannten Katalogs. Dadurch erzeugt dieselbe Auswahl immer denselben Query-String.

Der Beitrag über URL-Zustand und Browserhistorie zeigt, wie diese Reparatur mit replaceState erfolgt und fremde Query-Parameter erhalten bleiben.

Wie validiert Power Pages Suchtext und Maximallänge?

Der Suchtext besitzt einen kleinen Vertrag.

Vor der Verarbeitung wird er getrimmt. Ein leerer Text wird nicht in den Filter aufgenommen. Bis zu 100 Zeichen bleiben gültig.

Ein URL-Wert über dieser Grenze wird entfernt und als ungültiger Parameter markiert. Die Ergebnisseite kann den übrigen gültigen Zustand trotzdem laden und die URL reparieren.

Bei einer direkten Formularaktion verhält sich die Oberfläche anders. Der Controller liefert eine sichtbare Validierungsmeldung und startet keine Suche.

Server Logic prüft denselben Wert erneut. Ein falscher Typ oder ein zu langer optionaler Suchtext wird bei der vollständigen Suche entfernt. Andere gültige Filter bleiben erhalten.

Die Suggest-Operation ist strenger. Dort ist searchText erforderlich. Ein falscher Typ oder mehr als 100 Zeichen beendet den Request mit einem Fehler. Unter drei Zeichen liefert die aktuelle Implementierung eine erfolgreiche leere Vorschlagsliste, ohne die Custom API aufzurufen.

Diese Unterschiede sind absichtlich. Eine vollständige Suche ohne Freitext bleibt fachlich gültig. Eine Suggest-Anfrage ohne verwendbaren Text besitzt dagegen keinen sinnvollen Auftrag.

Der Beitrag Power Pages Auto-Suggest mit React: Debounce und Requests zeigt diesen kleineren Vertrag zusammen mit Debounce, Request-Sequenzen und den sichtbaren UI-Zuständen.

Wie validiert Power Pages Zahlen und Wertebereiche?

Jeder numerische Filter besitzt eine Domäne von 0 bis zu einem feldbezogenen Maximum M.

Die Endpunkte werden unabhängig normalisiert:

function normalizeBound(value: number | null, direction: 'min' | 'max', maximum: number): number | null {
  if (value === null || !Number.isFinite(value)) {
    return null;
  }

  const clamped = Math.min(maximum, Math.max(0, value));

  if (direction === 'min' && clamped === 0) {
    return null;
  }

  if (direction === 'max' && clamped === maximum) {
    return null;
  }

  return clamped;
}

Ein Wert unter null wird auf null eingegrenzt. Eine Untergrenze von null schränkt das Ergebnis nicht weiter ein und wird deshalb entfernt.

Ein Wert über dem Maximum wird auf M eingegrenzt. Eine Obergrenze von M ist ebenfalls wirkungslos und wird entfernt.

Die asymmetrische Folge ist wichtig:

Die aktuelle Implementierung prüft die Beziehung zwischen beiden Endpunkten nicht.

Wenn nach der Normalisierung min > max gilt, bleiben beide Werte erhalten. Server Logic erzeugt daraus zwei Bereichsklauseln. Die Suche liefert dann typischerweise keine passenden Datensätze, aber keinen eigenen Validierungsfehler für die Reihenfolge.

Ich dokumentiere diese Grenze ausdrücklich. Die Sanitization vertauscht die Grenzen nicht automatisch. Das wäre eine andere Geschäftsregel.

Warum sind URL- und Payload-Sanitization getrennte Prüfungen?

Die URL-Prüfung muss zusätzlich erkennen, ob eine Reparatur nötig ist.

Darum liefert sie neben den Filtern eine Liste veränderter Parameternamen:

interface SearchUrlParseResult {
  readonly filters: SearchFilters;
  readonly invalidParameters: readonly string[];
}

Ein Parameter landet dort, wenn ein Wert entfernt, eingegrenzt, als wirkungslos erkannt, dedupliziert oder in eine einheitliche Reihenfolge gebracht wurde.

Die Ergebnisseite nutzt diese Information. Bei mindestens einem veränderten bekannten Parameter schreibt sie die bereinigte Query mit replaceState in denselben History-Eintrag.

Die Vorbereitung eines direkten Formularzustands besitzt ein anderes Ziel. Sie baut einen gültigen Request-Payload. Sie braucht keine Liste reparierter URL-Keys.

Deshalb liefert die Payload-Normalisierung nur:

1. den vereinheitlichten Query-String
2. den unterstützten Browser-Payload
3. die normalisierten Filter

Beide Wege verwenden dieselben fachlichen Grenzwerte und Allowlists. Sie besitzen aber unterschiedliche Rückgabeverträge.

Wie validiert Power Pages Server Logic Filter unabhängig vom Browser?

Power Pages Server Logic übernimmt nicht den bereinigten Browserzustand als Wahrheit.

Der Server prüft zuerst den vollständigen Request.

Der Body muss als JSON-Objekt verwendbar sein. null, Arrays, primitive Werte und fehlerhaftes JSON werden abgelehnt. Die Implementierung begrenzt den serialisierten Body zusätzlich auf 8192 UTF-8-Bytes.

Diese Zahl ist ein projektspezifischer Vertrag dieses Endpunkts. Sie ist kein allgemeines Power-Pages-Plattformlimit.

Danach folgt eine feste Operations-Allowlist. Nur search und suggest sind erlaubt. Ein fehlender oder unbekannter Operationswert beendet den Request vor dem Custom-API-Aufruf.

Erst dann prüft Server Logic jeden optionalen Suchfilter erneut.

Ungültige optionale Werte werden entfernt. Gültige Nachbarwerte bleiben erhalten. Unbekannte zusätzliche Felder erhalten keine Wirkung.

Dieses Verhalten unterscheidet Requestfehler von Filterbereinigung:

Die Unterscheidung verhindert zwei problematische Extreme.

Die Suche bricht nicht wegen eines einzelnen beschädigten optionalen Filters vollständig ab. Sie behandelt aber einen unklaren Requestvertrag auch nicht stillschweigend als gültige Standardoperation.

Warum ersetzt CSRF-Schutz keine Geschäftsregel?

Clientseitige Aufrufe von Power Pages Server Logic benötigen einen CSRF-Token.

Microsoft zeigt dafür in der Dokumentation zum Aufruf von Server Logic den Wrapper shell.safeAjax. Die Dokumentation zum CSRF-Wrapper zeigt, wie der Request Verification Token in den AJAX-Request gelangt.

Der Token schützt den Request gegen eine bestimmte Klasse gefälschter browserseitiger Anfragen.

Er entscheidet nicht:

1. ob ein Filter fachlich unterstützt wird
2. ob eine Zahl innerhalb ihrer Domäne liegt
3. ob ein Optionswert erlaubt ist
4. ob ein Nutzer auf einen bestimmten Datensatz zugreifen darf

Diese Entscheidungen liegen in getrennten Kontrollen.

Warum darf Autorisierung nicht aus einem Browserfeld kommen?

Der Browser sendet keine verbindliche Aussage wie isAuthorized: true.

Die aktuelle Server Logic leitet den benötigten Nutzerstatus aus der Power-Pages-Sitzung ab. Ein gleichnamiges Feld im Browser-Payload könnte diesen Wert nicht überschreiben.

Auch dieser serverseitig abgeleitete Boolean ersetzt keine Plattformberechtigung.

Microsoft dokumentiert, dass Tabellenberechtigungen den Zugriff auf Dataverse-Datensätze in Power Pages einschränken und über Webrollen zugeordnet werden. Die Power Pages Web API folgt diesen Tabellenberechtigungen.

Ein angemeldeter Nutzer besitzt deshalb nicht automatisch Zugriff auf alle Datensätze.

Anmeldung, Webrolle, Tabellenberechtigung, serverseitig abgeleiteter Nutzerstatus und fachliche Filterregeln sind getrennte Bestandteile derselben Sicherheitsarchitektur.

Der Beitrag zur Power Pages Server Logic Sicherheitsgrenze ordnet diese Kontrollen in den vollständigen Requestweg ein.

Wie erzeugt Power Pages OData-Filter aus festen Bausteinen?

Der Browser sendet keine vollständige OData-Klausel.

Server Logic entscheidet über:

1. Feldnamen
2. Operatoren
3. Funktionen
4. Klammerung
5. Verknüpfung mit and oder or

Nur der geprüfte Wert kommt aus dem Browser.

Ein generalisiertes Beispiel sieht so aus:

function quoteODataString(value) {
  return "'" + value.replace(/'/g, "''") + "'";
}

function buildTextClause(searchText) {
  const value = quoteODataString(searchText.toLowerCase());

  return ['contains(tolower(name),' + value + ')', 'contains(tolower(city),' + value + ')'].join(' or ');
}

function buildRangeClauses(fieldName, range) {
  const clauses = [];

  if (range.min !== undefined) {
    clauses.push(fieldName + ' ge ' + range.min);
  }

  if (range.max !== undefined) {
    clauses.push(fieldName + ' le ' + range.max);
  }

  return clauses;
}

Mehrere Werte derselben Auswahl bilden eine geklammerte or-Gruppe. Unterschiedliche Filtergruppen werden mit and verbunden. Numerische Grenzen verwenden feste Vergleiche wie ge und le.

Die aktuelle Implementierung verteilt diese Klauseln auf drei fachliche Parameter:

Die privaten Dataverse-Feldnamen und die produktive Custom API gehören nicht in einen öffentlichen Artikel. Entscheidend ist das Muster. Der Server besitzt die Struktur. Der Browser liefert nur Kandidatenwerte.

Die Power Pages Dokumentation zu OData-Filtern beschreibt Vergleichsoperatoren, logische Operatoren, Gruppierung und Funktionen wie contains. Die Dataverse-Dokumentation zu $filter ergänzt die Regeln für Zeichenketten und Sonderzeichen.

Was schützt OData-Escaping und was nicht?

Ein Apostroph in einem einzelnen OData-Stringliteral wird durch zwei Apostrophe dargestellt.

Aus:

O'Brian

wird:

'O''Brian'

Diese Umwandlung schützt den Literalwert innerhalb einer bereits festgelegten Ausdrucksstruktur.

Sie macht keinen beliebigen Text zu einem sicheren OData-Ausdruck.

Wenn der Browser Feldnamen, Operatoren, Funktionen oder vollständige Klauseln liefern dürfte, könnte das Verdoppeln von Apostrophen die Struktur nicht kontrollieren.

Darum kombiniere ich Escaping mit festen serverseitigen Bausteinen und Allowlists.

Bei einem OData-Filter in einer URL kommt eine weitere Ebene hinzu. Sonderzeichen müssen für den URL-Transport codiert werden. OData-Literal-Escaping und URL-Encoding lösen verschiedene Probleme.

Wie verhindern Locale-Regeln falschen Power Pages Support?

Die URL kann nur unterstützte Locale-Werte enthalten. Ein ungültiger URL-Wert wird als abweichend markiert. Beim erneuten Serialisieren verwendet die Anwendung die tatsächlich aufgelöste Power-Pages-Sprache.

Server Logic besitzt zusätzlich einen eigenen Fallback für fehlende oder ungültige Locale-Werte.

Die Ebenenfilter zeigen, warum Locale mehr als eine Zahl ist. Die aktuelle Implementierung besitzt bestätigte Namen nur für eine Sprache. In der anderen Sprache wird der Ebenenfilter serverseitig weggelassen.

Das ist besser als eine unbestätigte Übersetzung in den Dataverse-Filter zu schreiben.

Teilweise unterstützt bedeutet hier:

1. der Browser kennt den stabilen Level-Slug
2. Server Logic akzeptiert nur bekannte Slugs
3. ein OData-Filter entsteht nur für die bestätigte Sprache
4. für andere Sprachen bleibt die Auswahl ohne Backend-Mapping

Die Grenze gehört in die Support-Matrix und nicht in eine versteckte Codeannahme.

Wie trennt die Support-Matrix UI-Werte und Dataverse Filter?

Die zuvor gezeigte Support-Matrix zum unterstützten Power Pages Filterumfang ordnet jeder Filtergruppe ihren Browservertrag, ihre serverseitige Prüfung und ihre Wirkung in Dataverse zu.

Nicht jeder Wert im Domänenmodell ist Teil des Suchvertrags. Weitere Flächenmerkmale, Suchradius und Metropolregion werden nicht im Suchrequest übertragen und erzeugen keinen Dataverse Filter.

Ein UI-Zustand oder ein TypeScript-Feld beschreibt deshalb für sich allein keine Filterwirkung.

Server Logic erzeugt OData nur für die Filtergruppen mit einem definierten Request-Vertrag und Backend-Mapping.

Diese Trennung hält die Bedeutung der Auswahl nachvollziehbar. Sie verhindert, dass ein sichtbares Feld unbeabsichtigt die Dataverse Abfrage verändert.

Wenn du diesen Ansatz in deinem eigenen Power Pages Portal einsetzt, dokumentiere für jede Filtergruppe:

1. die Bedeutung des Werts in der Oberfläche
2. seine Darstellung in URL und Browser-Payload
3. die Sanitization-Regel im Browser
4. die unabhängige Allowlist oder Domäne in Server Logic
5. die Zuordnung zum Dataverse-Parameter
6. die Wirkung auf die Suchergebnisse

So bleibt der Filterumfang ein fachlicher Vertrag und keine Annahme aus der Oberfläche.

Power Pages Suchfilter validieren: Erfahrungen aus dem Enterprise-Projekt

Ich habe diese Pipeline für eine Enterprise-Suche in Power Pages umgesetzt.

Die ECE-Fallstudie zur Power Pages Enterprise-Suche zeigt den Projektkontext. Die Beispiele in diesem Beitrag verwenden neutrale Feldnamen und anonymisierte Katalogwerte.

Für mich liegt der Wert dieser Regeln in der Nachvollziehbarkeit.

Eine beschädigte URL bleibt nutzbar, weil gültige Teilwerte erhalten bleiben. Der Browser erzeugt einen sauberen Zustand. Server Logic wiederholt die Prüfung unabhängig. OData entsteht nur aus definierten Bausteinen des Suchvertrags.

Du planst eine Power Pages Suche mit komplexen Filtern, Server Logic und Dataverse? Im Power Pages Pro-Code-Bereich zeige ich, wie ich Datenverträge, Sicherheitsgrenzen und fachliche Regeln vor der Umsetzung prüfe.