Einführung in App Builder - Anhang D: Sicherheit in App Builder (Erweitert)

Dies ist der vierte und letzte Anhang der Einführung in App Builder-Tutorialserie. Diese Anhänge ergänzen die Lektionen der Serie und bieten detailliertere Informationen zu den eingeführten Konzepten.

In dieser Lektion erkunden wir die Sicherheitsebene von App Builder – den Bereich, in dem wir steuern, wer auf unsere Anwendung zugreifen kann, und welche Teile ihrer Daten jeder Benutzer sehen oder ändern darf.

Rollen

Rollen sind die Art und Weise, wie App Builder Berechtigungen für eine Datenquelle organisiert. Eine Rolle kann Lesen-, Einfügen-, Aktualisieren- und Löschen-Berechtigungen für eine Tabelle oder ein Geschäftsobjekt erhalten, und Benutzer erhalten ihre Rollen indirekt durch die Mitgliedschaft in einer oder mehreren Sicherheitsgruppen. Gruppen organisieren Benutzer; Rollen organisieren Berechtigungen. Eine detaillierte Erklärung, wie jede Berechtigung beeinflusst, was ein Benutzer sehen und tun kann, finden Sie unter Berechtigungen und Privilegien.

Erstellen wir einen Satz von Rollen für unsere Northwinds-Datenquelle, die häufige Funktionen in einem Unternehmen widerspiegeln: Superuser, Schreibgeschützt, Betrieb, Personalwesen und Vertrieb. Jede führt eine andere Möglichkeit ein, Berechtigungen zu gewähren – von breiten Beschleunigern bis zur präzisen, objektweisen Kontrolle.

Superuser

Erstellen Sie eine Superuser-Rolle, indem Sie diese Schritte ausführen:

1. Wählen Sie in App Workbench > Datenquellen die Quelle Northwinds (Standard) aus.

2. Klicken Sie im Abschnitt Business Logic Layer auf Rollen. Das Dialogfeld Rollen wird geöffnet.

3. Klicken Sie auf + Superuser. App Builder erstellt automatisch eine Rolle namens Superuser mit vollständigen Berechtigungen für jede Tabelle und jedes Geschäftsobjekt in der Datenquelle.

Schreibgeschützt

Erstellen Sie nun eine Schreibgeschützt-Rolle, indem Sie diese Schritte ausführen:

1. Klicken Sie auf + Rolle.

2. Geben Sie im Feld Name Schreibgeschützt ein.

3. Geben Sie im Feld Beschreibung eine Beschreibung wie Schreibgeschützter Zugriff auf alle Northwinds-Daten ein.

4. Klicken Sie auf Speichern.

5. Erweitern Sie das Akkordeon Tabellen und klicken Sie auf Lesen gewähren, um der Rolle Schreibgeschützt auf einmal Lesezugriff auf jede Tabelle zu geben.

6. Erweitern Sie das Akkordeon Geschäftsobjekte und klicken Sie dann auf Lesen gewähren, um dasselbe für jedes Geschäftsobjekt zu tun.

Betrieb

Die Rolle Betrieb verwaltet den Kernbestand, Lieferantenbeziehungen und die Auftragserfüllung, die das Geschäft hinter den Kulissen am Laufen halten. Sie überwacht Produktkategorien, aktualisiert Preise und Lagerbestände, verwaltet Lieferantenkontakte und weist Versandunternehmen zu, um Kundenbestellungen zu liefern.

1. Klicken Sie auf + Rolle.

2. Geben Sie im Feld Name Betrieb ein.

3. Klicken Sie auf Speichern.

4. Klicken Sie auf das Symbol Seiten in der Zeile Betrieb – eine weitere Möglichkeit, die Rollenerstellung zu beschleunigen: Statt Berechtigungen Tabelle für Tabelle zu gewähren, wählen Sie aus, welche Seiten eine Rolle benötigt, und App Builder gewährt die zugrunde liegenden Berechtigungen, von denen diese Seiten abhängen.

5. Wählen Sie die Seiten Lieferanten, Lieferant, Versandunternehmen, Versandunternehmen, Produkte, Produkt und Kategorien aus, und gewähren Sie vollständigen Zugriff (Lesen, Einfügen, Aktualisieren und Löschen) auf alle.

6. Wählen Sie die Seiten Startseite, Kunden, Kunde, Bestellungen, Bestellung, Mitarbeiter und Mitarbeiter aus, und gewähren Sie nur Lesen-Zugriff auf alle, da Betrieb diese Daten anzeigen muss, ohne sie ändern zu können.

HR

Die HR-Rolle verwaltet Mitarbeiterdatensätze, deren regionale Zuordnungen und die Organisationsstruktur des Unternehmens. Sie benötigt präzise, granulare Zugriffe statt breiter Tabellen- oder Seitenzugriffe.

1. Klicken Sie auf + Rolle.

2. Geben Sie im Feld Name HR ein.

3. Klicken Sie auf Speichern.

4. Klicken Sie im Panel der Rolle auf + Berechtigungen, um spezifische Objekte einzeln hinzuzufügen.

5. Fügen Sie die Regeln Employee (Source), Region (Source), Region (List) und Employee (Network) hinzu, um der HR-Rolle vollständigen Zugriff auf jede zu gewähren. Das Hinzufügen einer Berechtigung auf diese Weise gewährt standardmäßig vollständigen Zugriff (Lesen, Einfügen, Aktualisieren und Löschen).

Übungszeit: Erstellen Sie die Sales-Rolle

Die Sales-Rolle muss Kunden und Bestellungen verwalten, Produkt-, Kategorie-, Versand- und Mitarbeiterdaten anzeigen und die erstellten Berichte einsehen. Sie sollte keinen Zugriff auf administrative Daten wie Lieferanten oder die Parametertabelle haben.

Erstellen Sie mit dem gleichen Pages-Symbol-Beschleuniger, den Sie für Operations verwendet haben, eine Sales-Rolle mit folgendem Zugriff:

• Vollständiger Zugriff auf die Seiten Customers, Customer, Orders und Order.
• Lese-Zugriff auf die Seiten Products, Product, Categories, Shippers, Shipper, Employees, Employee und Order Total by Employee.

Wählen Sie nicht die Seiten Suppliers, Supplier oder Parameter aus, damit Sales keinen Zugriff darauf hat.

Anwendungsgruppen

Sobald Rollen vorhanden sind, werden Berechtigungen standardmäßig restriktiv: Ein Benutzer erhält die Berechtigungen einer Rolle nur, wenn seine Gruppen ihm diese Rolle gewähren. Da sich Ihr eigenes Benutzerkonto noch in keiner Gruppe befindet, sperrt das Erstellen der obigen Rollen Sie aus Ihrer eigenen Anwendung aus, es sei denn, Sie verbinden sie mit echten Benutzern.

1. Klicken Sie auf der Seite Rollen auf Anwendungsgruppen.

2. Klicken Sie auf Erstellen.

3. Verwenden Sie im Feld Name das Muster [App-Name] [Rolle], z. B. Northwinds Superuser. Beschreiben Sie im Feld Beschreibung, wer zur Gruppe gehört.

4. Klicken Sie auf das Häkchen-Symbol, um zu speichern.

5. Klicken Sie im Panel Rollen neben der Rolle Superuser auf Gewähren, um sie mit der Anwendungsgruppe Northwinds Superuser zu verbinden.

Übungszeit: Erstellen Sie die verbleibenden Anwendungsgruppen

Wiederholen Sie die obigen Schritte, um eine Anwendungsgruppe für jede der anderen Rollen zu erstellen, die Sie erstellt haben: Read Only, Operations, HR und Sales.

Fügen Sie sich abschließend zur Gruppe Northwinds Superuser hinzu, damit Sie keinen Zugriff auf die Anwendung verlieren, die Sie erstellt haben:

1. Navigieren Sie zu IDE > Benutzerverwaltung > Gruppen.

2. Suchen Sie die Gruppe Northwinds Superuser und klicken Sie auf + Mitgliedschaft.

3. Wählen Sie Ihren Benutzer aus.

4. Klicken Sie auf das Häkchen-Symbol, um zu speichern.

Sie sollten jetzt wieder vollständige Berechtigungen haben, da Ihr Benutzer zur Gruppe Northwinds Superuser gehört, die Ihnen die Rolle Superuser gewährt.

Reach

Reach ist App Builders Implementierung von Sicherheit auf Zeilenebene. Während die gerade erstellten Rollen steuern, welche Operationen ein Benutzer auf ein Datenobjekt als Ganzes ausführen kann, steuert Reach, welche Zeilen dieses Datenobjekts ein Benutzer überhaupt sehen oder beeinflussen kann. Reach wird von der App Builder-Geschäftsengine implementiert, daher funktioniert es unabhängig von der zugrunde liegenden Datenbank auf die gleiche Weise.

Reach basiert auf drei Konzepten:

• Reach-Regel: Eine reguläre Geschäftsregel wie die in Anhang B erstellten, die bestimmt, auf welche Datensegmente ein Benutzer zugreifen kann. Reach-Regeln verwenden typischerweise die Funktion who() mvSQL, um den aktuellen Benutzer mit den Daten zu korrelieren, die er sehen darf.

• Reach-Token: Die einzelne Spalte, die in einer Reach-Regel ausgewählt ist und durch den Spaltennutzungstyp Reach Token gekennzeichnet ist. Sie identifiziert ein Datensegment, z. B. eine Region oder eine Geschäftseinheit.

• Reach-Registrierung: Die Konfiguration, die eine Reach-Regel an ein Datenobjekt bindet. Sie gibt an, welche Spalte des Datenobjekts dem Token der Reach-Regel entspricht, und optional, für welche Rolle die Einschränkung gilt.

Aus Lektion 5 erinnern Sie sich, dass wir eine RegionID-Spalte zu unserer Employee-Tabelle hinzugefügt haben und einige Mitarbeiter der East Coast Region und andere der West Coast Region zugewiesen haben. Wir werden dieses Setup verwenden, um die Employees-Seite so einzuschränken, dass jeder Benutzer nur Mitarbeiter aus seiner eigenen Region sieht.

Zunächst benötigen wir eine Möglichkeit, um zu identifizieren, welcher Mitarbeiterdatensatz dem aktuell angemeldeten Benutzer entspricht. Wir verwenden die UserID des Mitarbeiters anstelle des Benutzernamens, da sich ein Benutzername im Laufe der Zeit ändern kann, während eine UserID für die Lebensdauer des Kontos konstant bleibt.

1. Verbinden Sie die integrierte Datenquelle Vinyl (Sealed) mit Ihrer Anwendung, um ihre öffentlichen Datenobjekte zu nutzen: Klicken Sie in App Workbench > Data Sources auf + Data Source. Das Dialogfeld Add a Source to your application wird geöffnet.

2. Wählen Sie Link to existing source und suchen Sie dann Vinyl (Sealed) in der Liste der vorhandenen Datenquellen.

3. Klicken Sie auf Link Sources.

4. Klicken Sie auf Done.

Jetzt geben wir der Employee-Tabelle eine entsprechende Spalte.

1. Suchen Sie in App Workbench > Tables die Employee-Tabelle und öffnen Sie sie.

2. Klicken Sie auf + Column.

3. Geben Sie der neuen Spalte den Namen UserID. Stellen Sie im Bereich Data Types sicher, dass das Feld Logical auf Unique ID eingestellt ist, wodurch das Feld Physical automatisch auf UUID gesetzt wird.

4. Klicken Sie auf Save.

5. Suchen Sie in App Workbench > Rules die Regel Employee (Source) und öffnen Sie sie.

6. Suchen Sie auf der Registerkarte Tables die Spalte UserID und aktivieren Sie das Kontrollkästchen, um sie einzubeziehen.

Anstatt diesen Wert manuell einzugeben, fügen wir ein Steuerelement hinzu, damit es über die Benutzeroberfläche festgelegt werden kann – genauso wie in einer echten Produktionsumgebung.

1. Suchen Sie in App Workbench > Pages die Seite Employee und öffnen Sie sie.

2. Klicken Sie im Bereich Page Panel Layout auf Controls.

3. Klicken Sie auf + Control.

4. Wählen Sie im Menü Column die Option UserID und klicken Sie auf Next.

5. Wählen Sie unter Source die Option User_Read, das öffentliche Datenobjekt, das von der oben verlinkten Datenquelle Vinyl (Sealed) bereitgestellt wird. Die Auswahl Key (Column) sollte UserId sein und Title (Column) sollte UserName sein.

6. Klicken Sie auf Next und dann auf Finish.

7. Navigieren Sie zur Seite Employees, öffnen Sie einen bereits einer Region zugeordneten Mitarbeiter und verwenden Sie das neue Feld, um den Benutzer auszuwählen, mit dem Sie sich bei App Builder anmelden.

Jetzt erstellen wir die Reach-Regel.

1. Klicken Sie in App Workbench > Rules auf + Rule.

2. Geben Sie im Feld Name den Text Employee (Region Access) ein.

3. Wählen Sie im Feld Purpose die Option Reach.

4. Wählen Sie im Feld Target die Option Employee.

5. Klicken Sie auf Create.

6. Wählen Sie auf der Registerkarte Tables die Optionen RegionID und UserID zusätzlich zur bereits ausgewählten Primärschlüsselspalte EmployeeID.

7. Klicken Sie auf der Registerkarte Where auf + Where Clause. Geben Sie im Feld Left Expression den Text E.UserID ein, wählen Sie im Feld Operator die Option = und geben Sie im Feld Right Expression den Text who('userid') ein. Klicken Sie auf Save.

8. Doppelklicken Sie auf der Registerkarte Columns auf die Spalte RegionID. Legen Sie im Bereich Advanced ihren Column Usage Type auf Reach Token fest. Klicken Sie auf Save.

9. Klicken Sie auf Results im Panel Rule, um zu bestätigen, dass die Regel eine einzelne Zeile zurückgibt, die die Region des Mitarbeiterdatensatzes enthält, den Sie zuvor ausgewählt haben.

Registrieren wir nun diese Reach-Regel, damit sie das Geschäftsobjekt Employee (Source) einschränkt.

1. Suchen und öffnen Sie unter App Workbench > Rules die Regel Employee (Source).

2. Klicken Sie im Panel Rule auf Reach. Das Dialogfeld Reach wird geöffnet.

3. Klicken Sie auf + Reach.

4. Wählen Sie im Feld Reach Rule die Option Employee (Region Access) aus.

5. Wählen Sie im Feld Binding Column die Option RegionID aus.

6. Lassen Sie das Feld Role vorerst leer, damit die Einschränkung für alle Benutzer gilt, einschließlich Ihnen selbst, während wir es testen. Stellen Sie sicher, dass Active aktiviert ist.

7. Klicken Sie auf Save.

Besuchen Sie die Seitenvorschau Employees. Sie sollten nun nur noch Mitarbeiter sehen, die eine Region mit dem Mitarbeiterdatensatz teilen, den Sie ausgewählt haben, anstelle der gesamten Liste.

Übungszeit: Regionalen Zugriff auf Kunden erweitern

Mitarbeiter sind nicht die einzigen Northwinds-Daten, die von regionbasiertem Zugriff profitieren könnten. Wenden wir die gleiche Einschränkung auf die Tabelle Customer an.

1. Führen Sie die oben für die Tabelle Employee verwendeten Schritte aus, fügen Sie eine Spalte RegionID zur Tabelle Customer hinzu, fügen Sie sie zur Regel Customer (Source) hinzu, und fügen Sie ein Listensteuerelement Region (aus Region (List)) zur Popup-Seite Customer hinzu. Verwenden Sie das neue Steuerelement, um einigen Kundendatensätzen eine Region zuzuweisen.

2. Erstellen Sie eine neue Reach-Regel mit dem Namen Customer (Region Access), wobei Purpose auf Reach und Target auf Customer gesetzt ist. Klicken Sie auf der Registerkarte Tables auf + Tables, um die Tabelle Employee hinzuzufügen, die mit Customer auf RegionID verknüpft ist.

3. Verwenden Sie die gleiche Where-Klausel und den gleichen Spaltennutzungstyp Reach Token aus der Regel Employee (Region Access) erneut, und wählen Sie diesmal RegionID aus der Tabelle Employee aus. In Kombination mit der Verknüpfung gibt die Regel nun nur Kunden zurück, die eine Region mit dem aktuell angemeldeten Mitarbeiter teilen.

4. Registrieren Sie die neue Regel für das Geschäftsobjekt Customer (Source), und binden Sie sie diesmal an die Spalte RegionID der Tabelle Customer selbst.

5. Besuchen Sie die Seitenvorschau Customers, um zu bestätigen, dass nur Kunden aus Ihrer Region sichtbar sind.

Block

Der Spaltennutzungstyp Block verhindert, dass eine Zeile bearbeitet, gelöscht oder beides wird. Im Gegensatz zu Rollen, die für ein gesamtes Datenobjekt gelten, und Reach, das die Zeilensichtbarkeit steuert, kontrolliert Block, was ein Benutzer mit einer Zeile tun kann, die er bereits sehen kann. Ein Datenobjekt kann nur eine Block-Spalte verwenden, und ihr Wert bestimmt die Einschränkung:

Man kann eine Block-Spalte auf zwei verschiedenen Ebenen hinzufügen, und wo man sie hinzufügt, bestimmt die Reichweite der Einschränkung. Das Hinzufügen zu einer Tabelle in der Datenschicht wendet die Einschränkung global an, überall dort, wo die Daten dieser Tabelle in der gesamten App verwendet werden. Das Hinzufügen als Ausdruck auf einem Business Object in der Logikschicht, wie wir es unten tun, wendet die Einschränkung nur dort an, wo dieses spezifische Business Object verwendet wird.

Statt diese Zahlen direkt zurückzugeben, kann man auch die Funktion Block() mvSQL verwenden, die die besser lesbaren Werte None, Edit, Delete und EditAndDelete akzeptiert.

Sobald eine Bestellung versendet wurde, sollten ihre Positionen nicht mehr geändert werden. Sperren wir die Bearbeitung und das Löschen von OrderDetail-Zeilen für alle Bestellungen, die bereits ein ShippedDate haben.

1. In App Workbench > Rules findet und öffnet man die Regel OrderDetail (Source).

2. Im Tab Tables klickt man auf + Tables und fügt die Tabelle Order hinzu.

3. Im Tab Joins sollte App Builder bereits einen inneren Join zwischen OrderDetail und Order auf OrderID erstellt haben. Falls nicht, erstellt man ihn.

4. Im Tab Columns klickt man auf + Column. Im Feld Column or Expression gibt man IIF(O.ShippedDate IS NOT NULL, Block(EditAndDelete), Block(None)) ein. Im Feld Alias gibt man Block ein.

5. Man klickt auf Save.

6. Man doppelklickt auf die neue Spalte Block. Im Bereich Advanced setzt man ihren Column Usage Type auf Block. Man klickt auf Save.

Man besucht die Vorschau der Seite Orders und wählt eine Bestellung aus, die bereits ein ShippedDate hat. Im Panel Order Details sollten die Bearbeitungs- und Löschsymbole für keine Zeile mehr angezeigt werden. Man wählt eine Bestellung aus, die noch nicht versendet wurde, und diese Symbole sollten wie gewohnt verfügbar sein.

Übungszeit: Die Bestellung selbst sperren

Positionen sind nicht die einzigen Datensätze, die sich nach dem Versand nicht ändern sollten. Man wendet die gleiche Logik direkt auf die Regel Order (Source) an: Man fügt eine Block-Spalte mit dem Ausdruck IIF(ShippedDate IS NOT NULL, Block(EditAndDelete), Block(None)) hinzu und setzt ihren Column Usage Type auf Block. Da ShippedDate bereits zur Tabelle Order gehört, ist kein Join erforderlich. Man testet die Ergebnisse in der Vorschau der Seite Orders: Versendete Bestellungen sollten ihre eigenen Bearbeitungs- und Löschsymbole nicht mehr anzeigen.

Capability Bindings

Capability Bindings sind ein spezialisierter Bindungstyp, der den funktionalen Zustand eines untergeordneten Panels an die Daten eines übergeordneten Panels oder eines Seiten-Datenobjekts verknüpft. Sie können verwendet werden, um Steuerelemente ähnlich wie Block auszublenden oder zu deaktivieren, mit einem wesentlichen Vorteil: Capability Bindings können auch die Schaltfläche Create eines Panels beeinflussen. Das ist etwas, das Block nicht kann, da diese Schaltfläche unabhängig von einer bestimmten Zeile existiert.

Eine Capability-gebundene Spalte kann verschiedene Werte zurückgeben, um den Zustand eines gebundenen Steuerelements zu steuern:

Nutzen wir dies, um die Schaltfläche Create im Panel Order Details zu deaktivieren, wenn die übergeordnete Bestellung bereits versendet wurde. Dies verhindert, dass neue Positionen zu einer bereits versendeten Sendung hinzugefügt werden.

1. In App Workbench > Rules findet und öffnet man die Regel Order (Source).

2. Im Tab Columns klickt man auf + Column. Im Feld Column or Expression gibt man IIF(ShippedDate IS NOT NULL, 2, 0) ein. Im Feld Alias gibt man LockNewDetails ein.

3. Klicken Sie auf Speichern.

4. Öffnen Sie die Seite Orders und wählen Sie Action Drawer > Live Designer.

5. Klicken Sie auf das Bindungsspaltensymbol im Panel Order Details. Das Dialogfeld Binding Columns wird geöffnet:

   

6. Klicken Sie auf + Binding und setzen Sie das Feld Type auf Capability.

7. Wählen Sie im Feld Parent die Option LockNewDetails.

8. Wählen Sie im Feld Intrinsic Event die Option Insert.

9. Klicken Sie auf Speichern.

Besuchen Sie die Vorschau der Seite Orders und wählen Sie eine versendete Bestellung aus. Die Schaltfläche Create im Panel Order Details sollte jetzt deaktiviert sein. Wählen Sie eine Bestellung aus, die noch nicht versendet wurde, und die Schaltfläche sollte wieder anklickbar sein.

Übungszeit: Ausblenden statt Deaktivieren

Capability-Bindungen unterstützen andere Status als nur das Deaktivieren eines Steuerelements. Ein Wert von 1 blendet ein Steuerelement vollständig aus, anstatt es zu deaktivieren. Ändern Sie den Ausdruck LockNewDetails in IIF(ShippedDate IS NOT NULL, 1, 0) und testen Sie Ihre Ergebnisse: Die Schaltfläche Create im Panel Order Details sollte jetzt bei versendeten Bestellungen vollständig verschwinden, anstatt sichtbar aber unbrauchbar zu bleiben.

Bedingte Formatierung

Block- und Capability-Bindungen decken die integrierten Möglichkeiten ab, wie Benutzer mit einem Datensatz interagieren: die Bearbeitungs- und Löschsymbole sowie die Schaltfläche Create eines Panels. Allerdings umgehen alle Schaltflächen, die mit einem benutzerdefinierten Ereignis verbunden sind, wie die Schaltflächen Quantity Plus und Quantity Minus, die wir in Appendix B hinzugefügt haben, beide. Weder Block noch das Intrinsic Event einer Capability-Bindung gelten für ein benutzerdefiniertes Ereignis, daher funktionieren diese Schaltflächen weiterhin bei versendeten Bestellungen und ermöglichen es Benutzern, eine Quantity zu ändern, die nicht mehr bearbeitbar sein sollte.

Mit bedingter Formatierung können Sie ein Steuerelement basierend auf dem Wert einer beliebigen Spalte ausblenden oder deaktivieren, unabhängig davon, mit welchem Ereignis es verbunden ist. Verwenden wir dies, um die Schaltfläche Quantity Minus zu deaktivieren, sobald eine Bestellung versendet wurde.

1. Öffnen Sie die Seite Orders und wählen Sie Action Drawer > Live Designer.

2. Wählen Sie die Schaltfläche aus, die das Ereignis Quantity Minus ausführt.

3. Klicken Sie auf More > Styles.

4. Klicken Sie auf + Conditional formatting.

5. Wählen Sie im Feld Source Column die Option ShippedDate.

6. Wählen Sie im Feld Operator die Option Is not Null.

7. Wählen Sie im Feld State die Option Disabled.

8. Klicken Sie auf Speichern.

Besuchen Sie die Vorschau der Seite Orders und wählen Sie eine versendete Bestellung aus. Die Schaltfläche Quantity Minus sollte jetzt deaktiviert sein. Wählen Sie eine Bestellung aus, die noch nicht versendet wurde, und die Schaltfläche sollte wieder anklickbar sein.

Übungszeit: Bedingte Formatierung erweitern

Wiederholen Sie die obigen Schritte für die Schaltfläche, die das Ereignis Quantity Plus ausführt.

Wenden Sie dann die gleiche Einschränkung auf die Schaltfläche Delete Order Details im Panel Orders an, und setzen Sie dieses Mal ihren State auf Hidden statt Disabled, damit Sie sehen können, wie sich die beiden Status unterscheiden. Sobald eine Bestellung versendet wurde, sollte die Schaltfläche vollständig verschwinden, anstatt sichtbar aber unbrauchbar zu bleiben.

Weitere Informationen

Dies schließt diese tiefe Analyse der Details der Sicherheitsebene von App Builder ab. Falls noch nicht geschehen, lesen Sie Appendix A für einen genaueren Blick auf die Datenschicht, Appendix B für die Geschäftsschicht oder Appendix C für die UI-Schicht.

Um mehr über App Builder zu erfahren, besuchen Sie Jitterbit University.