Naar hoofdinhoud gaan

Bezoekers wijzigingen laten opslaan

Doel​

Laat iemand op je portal een aanvraag indienen, wijzigen of verwijderen — niet alleen lezen.

Voordat je begint​

  • Een portal waarop Wie kan het openen op Mensen die zich aanmelden staat. Schrijven wordt geweigerd op een portal die iedereen kan openen: er zou niemand zijn aan wie de wijziging kan worden toegeschreven. Zie Bezoekers vragen zich aan te melden.
  • Een aangepaste API voor elk ding dat ze mogen doen. Een API die leest, is geen API die schrijft, en het platform behandelt hem ook niet als beide.

Stappen​

  1. Schrijf de Custom API. Voor aanmaken maakt u het werkwoord POST; voor wijzigen PATCH; voor verwijderen DELETE. Schrijf er een aanvraagschema voor: dat staat als eerste tussen een bezoeker en een kolom die hij niet mag zetten. Zonder schema mag de body van een bezoeker alleen de velden bevatten die uw script met getInput leest; al het andere wordt geweigerd.
  2. Open je oplossing, kies Portals en open de portal.
  3. Druk onder Wat het kan lezen op Iets om te lezen toevoegen en kies:
    • de tabel die je scherm noemt in createRecord / updateRecord / deleteRecord,
    • de bewerking — Een record maken, Een record wijzigen of Een record verwijderen,
    • de API die erop antwoordt.
  4. Druk op Opslaan.

Elk van de vijf dingen die een scherm kan doen, heeft een eigen rij nodig. Een portal die aanvragen kan opsommen, kan er geen maken totdat je ook de rij Maken toevoegt — het zijn twee afzonderlijke contracten, en de pagina kan alleen de tabel noemen.

Wat je scherm doet​

Niets nieuws. Dezelfde acties die je voor een app binnen het platform zou tekenen:

createRecord("par_request", {
  par_name: getState("subject"),
  par_detail: getState("detail")
}, "saved");

Op een portal wordt dat een aanroep van de API die je voor par_request / Maken op de toestemmingslijst hebt gezet. De tekening blijft ongewijzigd — daar draait het juist om bij één app publiceren naar twee plekken.

Wat de API moet doen​

Bepalen wie dit mag doen, en invullen wat de bezoeker niet mag invullen.

var me = portalEmail();
if (me == '') {
  throwValidationError('Sign in before raising a request.');
} else {
  var subject = getInput('par_name');
  if (subject == '') {
    throwValidationError('Please give your request a subject.');
  } else {
    // **The visitor does not get to say who raised it.** Whatever the page sent for this column
    // is ignored; the address comes off their signed-in session.
    var id = createRecord('par_request', {
      par_name: subject,
      par_detail: getInput('par_detail'),
      par_raised_by_email: me,
      par_status: 'New'
    });
    setOutput('record', getRecord('par_request', id));
  }
}

Een bezoeker weghouden uit kolommen die hij niet mag invullen​

De portal stuurt de body precies zoals de pagina hem stuurde door, en kan niet anders: welke velden een bezoeker mag invullen, is een vraag over jouw tabel, en alleen jouw contract kent het antwoord.

Twee dingen beantwoorden die vraag, en je wilt ze allebei.

Je aanvraagschema, dat een veld weigert dat je nooit hebt beloofd. Stel "additionalProperties": false in en noem alleen wat een bezoeker mag sturen:

{
  "type": "object",
  "additionalProperties": false,
  "required": ["par_name"],
  "properties": {
    "par_name": { "type": "string", "minLength": 1, "maxLength": 200 }
  }
}

Een body met par_raised_by_email erin wordt nu geweigerd voordat je script draait.

Elk veld bij naam lezen, zoals het script hierboven doet. getInput('par_name') neemt waar je om vroeg en verder niets.

Geef de body nooit in zijn geheel door

Een script dat de hele body aan createRecord geeft, laat een bezoeker elke kolom invullen waarvan hij de naam kan raden — ook de kolom die zegt van wie het record is. Het schema maakt dat moeilijk; bij naam lezen maakt het onmogelijk.

Wat de bezoeker ziet als het mislukt​

  • Een weigering die jij hebt geschreven — throwValidationError('Please give your request a subject.') — verschijnt naast de knop waarop hij drukte.
  • Al het andere toont een algemene melding "dat kon niet worden opgeslagen", en de echte reden gaat naar het logboek van de portalhost.

Die tweedeling is bewust: jouw zin gaat over hem en hij kan er iets mee, terwijl een interne fout geen van beide is.

Je validatieberichten worden door onbekenden gelezen

Omdat de eerste soort wordt getoond, schrijf je die zinnen voor het publiek. Noem geen kolom, geen tabel en geen interne regel — "Geef je aanvraag een onderwerp" in plaats van "par_name failed constraint NOT NULL".

Wat het platform niet controleert​

Of een bezoeker kan teruglezen wat hij net heeft geschreven. Slaat je Maken-API een record op dat je Query-API wegfiltert, dan bestaat het record wel maar toont de lijst het niet. Niets waarschuwt je: de twee scripts zijn afzonderlijke contracten, en het platform gaat niet twijfelen aan een paar dat je met opzet zo hebt geschreven.

Slaat een scherm iets op en toont het daarna een lege lijst, dan is het meestal dit — vergelijk het filter in je lees-API met wat je schrijf-API heeft opgeslagen.

Het uitzetten​

Verwijder de rij uit Wat het kan lezen, of zet Wie kan het openen terug op Iedereen. Beide houden de portal direct op met schrijven. Het tweede doet dat ook op het moment dat je opslaat, ook al staan de rijen nog in de lijst — een open portal bedient zijn leesacties en geen enkele schrijfactie.

Gerelateerd​