Skip to main content
Una fila en app_template es un cuerpo de mensaje aprobado. Una plantilla es texto fijo con placeholders, así que Your code is {#var#} aprueba el mensaje y no un código específico.

​
El fallo es una plantilla que se guarda limpiamente y no empareja nada

El contenido es fail-closed. “No empareja nada” no significa que la plantilla se ignore. Significa que el cliente deja de enviar, y parece que nada está mal desde todos los ángulos excepto el suyo.
{code} no es un placeholder. No tiene # dentro, así que es texto ordinario: la plantilla aprueba una única cadena exacta que contiene llaves y rechaza cada mensaje real. Nada en la fila parece mal, porque nada en ella está mal. Aprueba algo que ningún cliente enviará jamás.La vista previa del panel existe para este único error. Muestra un mensaje de ejemplo que la plantilla acepta, construido por el mismo escáner que usa el emparejador del gateway, así que una plantilla que aprueba llaves literales es visible en el momento en que se escribe en lugar de en un ticket de soporte una semana después.
Los casi-fallos se comportan de manera diferente en los dos lados, deliberadamente:
El gateway solía rechazar de plano un placeholder mal formado, lo cual suena más seguro y no lo era: el loader descarta una plantilla que no puede compilar, así que un operador veía una plantilla aprobada en el panel mientras cada mensaje que cubría era rechazado. Estricto en autoría, tolerante pero ruidoso al cargar es la regla. El trabajo del panel es impedir que la fila se escriba; el trabajo del gateway sobre una fila ya en la base de datos es mantener a la cuenta enviando y decir qué hizo.

​
Los tres placeholders, escritos exactamente

Escribe el token en minúsculas sin espacios dentro. Esa es su ortografía y no dice nada sobre lo que acepta. {#alp#} toma espacios, apóstrofes, guiones y puntos, así que your login, Priya Sharma, O'Brien, Anne-Marie y St. John todos coinciden. Tanto el apóstrofe y guion ASCII como los tipográficos se aceptan, porque los tipográficos son los que sobreviven a un pegado desde un PDF. Lo que aún rechaza son los dígitos, y esa es toda la razón para elegirlo sobre {#var#}. Un placeholder tipado es estrictamente más ajustado que {#var#}. Mismo límite de longitud, menos caracteres permitidos. Así que elegir uno solo puede estrechar lo que una plantilla acepta.

​
Cuánto puede representar un placeholder

Una variable empareja de 1 a 30 caracteres por defecto.
Subir smsg.whitelist.max.variable amplía cada plantilla aprobada del despliegue a la vez. Es global en lugar de por listener porque las plantillas se compilan una vez al cargar en un índice por cuenta, así que no hay dónde ponerlo por cliente. Un valor subido para el nombre largo de comerciante de un cliente afloja las aprobaciones de todos los demás clientes en la misma cantidad.Es el mayor falso-positivo de aceptación en este diseño, por eso se registra en INFO y se reporta como max_variable en /ops/health. Un valor fuera de 1–1000 vuelve al valor por defecto con un WARN.
max_variable en la salida de health también es la respuesta a “el ajuste se ha cambiado y no ha pasado nada”. Reporta el tope realmente en vigor, así que un sondeo de configuración que aún no ha aterrizado es visible en lugar de conjeturado.

​
El espacio en blanco se compara plegado

Cualquier secuencia de espacios, tabs, saltos de línea, CRLF o espacios no separables cuenta como un único espacio en ambos lados, y ambos extremos se recortan. Así que una plantilla registrada con un salto de línea antes de su firma coincide con tráfico que envía un espacio ahí. El plegado nunca une dos palabras: una plantilla que aprueba foo bar aún no puede ser satisfecha por foobar.
Esto es solo comparación. El mensaje enviado al operador es byte por byte lo que llegó, y la plantilla almacenada es byte por byte lo que se pegó. Que es contra lo que el registro DLT es auditable. La vista previa del panel muestra el texto plegado, deliberadamente, así que un operador que pegó un cuerpo lleno de espacios no separables ve lo que realmente se comparará.

​
Lo que el panel se niega a guardar

Una cosa se avisa en lugar de rechazarse: una plantilla cuyo texto literal entre dos placeholders se repite más tarde en el cuerpo. El emparejamiento greedy puede rechazar un mensaje que un motor con backtracking aceptaría. Tal plantilla suele seguir siendo correcta, y este es el único modo de fallo invisible del emparejador, así que el objetivo es hacerlo visible en lugar de bloquearlo.

​
Plantillas y mensajes multi-segmento

En el ingreso SMPP un submit_sm que lleva una cabecera de segmento no se comprueba de contenido. Un segmento lleva un fragmento del cuerpo, así que el contenido aún no puede juzgarse. Un emparejamiento de plantilla tampoco es por tanto lo que estampa esa PDU.
Un TLV obligatorio suministrado solo por una plantilla puede no llegar a un mensaje concatenado. Si el tag que un operador necesita viene solo de la fila de plantilla, y nada en la credencial lo suministra, el camino por segmento no tiene nada que estampar. Y un listener que requiera ese tag rechaza. Pon el tag que el operador requiere también en el defaultTlvs de la credencial, donde se aplica a cada PDU independientemente del emparejamiento.
El informe de cobertura de TLV del panel dice, por fila aprobada, qué tags obligatorios no suministrará nada. Consulta Sender IDs.

​
Aprobación, y lo que cuesta una edición

Todo lo que un cliente envía desde el portal llega como PENDING. El gateway sirve una fila solo cuando está enabled y APPROVED. Desde el gateway 0.9.8, un cliente que lee la API de registros es informado cuando una fila está aprobada pero desactivada. Consulta Sender IDs, donde se explican las mismas dos columnas.
Editar una plantilla aprobada la suspende. Cambiar el nombre, el texto, la nota o el login vuelve a poner la fila en PENDING y borra la revisión anterior, así que queda fuera de servicio hasta que alguien la apruebe de nuevo. Y en una cuenta fail-closed eso significa que el tráfico del cliente se detiene hasta entonces.Eso es lo que la aprobación existe para detener: cambiar la redacción aprobada bajo una aprobación existente. Proponer TLVs es la única excepción, porque nada en el camino del mensaje lee la columna propuesta.
No hay clave natural en app_template, así que un cuerpo duplicado se detecta en el código en lugar de por una restricción: pedir de nuevo un texto ya solicitado o aprobado se rechaza con un mensaje que dice cuál, en lugar de convertirse en una segunda fila que nadie puede distinguir de la primera.

Sender IDs

La otra mitad de la misma aprobación, y el informe de cobertura de TLV.

Referencia de whitelisting

Cada propiedad, los tres modos de estampado, y la comprobación obligatoria por proveedor.