Datos y Formularios

Una App publicada es estática. Todo lo vivo que tiene — una lista de productos, los pedidos de un miembro, un formulario enviado — se pide desde el navegador a través del API Gateway. Esta página trata de cómo se arma esa conexión, y de la única regla que la mantiene segura.

La configuración de runtime

Una App lleva un bloque chico de configuración que su shell publicado busca al arrancar. Ese bloque tiene:

El sitio publicado lo busca por subdominio, contra un endpoint anónimo, y solo devuelve valores seguros para un navegador. Nada secreto forma parte de esto, porque todo lo que hay ahí está a un Ver código fuente de ser leído.

Por qué existen los mapas

Podrías escribir el id de una tabla dentro de una página. Después copiás la App a un segundo workspace para un cliente, y todos los ids están mal.

Los mapas te dan un nivel de indirección. Tus páginas piden productos; la configuración dice qué id de tabla significa eso acá. La misma App, apuntada a la configuración de otro workspace, funciona sin editar una sola página.

Nombrá las claves lógicas por lo que significan para el sitio, no por el título actual de la tabla. productos, posts, equipo — esos siguen siendo correctos cuando alguien renombre la tabla.

La credencial

Una App puede generar su propia credencial de gateway, y conviene dejar que lo haga: la clave generada queda acotada a exactamente las tablas mapeadas en ese momento y atada al origen de la App.

Las dos mitades importan:

• Acotada a las tablas mapeadas significa que la clave no puede leer una tabla que el sitio nunca menciona. Tu tabla de pedidos sigue invisible para la clave de un sitio de marketing, aunque las dos vivan en el mismo workspace.

• Atada al origen significa que la clave es inútil desde cualquier lado que no sea tu sitio. Quien la copie del código fuente de tu página no puede usarla desde la suya.

Si más adelante mapeás una tabla nueva, regenerá la clave. Si no, el sitio pide algo que la clave no tiene permitido ver y el pedido se rechaza — lo que parece un bug y en realidad es la protección funcionando.

Qué puede hacer una clave publicable

Una clave pk_ es pública por diseño. Cualquiera que abra tu sitio puede leerla, así que tratala como publicada desde el momento en que desplegás.

Eso está bien, siempre que sus permisos sean honestos al respecto. Los scopes que lleve deberían ser los que estarías cómodo imprimiendo en un cartel: lectura sobre tablas públicas, inserción sobre la tabla que hay detrás de un formulario de contacto. No actualización. No borrado. No las tablas con datos de personas.

¿Estaría cómodo si un desconocido hiciera exactamente este pedido a mano? Si no, ese permiso no va en una clave publicable.

Todo lo que no pondrías en un cartel va detrás de una automatización: la App llama al endpoint, la automatización hace el trabajo con una clave de servidor que el navegador nunca recibe, y devuelve solo la respuesta.

Leer datos

Con la configuración puesta, una página consulta al gateway con PraxQL — el mismo lenguaje de consulta que usa el resto de la plataforma, documentado en API Gateway. Una página de colección corre una consulta y renderiza las filas; una de detalle corre una consulta para una fila.

El filtrado, el orden y la paginación ocurren en la consulta, no en la página, lo que significa que una lista de diez mil filas nunca se convierte en diez mil filas de HTML.

Formularios

Los formularios no son un motor aparte dentro de Apps. Un bloque de formulario embebe un formulario de Praxsuite, y los envíos caen donde caen todos los envíos de ese formulario — la misma tabla, las mismas automatizaciones, las mismas notificaciones.

Esta es la parte que la gente suele reconstruir sin querer. Si el formulario ya existe en el workspace, la App debería embeberlo en vez de insertar filas por su cuenta: así obtenés validación, el registro del envío y cualquier automatización conectada, gratis.

Contenido que solo ven algunos visitantes

En una App privada o mixta, un visitante autenticado tiene un token de end user. Los pedidos hechos con ese token se filtran según los roles de gateway de esa persona — así que "mostrame mis pedidos" no es un filtro que aplica tu página, es un filtro que aplica el gateway antes de responder.

Esa distinción es todo el modelo de seguridad. Una página que trae todo y esconde las otras filas en el navegador no escondió nada: los datos ya estaban en la respuesta. Dejá que el filtro de fila del rol haga el trabajo.

La regla

Nada secreto entra en una App. Ni una API key de un servicio de terceros, ni una clave de servidor del gateway, ni un token, ni una contraseña, ni una cadena de conexión. Una App publicada es un conjunto de archivos que cualquiera puede descargar y leer, incluidos los que tu build nunca pensó que fueran interesantes.

Cuando una página necesita hacer algo con un secreto, llama a una automatización que guarda el secreto en el Vault, y recibe solo el resultado.

Siguiente

• Publicación y versiones — sacar el sitio a producción

• PraxQL — el lenguaje de consulta que usan las páginas para leer datos

• Credenciales y principales — qué es una clave publicable, completo

• Automatizaciones — dónde va el trabajo del lado del servidor