Publicar una aplicación como portal
Objetivo
Tomar una aplicación que ya ha dibujado y darle una dirección web propia, para que personas que no pertenecen a su organización (clientes, solicitantes, el público) puedan abrirla sin iniciar sesión en la plataforma.
Antes de empezar
Necesita dos cosas, y el portal no se guardará sin la primera:
- Una aplicación de Studio. Un portal publica un dibujo; no lo contiene. Consulte Crear una aplicación de Studio.
- Una API personalizada para todo lo que lea el portal. Un portal nunca lee una tabla directamente; consulte Qué puede leer un portal más abajo para saber por qué. Si su portal solo muestra texto e imágenes, puede saltarse esto.
Pasos
- Abra su solución y elija Portales.
- Pulse Nuevo.
- Asígnele un nombre. Es como lo llamarán usted y sus compañeros; no es lo que ven los visitantes, porque todo lo que ve un visitante está dibujado.
- Elija la aplicación que se publica en la lista. Solo aparecen las aplicaciones de este entorno.
- Escriba una dirección web. Solo la primera parte:
acme-support, no la dirección entera. El resto de la dirección pertenece a su implementación de Parsware, y la indicación bajo el cuadro muestra cómo quedará la dirección final. - Elija quién puede abrirlo. Cualquiera significa que la dirección abre directamente su aplicación; Personas que inician sesión pone delante un formulario de inicio de sesión; consulte Pedir a los visitantes que inicien sesión.
- Marque qué puede leer: las API personalizadas a las que este portal puede llamar.
- Elija como quién actúan los visitantes: los roles de seguridad que tiene cada visitante de este portal. Consulte Qué tablas puede tocar un portal.
- Deje Publicado sin marcar mientras sigue trabajando, y márquelo cuando quiera que la dirección empiece a responder.
- Pulse Guardar.
Qué puede leer un portal
Un portal lee a través de las API personalizadas que usted enumere, y a través de nada más. No puede leer una tabla directamente, y no hay ningún ajuste que se lo permita.
Es deliberado. Dibujar una pantalla nunca debería convertirse en una manera de publicar por accidente una tabla en internet. Una API personalizada es algo que alguien escribió a propósito: decide lo que puede ver un desconocido, en un script que usted puede leer. Una tabla no es más que una tabla.
Así que, si una pantalla de su portal necesita datos, el orden es: definir la API personalizada, marcarla en la lista del portal y hacer que la pantalla lea a través de ella.
Nombrar la API en la pantalla
Una pantalla de portal nombra el contrato que lee, en lugar de una tabla:
loadRecords("api:par_articles@1", "articles", { top: 20, orderBy: "par_name" })
api: indica que es una API personalizada; par_articles es su nombre lógico; @1 es su
versión, porque dos versiones de una misma API son dos contratos distintos. La misma forma sirve
para getRecord, createRecord, updateRecord y deleteRecord: la función a la que llame
decide lo que hace la plataforma, y el verbo de la propia API tiene que poder responder a ella.
Un createRecord dirigido a una API que solo lee fallará cuando la pantalla lo ejecute.
En la lista de aplicaciones, una pantalla dibujada lee sus tablas directamente: es lo que hace
la aplicación de una persona que ha iniciado sesión, y por eso puede paginar y filtrar. En un
portal no existe esa puerta. Así que una pantalla que nombra api: se abre en el portal y se
niega a hacerlo en el Shell, diciéndolo en lugar de mostrar una lista vacía.
Si quiere un mismo dibujo en los dos sitios, necesita dos pantallas. Es el compromiso que la plataforma adoptó deliberadamente: su portal lee a través de un contrato que usted escribió, y el contrato decide lo que ve un desconocido.
Su API debe responder { "rows": [...], "total": 12 } para una lista. Si responde otra cosa,
la pantalla muestra una lista vacía en lugar de un error, así que un error en una API nunca rompe
un portal.
La lista es un permiso, no un mapa. Marcar una API indica que este portal puede llamarla, y nada más. Su pantalla decide cuándo, al nombrarla. Una API que no ha marcado se rechaza aunque una pantalla la pida, y eso es lo que impide que un error en un dibujo se convierta en una puerta.
Escribir requiere visitantes que inicien sesión, o una prueba de verificación. Una API que responde a POST, PATCH, PUT o DELETE solo se puede llamar cuando Quién puede abrirlo est á establecido en personas que inician sesión, porque un portal abierto no tiene a quién atribuir un cambio. La única manera de evitarlo es la de la sección siguiente.
Pregunte a quien administre su instalación de Parsware si se ha concedido al host del portal el ámbito que exige su API personalizada. Cada API personalizada nombra uno, y el host del portal es quien lo tiene en nombre de sus visitantes: sin él, todas las lecturas se rechazan y la página simplemente no muestra nada.
Qué tablas puede tocar un portal
Las API personalizadas que marque indican a qué contratos puede llamar una página. Los visitantes actúan como indica qué tablas pueden leer y escribir después esos contratos: los mismos roles de seguridad que da a sus propios compañeros, con las mismas concesiones.
Dé a un portal un rol propio que conceda exactamente lo que necesitan sus API (Leer y Crear sobre Casos, por ejemplo) en lugar de un rol que use su personal. Todos los visitantes del portal lo tienen, hayan iniciado sesión o no.
Si no elige ninguno, el portal no llega a nada. Sus listas están vacías y cada guardado dice No se pudo guardar. Es la opción segura, y es lo primero que hay que comprobar cuando un portal no muestra nada en una página que parece correcta.
En un portal en el que los visitantes inician sesión, el rol no es lo único. Si la tabla tiene una regla que dice de quién es cada fila (consulte Decidir qué registros ve un visitante), cada visitante queda limitado a las filas de su propia empresa después de que el rol le haya dejado entrar.
El rol de administrador de la plataforma nunca se ofrece aquí. Un visitante que lo tuviera tendría el entorno entero.
Permitir que cualquiera le envíe algo
Marque Permitir que cualquiera le envíe cosas (solo aparece mientras Quién puede abrirlo está en Cualquiera) y un visitante sin cuenta podrá escribir, siempre que su navegador dedique antes un momento a un pequeño desafío que demuestra que no es un script.
Esto es lo que hace posible un formulario de contacto. Sin ello, un portal que cualquiera puede abrir puede leer pero no escribir, lo que obliga a pedir a alguien que cree una cuenta antes de poder enviarle un mensaje, y eso no es un formulario de contacto.
No hay nada que dibujar ni nada que tenga que hacer el visitante. Ninguna casilla que marcar, ninguna palabra deformada que leer, ninguna foto de semáforos. La plataforma da al navegador un pequeño cálculo; un portátil lo termina antes de que se note, y un teléfono antiguo tarda un momento y muestra Comprobando que es una persona… bajo el botón mientras trabaja. No se recoge nada sobre el visitante, y nada de la página viene del servidor de otra empresa.
Lo que frena y lo que no. Encarece los envíos masivos: un script que podía enviar mil formularios por hora ahora paga trabajo real por cada uno, así que en la práctica envía cuarenta. No frena a alguien decidido que esté dispuesto a usar navegadores reales, y ninguna casilla de ningún sitio lo frena, se llame como se llame. Trátelo como un filtro de spam con dientes, no como un candado.
Tres cosas que no cambia:
- Lo que se puede llamar. Solo las API personalizadas que marcó arriba, exactamente igual que antes.
- Lo que se puede escribir. El esquema de solicitud de la propia API sigue decidiendo qué campos puede establecer un visitante. Un contrato que acepta un asunto y un mensaje acepta un asunto y un mensaje.
- Quién es cada uno. Nadie ha iniciado sesión, así que no se verifica nada. Si su API guarda una dirección de correo que escribió el visitante, es una dirección que alguien escribió. Cuando eso importe, pida a los visitantes que inicien sesión.
portal-contact-form en samples/solutions/ es exactamente esto: un portal abierto, una
escritura, un archivo adjunto a ella y una página en el propio sitio que explica qué mirar.
Abrirlo
Cuando un portal tiene dirección, la lista la muestra como un vínculo, y Abrir portal en la barra de comandos la abre en una pestaña nueva. Abra el portal para editarlo y la misma dirección aparece bajo el cuadro Dirección web, con dos pequeños botones al lado: uno abre el portal, para cuando quiera verlo, y otro copia la dirección, para cuando vaya a enviársela a otra persona. Ninguno muestra texto (la dirección es larga, y unas etiquetas al lado empujarían el segundo botón a otra línea), así que pase el puntero por encima de cualquiera de ellos y le dirá cuál es.
La dirección solo aparece cuando se ha guardado. Mientras sigue escribiendo una etiqueta, la indicación bajo el cuadro muestra cómo será la dirección final; un vínculo construido con algo que todavía no ha guardado apuntaría a un portal que no existe.
Si su instalación no sirve portales, no hay dirección que abrir y la indicación se queda donde estaría el vínculo. Pregunte a quien administre su instalación de Parsware.
Esa frase nunca trata sobre su portal: es la plataforma diciendo que no pudo responder, y su dibujo, su dirección y el interruptor Publicado no tienen nada que ver. Es una de dos cosas, y las dos corresponden a quien administra su instalación: los servicios están caídos, o el host del portal no puede obtener una credencial de Parsware. Una dirección incorrecta dice algo muy distinto («Aquí no hay nada publicado»), así que puede distinguirlos por la propia página.
Qué ve un visitante
Dos cosas de una página de portal son de la plataforma y no suyas, y conviene conocerlas antes de que alguien le pregunte por ellas.
Un portal se abre en modo oscuro. Sus propias aplicaciones de Parsware se abren en modo claro, porque es donde pasa una jornada de trabajo; un portal es donde llega un desconocido desde un vínculo en un mensaje, normalmente en un teléfono, y el modo oscuro es una primera impresión más amable. En la esquina superior de todas las páginas del portal flota un pequeño botón claro/oscuro (a la derecha en español, a la izquierda en persa y en árabe), y la primera vez que un visitante lo pulsa, esa es su elección a partir de entonces: el navegador la recuerda, y el modo oscuro predeterminado nunca contradice a quien ya ha respondido.
Aun así, puede dibujar su propio interruptor. setTheme("light") y setTheme("dark") están
disponibles para cualquier controlador de una pantalla dibujada, y un botón que dibuje y el de la
esquina actúan sobre el mismo ajuste. El de la esquina es el mínimo, para que un portal sea legible
antes de que a nadie se le ocurra dibujar uno.
Y el dibujo se redistribuye. Una pantalla se dibuja con un tamaño, pero no se muestra con ese tamaño: los bloques que ocupan todo el ancho de la página conservan su separación con cada margen y dejan que ceda el centro, y los elementos dibujados uno junto a otro conservan su parte del ancho. Así, un portal se ajusta a la ventana en la que se abre, con cualquier ancho, y nada se sale de la página.
Lo que la redistribución no puede hacer es reorganizar. Dos columnas dibujadas una junto a otra siguen una junto a otra: en un teléfono son dos columnas estrechas, no una columna con la segunda debajo de la primera. Si un portal importa en los teléfonos, dibuje una pantalla para teléfono: para eso están los tres ejemplos Un portal en escritorio / tableta / teléfono.
Sobre la dirección
Una dirección responde a un único portal en toda la instalación. No una por entorno: una en total. Hay una única puerta de entrada delante de todos los entornos, y decide adónde va una solicitud mirando la dirección.
Eso tiene una consecuencia con la que se encontrará la primera vez que promueva una solución:
Importe la misma solución en Prueba o en Producción y la dirección que pide ya está respondiendo para el entorno en el que la construyó. Así que el portal llega sin dirección y desactivado, y aparece como Necesita una dirección en esta lista.
No es un error, y no le ha pasado nada a su solución. Su portal de desarrollo y su portal de producción siempre iban a necesitar direcciones distintas. Abra el portal en el nuevo entorno, dele la dirección que quiera allí y marque Publicado.
Un portal también puede responder en una dirección que sea propiedad de su organización
(portal.acme.com), que se agrega en Sus propios dominios y cuya propiedad se demuestra
después. Consulte Usar su propio dominio.
Activarlo y desactivarlo
Publicado es la única casilla del portal de creadores cuyo «activado» significa cualquier persona del mundo que conozca la dirección puede ver esto. Así que:
- Empieza desactivado, y sigue así hasta que usted lo active.
- No se puede activar mientras el portal no tenga dirección: no habría dónde responder. Un dominio propio solo cuenta como dirección cuando está verificado, por el mismo motivo: en uno sin verificar no responde nada.
- Desactivarlo hace que la dirección deje de responder de inmediato. La aplicación que publica no se toca.
Eliminar un portal
Eliminar un portal hace que la dirección deje de responder y la deja libre para otra cosa. No elimina la aplicación: el dibujo sigue siendo una aplicación que su propio personal puede abrir en el Shell, y esa es precisamente la razón de que publicar sea algo distinto de dibujar.