Si alguna vez has construido una aplicación JavaScript moderna dentro de un Web Viewer de FileMaker que llama a las APIs de FileMaker Server — como OData o la Data API — directamente mediante fetch(), casi con seguridad te has topado con el clásico muro del navegador:

Preflight response is not successful. Status code: 405
Fetch API cannot load https://fms.example.com/fmi/odata/v4/... due to access control checks.

Detrás de ese único error se esconde un problema de dos cabezas:

1. Cross-Origin Resource Sharing (CORS): tu página del Web Viewer y la API de FileMaker Server viven en orígenes distintos (o en puertos/protocolos diferentes), y la configuración Apache por defecto de FMS no responde a las peticiones preflight OPTIONS ni refleja el origen de tu aplicación.
2. Confianza TLS / SSL: FileMaker Server exige HTTPS para OData. En una red interna donde el puerto 80 no está disponible o ya lo ocupa otro servidor, conseguir un certificado válido en FMS — o confiar en un certificado autofirmado en cada dispositivo cliente — se convierte rápidamente en un quebradero de cabeza de mantenimiento.

Tres salidas probadas #

En nuestra nueva guía de código abierto, fms-cors-proxy, desglosamos las tres arquitecturas prácticas para resolverlo limpiamente en FileMaker Server.

1. El proxy inverso de mismo origen (nginx delante de FMS) #

Si ya tienes un servidor web principal en tu red con los puertos 80/443 y un certificado válido de Let’s Encrypt, coloca nginx delante de FileMaker Server:

• Sirve tu aplicación del Web Viewer directamente desde nginx.
• Haz proxy inverso de las peticiones /fmi/ internamente hacia FileMaker Server con proxy_ssl_verify off.

Como el navegador solo habla con nginx en un único dominio con un certificado válido, CORS desaparece por completo, fetch() funciona directamente en todos los clientes (FileMaker Pro, Go y WebDirect), y FMS puede conservar intacto su certificado autofirmado por defecto.

👉 Abre el mapa interactivo del proxy inverso — sigue cada petición desde el navegador, pasando por nginx, hasta FileMaker Server, paso a paso.

2. Configuración CORS directa en FileMaker Server (httpd.conf) #

Cuando tu aplicación web realmente necesita vivir en un host separado, tienes que abrazar las peticiones cross-origin. Nuestra guía recorre las reglas exactas de <Location "/fmi"> necesarias en la configuración Apache de FileMaker Server (httpd.conf y httpd.conf.2.4), incluyendo:

• Reflejar orígenes LAN de confianza (con números de puerto).
• Permitir las cabeceras que requiere fms-odata-js (odata-version, Prefer, Authorization, etc.).
• Devolver 200 OK en las peticiones preflight OPTIONS en lugar de 405 Method Not Allowed.
• Recargar el Apache de FMS de forma limpia mediante launchctl kickstart sin reiniciar el servidor de base de datos.

👉 Abre el mapa interactivo de CORS/Apache — recorre todo el flujo de preflight y respuesta en FileMaker Server.

3. Let’s Encrypt DNS-01 automatizado en FMS #

¿Quieres que el propio FileMaker Server sea el único endpoint con un certificado válido tanto en HTTPS (443) como en las conexiones de clientes FileMaker (5003), sin abrir el puerto 80 a internet? También enlazamos con nuestro repositorio hermano, fms-letsencrypt-dns01, que automatiza la emisión y renovación de certificados DNS-01 directamente en FMS — lo cubrimos en profundidad en nuestra entrada anterior.

Lee la guía completa y descarga las plantillas de configuración #

Tanto si quieres eliminar CORS con un bloque nginx de 15 líneas como si prefieres arreglar los preflights de Apache directamente en FileMaker Server, el repositorio incluye instrucciones paso a paso, comandos curl de verificación, tablas de resolución de problemas y plantillas de configuración listas para usar.

👉 Echa un vistazo a fms-cors-proxy en GitHub