Eine App als Portal veröffentlichen
Ziel
Eine App, die Sie bereits gezeichnet haben, unter einer eigenen Webadresse bereitstellen, damit Personen außerhalb Ihrer Organisation – Kunden, Bewerber, die Öffentlichkeit – sie öffnen können, ohne sich überhaupt bei der Plattform anzumelden.
Bevor Sie beginnen
Sie brauchen zwei Dinge, und ohne das erste lässt sich das Portal nicht speichern:
- Eine Studio-App. Ein Portal veröffentlicht eine Zeichnung; es enthält keine. Siehe Eine Studio-App erstellen.
- Eine benutzerdefinierte API für alles, was das Portal liest. Ein Portal liest nie direkt aus einer Tabelle – warum, steht unten unter Was ein Portal lesen darf. Zeigt Ihr Portal nur Text und Bilder, können Sie das überspringen.
Schritte
- Öffnen Sie Ihre Lösung und wählen Sie Portale aus.
- Wählen Sie Neu aus.
- Geben Sie ihm einen Namen. So nennen Sie und Ihre Kollegen es; Besucher sehen ihn nicht, denn alles, was ein Besucher sieht, ist gezeichnet.
- Wählen Sie die zu veröffentlichende App aus der Liste. Es erscheinen nur Apps dieser Umgebung.
- Geben Sie eine Webadresse ein. Nur den ersten Teil –
acme-support, nicht die ganze Adresse. Der Rest der Adresse gehört zu Ihrer Parsware-Bereitstellung, und der Hinweis unter dem Feld zeigt, wie die fertige Adresse aussehen wird. - Wählen Sie, wer es öffnen darf. Jeder bedeutet, dass die Adresse direkt Ihre App öffnet; Personen, die sich anmelden stellt ein Anmeldeformular davor – siehe Besucher zur Anmeldung auffordern.
- Aktivieren Sie, was es lesen darf – die benutzerdefinierten APIs, die dieses Portal aufrufen darf.
- Wählen Sie, als wen Besucher handeln – die Sicherheitsrollen, die jeder Besucher dieses Portals besitzt. Siehe Auf welche Tabellen ein Portal zugreifen darf.
- Lassen Sie Veröffentlicht deaktiviert, solange Sie noch daran arbeiten, und aktivieren Sie es, wenn die Adresse antworten soll.
- Wählen Sie Speichern aus.
Was ein Portal lesen darf
Ein Portal liest über die benutzerdefinierten APIs, die Sie auflisten, und über nichts anderes. Es kann nicht direkt aus einer Tabelle lesen, und keine Einstellung erlaubt es.
Das ist Absicht. Das Zeichnen eines Bildschirms darf nie zu einem Weg werden, versehentlich eine Tabelle ins öffentliche Internet zu stellen. Eine benutzerdefinierte API ist etwas, das jemand bewusst geschrieben hat: Sie entscheidet in einem lesbaren Skript, was ein Fremder sehen darf. Eine Tabelle ist nur eine Tabelle.
Braucht ein Bildschirm Ihres Portals also Daten, ist die Reihenfolge: die benutzerdefinierte API definieren, sie in der Liste des Portals aktivieren und Ihren Bildschirm darüber lesen lassen.
Die API in Ihrem Bildschirm benennen
Ein Portal-Bildschirm benennt den Vertrag, den er liest, statt einer Tabelle:
loadRecords("api:par_articles@1", "articles", { top: 20, orderBy: "par_name" })
api: sagt, dass es sich um eine benutzerdefinierte API handelt; par_articles ist ihr logischer
Name; @1 ist ihre Version, denn zwei Versionen einer API sind zwei verschiedene Verträge. Dieselbe
Form funktioniert für getRecord, createRecord, updateRecord und deleteRecord – welche davon Sie
aufrufen, bestimmt, was die Plattform tut, und das eigene Verb der API muss darauf antworten können.
Ein createRecord, das auf eine API zeigt, die nur liest, schlägt fehl, wenn der Bildschirm es
ausführt.
In der App-Liste liest ein gezeichneter Bildschirm seine Tabellen direkt – so arbeitet die App einer
angemeldeten Person, und deshalb kann sie blättern und filtern. In einem Portal gibt es diese Tür
nicht. Ein Bildschirm, der api: nennt, öffnet sich daher im Portal und verweigert in der Shell –
und sagt das, statt eine leere Liste anzuzeigen.
Wollen Sie eine Zeichnung an beiden Orten, braucht sie zwei Bildschirme. Diesen Kompromiss ist die Plattform bewusst eingegangen: Ihr Portal liest über einen Vertrag, den Sie geschrieben haben, und der Vertrag entscheidet, was ein Fremder sieht.
Ihre API sollte für eine Liste { "rows": [...], "total": 12 } antworten. Antwortet sie
etwas anderes, zeigt der Bildschirm eine leere Liste statt eines Fehlers, sodass ein Portal nie durch
einen Fehler in einer einzelnen API unbrauchbar wird.
Die Liste ist eine Berechtigung, keine Landkarte. Eine API zu aktivieren, sagt, dass dieses Portal sie aufrufen darf – nicht mehr. Ihr Bildschirm entscheidet, wann, indem er sie nennt. Eine API, die Sie nicht aktiviert haben, wird abgelehnt, auch wenn ein Bildschirm sie anfordert – das verhindert, dass ein Fehler in einer Zeichnung zu einer Tür wird.
Schreiben erfordert Besucher, die sich anmelden – oder eine Prüfung. Eine API, die auf POST, PATCH, PUT oder DELETE antwortet, lässt sich erst aufrufen, wenn Wer darf es öffnen auf Personen gesetzt ist, die sich anmelden, weil es in einem offenen Portal niemanden gibt, dem man eine Änderung zuordnen könnte. Den einzigen Weg darum herum beschreibt der nächste Abschnitt.
Fragen Sie die Person, die Ihre Parsware-Installation betreibt, ob dem Portal-Host der Scope gewährt wurde, den Ihre benutzerdefinierte API verlangt. Jede benutzerdefinierte API nennt einen, und der Portal-Host besitzt ihn im Namen Ihrer Besucher – ohne ihn wird jeder Lesevorgang abgelehnt, und die Seite zeigt einfach nichts.
Auf welche Tabellen ein Portal zugreifen darf
Die aktivierten benutzerdefinierten APIs sagen, welche Verträge eine Seite aufrufen darf. Als wen Besucher handeln sagt, welche Tabellen diese Verträge dann lesen und schreiben dürfen – dieselben Sicherheitsrollen, die Sie Ihren eigenen Kollegen geben, mit denselben Rechten.
Geben Sie einem Portal eine eigene Rolle, die genau das gewährt, was seine APIs brauchen – etwa Lesen und Erstellen für Fälle –, statt einer Rolle, die Ihre Mitarbeiter verwenden. Jeder Besucher des Portals besitzt sie, ob angemeldet oder nicht.
Wählen Sie keine, erreicht das Portal nichts. Seine Listen sind leer, und jedes Speichern meldet Das konnte nicht gespeichert werden. Das ist die sichere Richtung, und es ist das Erste, was Sie prüfen sollten, wenn ein Portal auf einer richtig aussehenden Seite nichts zeigt.
In einem Portal mit Anmeldung ist die Rolle nicht das Ende. Hat die Tabelle eine Regel, die festlegt, welche Zeilen wem gehören – siehe Festlegen, wessen Datensätze ein Besucher sieht –, wird jeder Besucher auf die Zeilen seines eigenen Unternehmens eingeschränkt, nachdem die Rolle ihn hereingelassen hat.
Die Rolle des Plattformadministrators wird hier nie angeboten. Ein Besucher, der sie besäße, besäße die ganze Umgebung.
Jeden Ihnen etwas senden lassen
Aktivieren Sie Jeden Ihnen etwas senden lassen – die Option erscheint nur, solange Wer darf es öffnen auf Jeder steht –, und ein Besucher ohne Konto kann schreiben, sofern sein Browser zuvor einen Moment an einem Rätsel arbeitet, das beweist, dass er kein Skript ist.
Das macht ein Kontaktformular möglich. Ohne diese Option darf ein Portal, das jeder öffnen kann, lesen, aber nicht schreiben – man müsste jemanden also bitten, ein Konto anzulegen, bevor er Ihnen eine Nachricht senden kann, und das ist kein Kontaktformular.
Es gibt nichts zu zeichnen und für den Besucher nichts zu tun. Kein Kästchen zum Ankreuzen, kein verzerrtes Wort zum Entziffern, keine Bilder von Ampeln. Die Plattform gibt dem Browser eine kleine Rechenaufgabe; ein Laptop ist fertig, bevor Sie es bemerken, ein altes Telefon braucht einen Moment und zeigt währenddessen Es wird geprüft, ob Sie ein Mensch sind… unter der Schaltfläche. Über den Besucher wird nichts erfasst, und nichts auf der Seite stammt vom Server eines anderen Unternehmens.
Was es verhindert und was nicht. Es macht Massenübermittlungen teuer: Ein Skript, das tausend Formulare pro Stunde senden könnte, zahlt nun für jedes einzelne echte Arbeit und sendet in der Praxis vierzig. Es hält nicht jemanden auf, der entschlossen ist und echte Browser betreibt – und kein solches Kästchen irgendwo hält das auf, wie auch immer es heißt. Betrachten Sie es als Spamfilter mit Biss, nicht als Schloss.
Drei Dinge ändert es nicht:
- Was aufgerufen werden kann. Nur die oben aktivierten benutzerdefinierten APIs, genau wie zuvor.
- Was geschrieben werden kann. Das eigene Anfrageschema der API entscheidet weiterhin, welche Felder ein Besucher setzen darf. Ein Vertrag, der einen Betreff und eine Nachricht annimmt, nimmt einen Betreff und eine Nachricht an.
- Wer jemand ist. Niemand ist angemeldet, also ist nichts überprüft. Speichert Ihre API eine E-Mail-Adresse, die der Besucher eingegeben hat, ist das eine Adresse, die jemand eingegeben hat. Wo das wichtig ist, bitten Sie Besucher stattdessen, sich anzumelden.
portal-contact-form in samples/solutions/ ist genau das: ein offenes Portal, ein Schreibvorgang,
eine daran angehängte Datei und eine Seite in der Website selbst, die erklärt, worauf Sie achten
sollten.
Es öffnen
Sobald ein Portal eine Adresse hat, zeigt die Liste sie als Link, und Portal öffnen in der Befehlsleiste öffnet es in einem neuen Tab. Öffnen Sie das Portal zum Bearbeiten, erscheint dieselbe Adresse unter dem Feld Webadresse mit zwei kleinen Schaltflächen daneben: Eine öffnet das Portal, wenn Sie es sich ansehen möchten, und eine kopiert die Adresse, wenn Sie sie gleich jemandem senden wollen. Keine zeigt ein Wort – die Adresse ist lang, und Beschriftungen daneben würden die zweite Schaltfläche in eine eigene Zeile schieben –, fahren Sie also mit dem Mauszeiger darüber, und sie sagen, welche welche ist.
Die Adresse erscheint erst, wenn sie gespeichert wurde. Während Sie noch eine Bezeichnung eingeben, zeigt der Hinweis unter dem Feld, wie die fertige Adresse aussehen wird; ein Link aus etwas, das Sie noch nicht gespeichert haben, würde auf ein Portal zeigen, das es nicht gibt.
Liefert Ihre Installation keine Portale aus, gibt es keine Adresse zum Öffnen, und der Hinweis bleibt dort, wo der Link stünde. Fragen Sie die Person, die Ihre Parsware-Installation betreibt.
Dieser Satz betrifft nie Ihr Portal – es ist die Plattform, die sagt, dass sie nicht antworten konnte, und Ihre Zeichnung, Ihre Adresse und der Schalter Veröffentlicht spielen keine Rolle. Es ist eine von zwei Ursachen, und beide gehören der Person, die Ihre Installation betreibt: Die Dienste sind nicht verfügbar, oder der Portal-Host erhält keine Anmeldeinformationen von Parsware. Eine falsche Adresse meldet etwas ganz anderes („Hier ist nichts veröffentlicht“), sodass Sie beides schon an der Seite selbst unterscheiden können.
Was ein Besucher sieht
Zwei Dinge an einer Portalseite gehören der Plattform statt Ihnen, und beide sollten Sie kennen, bevor jemand Sie danach fragt.
Ein Portal öffnet sich dunkel. Ihre eigenen Apps in Parsware öffnen sich hell, weil Sie dort einen Arbeitstag verbringen; ein Portal ist der Ort, an dem ein Fremder über einen Link in einer Nachricht ankommt, meist auf einem Telefon, und dunkel ist der freundlichere erste Eindruck. Eine kleine Hell/Dunkel-Schaltfläche schwebt in der oberen Ecke jeder Portalseite – rechts auf Englisch, links auf Persisch und Arabisch –, und sobald ein Besucher sie zum ersten Mal drückt, gilt seine Wahl von da an: Der Browser merkt sie sich, und die dunkle Voreinstellung widerspricht nie jemandem, der sich bereits entschieden hat.
Sie können trotzdem einen eigenen Schalter zeichnen. setTheme("light") und setTheme("dark") stehen
jedem Handler auf einem gezeichneten Bildschirm zur Verfügung, und eine Schaltfläche, die Sie zeichnen,
wirkt auf dieselbe Einstellung wie die in der Ecke. Die in der Ecke ist die Grundausstattung, damit ein
Portal lesbar ist, bevor jemand daran denkt, eine zu zeichnen.
Und die Zeichnung passt sich an. Ein Bildschirm wird in einer bestimmten Größe gezeichnet, aber nicht in dieser Größe angezeigt: Blöcke, die sich über die Seite erstrecken, behalten ihren Abstand zu jedem Rand und geben in der Mitte nach, und nebeneinander gezeichnete Elemente behalten ihren Anteil an der Breite. So passt ein Portal in jedes Fenster, in dem es geöffnet wird, bei jeder Breite, und nichts ragt über die Seite hinaus.
Was diese Anpassung nicht kann, ist Umordnen. Zwei nebeneinander gezeichnete Spalten bleiben nebeneinander – auf einem Mobiltelefon sind es zwei schmale Spalten, nicht eine Spalte mit der zweiten darunter. Ist ein Portal auf Telefonen wichtig, zeichnen Sie einen Bildschirm für ein Telefon: Dafür sind die drei Beispiele A portal on a desktop / tablet / phone da.
Zur Adresse
Eine Adresse antwortet für ein Portal, in der gesamten Installation. Nicht eine pro Umgebung – eine insgesamt. Vor allen Umgebungen steht eine einzige Eingangstür, und sie entscheidet anhand der Adresse, wohin eine Anfrage geht.
Das hat eine Folge, der Sie beim ersten Befördern einer Lösung begegnen werden:
Importieren Sie dieselbe Lösung in Test oder Produktion, antwortet die Adresse, die sie verlangt, bereits für die Umgebung, in der Sie sie gebaut haben. Das Portal kommt daher ohne Adresse und ausgeschaltet an und erscheint in dieser Liste als Braucht eine Adresse.
Das ist kein Fehler, und mit Ihrer Lösung ist nichts schiefgegangen. Ihr Entwicklungsportal und Ihr Produktionsportal brauchten ohnehin verschiedene Adressen. Öffnen Sie das Portal in der neuen Umgebung, geben Sie ihm die gewünschte Adresse und aktivieren Sie Veröffentlicht.
Ein Portal kann auch unter einer Adresse antworten, die Ihrer eigenen Organisation gehört –
portal.acme.com –, die Sie unter Ihre eigenen Domains hinzufügen und deren Besitz Sie dann
nachweisen. Siehe Eine eigene Domain verwenden.
Ein- und ausschalten
Veröffentlicht ist das einzige Kästchen im Erstellerportal, dessen „ein“ bedeutet: Jeder auf der Welt, der die Adresse kennt, kann das sehen. Daher gilt:
- Es beginnt ausgeschaltet und bleibt es, bis Sie es einschalten.
- Es lässt sich nicht einschalten, solange das Portal keine Adresse hat – es gäbe keinen Ort zum Antworten. Eine eigene Domain zählt aus demselben Grund erst als Adresse, wenn sie verifiziert ist: Unter einer nicht verifizierten antwortet nichts.
- Ausschalten lässt die Adresse sofort nicht mehr antworten. Die veröffentlichte App bleibt unberührt.
Ein Portal löschen
Das Löschen eines Portals lässt die Adresse nicht mehr antworten und gibt sie für anderes frei. Die App wird nicht gelöscht – die Zeichnung bleibt eine App, die Ihre eigenen Leute in der Shell öffnen können; genau deshalb ist Veröffentlichen etwas anderes als Zeichnen.