Ten en cuenta que en las ciencias informáticas un error casi siempre tiene diversas soluciones, no obstante aquí te compartimos lo mejor y más óptimo.
Solución:
Después de horas de depuración, finalmente encontré el problema; Como estaba jugando con la configuración de mi servidor XMPP, había vuelto a generar los certificados SSL para XMPPd. Como estaba usando certificados autofirmados, esto causaría un error de SSL. Debido a que había visitado ese mismo URI a través de HTTPS anteriormente, ya había aprobado manualmente el antiguo certificado autofirmado, pero obviamente esa aprobación ya no era válida después de regenerar el certificado SSL.
El key al problema es este: Si su certificado SSL genera una advertencia de cualquier tipo, wss:// Las conexiones de WebSocket fallarán inmediatamente y no hay una forma canónica de detectar esto.
Como se indicó anteriormente, no parece haber una forma estandarizada de detectar siquiera que este problema está ocurriendo, y mucho menos resolverlo. La mejor solución a este problema que he podido encontrar, es la siguiente:
- Si el WebSocket se desconecta antes de haber recibido una confirmación de inicio de sesión (específico de XMPP), intente hacer un texto sin formato
ws://(sin SSL) conexión al puerto no SSL. - Si la conexión de texto sin formato tiene éxito, esto significa que el servidor está activo; por lo tanto, el problema está en el certificado SSL. (Si la conexión de texto sin formato también falla, el servidor simplemente no está disponible).
- Mostrar un error al usuario, indicando que hubo un problema de SSL y que debe verificar el certificado, con instrucciones sobre cómo aprobarlo manualmente.
- Proporcionar una
target="_blank"enlace a lawss://URL, pero reemplazando el protocolo conhttps://. Esto puede ser específico de Prosody, pero al visitar esa URL verá la página de advertencia de SSL. Prosody mostrará un texto que comienza con “¡Funciona!” después de aprobar el certificado: si el lado del servidor es una aplicación personalizada, debe mostrar un mensaje que diga que “el problema se resolvió, puede cerrar esta pestaña ahora”. - En segundo plano, en la aplicación principal, siga intentando volver a conectarse a través de wss:// cada pocos segundos. Una vez que la conexión se realiza correctamente, significa que el usuario ha aprobado el certificado. Oculte/elimine el error y continúe con el proceso normal de conexión/inicio de sesión.
Está lejos de ser un proceso fluido, en cuanto a UX, pero es el enfoque más fluido que he encontrado. No es posible iframear la página de error (esta fue una de mis primeras ideas): Chrome se negará a cargarlo, Firefox ocultará el botón “Agregar excepción” y me imagino que otros navegadores exhiben un comportamiento similar.
Recuerde que a los navegadores modernos no les gustan los certificados autofirmados. Por lo tanto, si su seguro WebSocket la conexión muere antes de finalizar el protocolo de enlace, podría significar que el certificado no ha sido aceptado. Para resolver el problema, puede:
- comprar un certificado firmado por una Autoridad Central
- simplemente abra en una nueva pestaña o ventana el enlace de su URI de WebSocket y dígale al navegador que confíe en la conexión. Regrese a su WebSocket y debería funcionar.
Comentarios y valoraciones del artículo
Si te animas, eres capaz de dejar un escrito acerca de qué le añadirías a este post.