Saltar al contenido principal

Permitir que los visitantes guarden cambios

Objetivo​

Permitir que alguien en su portal abra una solicitud, la cambie o la elimine, y no solo que lea.

Antes de empezar​

  • Un portal en el que Quién puede abrirlo está establecido en Personas que inician sesión. En un portal que cualquiera puede abrir, la escritura se rechaza: no habría nadie a quien atribuir el cambio. Consulte Pedir a los visitantes que inicien sesión.
  • Una API personalizada para cada cosa que puedan hacer. Una que lee no es una que escribe, y la plataforma no la tratará como ambas.

Pasos​

  1. Escriba la Custom API. Para crear, haga su verbo POST; para cambiar, PATCH; para eliminar, DELETE. Escríbale un esquema de solicitud: es lo primero que se interpone entre un visitante y una columna que no debería fijar. Sin él, el cuerpo de un visitante solo puede llevar los campos que su script lee con getInput, y todo lo demás se rechaza.
  2. Abra su solución, elija Portales y abra el portal.
  3. En Qué puede leer, pulse Agregar algo que leer y elija:
    • la tabla que su pantalla nombra en createRecord / updateRecord / deleteRecord,
    • la operación: Crear un registro, Cambiar un registro o Eliminar un registro,
    • la API que la responde.
  4. Pulse Guardar.

Cada una de las cinco cosas que puede hacer una pantalla necesita su propia fila. Un portal que puede enumerar solicitudes no puede crear una hasta que agregue también la fila Crear: son dos contratos distintos, y la página solo puede nombrar la tabla.

Qué hace su pantalla​

Nada nuevo. Las mismas acciones que dibujaría para una aplicación dentro de la plataforma:

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

En un portal eso se convierte en una llamada a la API que incluyó en la lista de permitidos para par_request / Crear. El dibujo no cambia: esa es precisamente la razón de publicar una misma aplicación en dos sitios.

Qué tiene que hacer la API​

Decidir a quién se le permite hacer esto, y rellenar lo que el visitante no debe rellenar.

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));
  }
}

Mantener a un visitante fuera de las columnas que no debe establecer​

El portal reenvía el cuerpo exactamente como lo envió la página, y no puede hacer otra cosa: qué campos puede establecer un visitante es una pregunta sobre su tabla, y solo su contrato conoce la respuesta.

Hay dos cosas que la responden, y conviene tener las dos.

Su esquema de solicitud, que rechaza un campo que nunca prometió. Establezca "additionalProperties": false y enumere solo lo que un visitante puede enviar:

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

Un cuerpo que lleve par_raised_by_email se rechaza ahora antes de que se ejecute su script.

Leer cada campo por su nombre, como hace el script anterior. getInput('par_name') toma lo que pidió y nada más.

Nunca pase el cuerpo entero

Un script que entrega el cuerpo completo a createRecord permite a un visitante establecer cualquier columna cuyo nombre adivine, incluida la que dice de quién es el registro. El esquema lo dificulta; leer por nombre lo hace imposible.

Qué ve el visitante cuando algo falla​

  • Un rechazo que escribió usted (throwValidationError('Please give your request a subject.')) aparece junto al botón que pulsó.
  • Cualquier otra cosa muestra un mensaje general de «no se pudo guardar», y el motivo real va al registro del host del portal.

Esa división es deliberada: su frase trata sobre el visitante y puede actuar en consecuencia, mientras que un error interno no cumple ninguna de las dos cosas.

Sus mensajes de validación los leen desconocidos

Como el primer tipo se muestra, escriba esas frases pensando en el público. No nombre ninguna columna, ninguna tabla ni ninguna regla interna: «Indique un asunto para su solicitud» en lugar de «par_name failed constraint NOT NULL».

Qué no comprueba la plataforma​

Si un visitante puede volver a leer lo que acaba de escribir. Si su API de creación guarda un registro que su API de consulta filtra, el registro existe y la lista no lo muestra. Nada le avisa: los dos scripts son contratos distintos, y la plataforma no va a cuestionar una pareja que usted escribió a propósito.

Si una pantalla guarda algo y después muestra una lista vacía, normalmente es esto: compare el filtro de su API de lectura con lo que guardó su API de escritura.

Desactivarlo​

Quite la fila de Qué puede leer, o vuelva a establecer Quién puede abrirlo en Cualquiera. Cualquiera de las dos cosas impide de inmediato que el portal escriba. La segunda también lo impide en cuanto guarda, aunque las filas sigan en la lista: un portal abierto sirve sus lecturas y ninguna de sus escrituras.

Temas relacionados​