Como importar envíos de formularios públicos nunha rede privada

Un formulario público que nunca fala coa rede privada produce igualmente datos que a rede privada debe xulgar. O túnel só cambia quen chama a quen. Todo o que vén despois da descarga é unha decisión de importación e pertence ao lado privado. Este percorrido segue un envío desde o navegador ata un rexistro interno consolidado.

Comeza onde aterra o envío

O navegador publica nun punto de conexión público, que escribe unha fila nun almacén de entrada controlado e non devolve máis ca un acuse de recepción. Ese almacén é o punto de entrega e debería ser o único no que a capa pública pode escribir. Mantén alí a carga orixinal sen cambios, xunto coa hora de chegada e un identificador de rexistro estable.

Despois, un traballador privado extrae as filas pendentes polo túnel e decide que facer con cada unha. Execútase baixo a súa propia identidade, que é o tema da sección seguinte.

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

Dállle ao importador só a autoridade que necesita

O proceso web público e a identidade que escribe na aplicación interna deberían ser dous suxeitos distintos. Un servidor público non necesita administración interna só porque teña que entregar datos de formulario, e unha única conta compartida para ambos os dous lados converte calquera fallo web nunha escritura interna. Emite para o traballador a súa propia credencial, limítaa á única operación de importación e rexistra que suxeito realizou cada importación. Esa separación é o que fai que a fronteira do túnel sexa significativa e non decorativa.

Limita tamén de que fonte pode ler o traballador. Se a implementación usa unha cola ou un servizo de transferencia, ese servizo conserva a súa propia autenticación e política de acceso, porque a VPN non autentica nada dentro da carga.

Unha función de curta duración non está exenta da mesma revisión. Mentres se executa, a súa posición de rede e as súas credenciais aínda outorgan autoridade, e unha vida máis curta só estreita a xanela. A duración non substitúe a decisión sobre que operacións pode realizar a identidade.

Valida antes de que cambie algo interno

Os campos dos formularios públicos son texto controlado polo atacante ata que se demostre o contrario, e as directrices de validación de entrada de OWASP inclúen os fluxos do backend entre as fontes non fiables exactamente por ese motivo. Un transporte cifrado di que os bytes chegaron intactos, non que describan unha petición permitida. Analiza e valida antes de calquera paso privilexiado, para que unha fila defectuosa nunca chegue a unha ruta de código que poida actuar.

Define os campos permitidos, os seus formatos, os seus tamaños e as regras de negocio que se deben cumprir. Unha data pode estar ben formada e aínda así ser incorrecta para a operación solicitada, e unha carga que nomea unha conta interna ou un estado de aprobación non debe poder concederse ningún dos dous.

Envía as filas rexeitadas a un resultado de revisión en lugar de adiviñar unha corrección ou reenvialas a un intérprete de ordes ou a unha interface directa de base de datos. Rexistra o identificador do rexistro e a regra que fallou, non todos os campos que escribiu o solicitante.

Crea un punto de reintento nunha soa operación

Se o rexistro submission-1042 se extrae dúas veces porque se perdeu o primeiro acuse, o traballador necesita unha forma duradeira de recoñecer o rexistro de orixe e o seu resultado consolidado. Unha programación que executa a tarefa unha vez non demostra que cada fila se aplicase unha vez. A entrega duplicada é normal, así que o deseño debe absorbela.

Usa o mecanismo propio de transaccións e de xestión de duplicados da aplicación interna, e mantén o identificador de orixe, o resultado e o acuse nunha secuencia coherente. Confirma só despois de que a operación prevista estea consolidada ou asignada de forma duradeira, e nunca borres a fila de entrada só porque se descargasen os bytes.

Despois demóstrao con tres ficheiros de proba: unha fila válida, unha fila mal formada e o mesmo identificador de orixe controlado entregado dúas veces. Cada un pasa polo mesmo punto de conexión que usa o traballador.

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

As dúas primeiras filas deben rematar en estados internos distintos, e a terceira debe devolver o identificador xa consolidado para ese rexistro de orixe en lugar de crear un segundo. Calquera outra cousa significa que a importación aínda non é repetible.