En esta guía se describen los problemas más comunes y las soluciones a la hora de realizar una integración manual basada en API. Tendrás que adaptar estos consejos a tu aplicación y frameworks particulares.
No podemos ofrecer soporte para integraciones personalizadas a través de los canales de soporte habituales, ya que hay muchos factores que escapan a nuestro control. Escribir una integración personalizada es relativamente sencillo, pero es necesario ser un desarrollador experimentado con un buen conocimiento de los elementos esenciales de HTTP.
Para ver ejemplos de integraciones probadas en el mundo real que abordan todos los problemas descritos a continuación, puede revisar nuestras integraciones en GitHub:
- https://github.com/Crowdhandler/crowdhandler-cloudflare-integration
- https://github.com/Crowdhandler/crowdhandler-php-sdk
Problemas de exclusión de URL
Si su aplicación tiene un controlador frontal, puede estar enrutando todas las peticiones a su aplicación a través de una integración que comprueba con CrowdHandler para permitir o denegar peticiones URL individuales. Esto puede dar lugar a los dos problemas siguientes:
1. Comprobación de URL innecesarias
Cuando un usuario carga una página, el navegador cargará todos los activos de página asociados en tu dominio, y es posible que estas peticiones pasen por tu controlador frontal. Esto puede hacer que se realicen comprobaciones innecesarias, lo que añadirá tiempo de carga y, en última instancia, carga de servidor a tu aplicación. Es recomendable excluir al menos estas extensiones de archivo comunes antes de comprobar una URL:
.css. gif .ico .jpg .jpeg .js .json .mov .mp4 .mpeg .mpg .png .svg .ttf .otf .eot .woff .woff2
También debe excluir cualquier otra ruta en sus aplicaciones que esté relacionada con contenido que no requiera protección de sala de espera. Por ejemplo, si almacena todos los activos estáticos en un subdirectorio llamado /static, puede excluir esa ruta de las comprobaciones.
2. Bloqueo de servicios de terceros en la cola
Si está utilizando un controlador frontal como el anterior y tiene servicios de terceros que llaman a API en su dominio protegido, es probable que estos servicios queden atrapados en la cola y no avancen, ya que es poco probable que acepten cookies. Los servicios de terceros más comunes que pueden ser bloqueados incluyen:
- Servicios, plugins o aplicaciones que consumen API en su dominio (RPC, REST)
- Servicios de pago que realizan llamadas al servidor de su dominio para confirmar las transacciones.
Si los servicios utilizan un rango de IPs muy definido, puede permitirles el paso añadiendo el rango de IPs con una regla de bypass. Sin embargo, suele ser preferible excluir estas URL de las comprobaciones.
3. Bloqueo de las URL de administración
Si se conecta a su aplicación backend o CMS a través de urls como /admin puede que desee excluir estas urls también. Puede ser igual de efectivo configurar las IPs de su oficina o VPN para que sean bypass.
Cuestiones relacionadas con las cookies
Tal vez el mayor problema que vemos con las integraciones personalizadas es la imposibilidad de establecer correctamente una cookie para realizar un seguimiento del token CrowdHandler del usuario.
Puede estar utilizando cookies, o puede estar utilizando otra forma de almacenamiento de sesión del navegador o del lado del servidor. Aquí utilizamos cookies como un término general para cualquier método de almacenamiento que utilice para rastrear el token CrowdHandler de los usuarios, pero debe tener cuidado con cualquier medio que esté utilizando para guardar las sesiones.
1. No establecer una Cookie legible
Su integración debe almacenar el token CrowdHandler del usuario la primera vez que es redirigido a su sitio. No puede confiar en que el token esté en la URL después de la primera visita tras la redirección desde la sala de espera. Tendrá que asegurarse de que la cookie está configurada. Asegúrese de que está configurando una cookie que su aplicación pueda leer desde rutas posteriores que el usuario pueda estar visitando.
2. Fallo al establecer Cookie debido a una redirección HTTP
La razón más común por la que una integración falla al establecer una cookie es porque una redirección HTTP atrapa al usuario antes de que su integración se ejecute, y redirige al usuario a una nueva ruta sin pasar el token en la URL. Estas reglas de redirección pueden estar en la configuración de su servidor web, o pueden ejecutarse al principio de su ruta de código para tratar con redirecciones de idioma o de inicio de sesión. Así que si usted está tratando con un sitio multi-idioma, o la protección de una ruta que implica el inicio de sesión del usuario a continuación, tenga especial cuidado. La solución es asegurarse de que las redirecciones incluyen la cadena de consulta con el token, o asegurarse de que no está enviando a los usuarios directamente desde la sala de espera a una url que redirigirá inmediatamente.
Existe un artículo específico en la Base de conocimientos sobre este problema. Léalo para entenderlo mejor. Aunque este artículo está dirigido principalmente a los usuarios de la integración de JavaScript, usted podría recrear este problema en su propia integración.
3. No actualizar la Cookie
Hay razones legítimas por las que un usuario puede encontrarse pasando por la cola más de una vez, o puede que su sesión expire y se emita un nuevo token. Por esta razón, es importante que siempre que veas un token de crowdhandler en la URL, o cuando un nuevo token vuelva de la API, actualices la cookie para que coincida. De lo contrario, su integración puede utilizar un token caducado, enviando al usuario de vuelta a la cola.
Así que en su código de integración, busque un token en la URL. Si encuentra uno, haga la llamada con el token en la URL en lugar de cualquier token que pueda encontrar en una cookie. Entonces, de cualquier manera, confía en el token bien formado que vuelve de la API y establece la cookie.
4. Borrar la cookie o establecer un valor malformado
Al mirar la URL o analizar la respuesta de la API para ver si debe actualizar la cookie del usuario, tenga cuidado de no permitir que un error en algún lugar de su código establezca accidentalmente un valor nulo, vacío o falso. Algunos frameworks interpretarán esto como un borrado de cookie, y en cualquier caso, si el usuario envía un token inválido en su próxima petición se le emitirá un nuevo token, lo que resultará en que sea enviado al final de la cola.
5. No establecer una cookie al redirigir al usuario a la sala de espera.
Estrictamente hablando, no es necesario establecer una cookie si va a redirigir a este usuario a la sala de espera. Sin embargo, su integración será mucho más robusta si siempre establece una cookie. Esto se debe a que el usuario puede encontrarse de nuevo en el sitio de alguna manera antes de completar su viaje a través de la sala de espera. Si aún los reconoce, serán devueltos a la sala de espera, manteniendo su posición original. Si no, serán enviados de nuevo a la sala de espera con una nueva posición al final de la cola. Si un usuario está mucho tiempo en la sala de espera, no es raro que vuelva a probar el sitio, quizá en una nueva pestaña. Sobre todo si han recibido por correo electrónico un enlace a la página protegida.
6. Establecer una fecha de caducidad inadecuada con su cookie, o confiar en el almacenamiento temporal de la sesión.
Considerando el escenario anterior, el típico tiempo de espera de 20 minutos asociado con el almacenamiento de sesión incorporado proporcionado por frameworks como .Net o PHP puede no ser lo suficientemente robusto para este escenario. En caso de duda, utilice una cookie de sesión o una cookie permanente.
Problemas con la API
Tómese su tiempo para comprender los parámetros que envía y las respuestas que puede recibir. Estos son los principales problemas que vemos con las solicitudes y respuestas de API:
1. Envío de una IP errónea a la API
Cuando envíes la IP al recurso de solicitud, asegúrate de que estás enviando la IP del usuario, y no la IP de tu servidor, o la IP de un servidor proxy intermediario. Si envías la misma IP muchas veces, es probable que esa IP sea identificada y bloqueada. Si te enfrentas a esto en un entorno en vivo, puedes establecer esa IP o rango en 'ignorar', lo que evitará el comportamiento de auto-bloqueo, pero debes probar y arreglar tu integración para identificar la IP correcta. Normalmente, si tu servidor web está detrás de un proxy, puedes detectar la IP real a partir de la cabecera HTTP X-Forwarded-For. Puede que esta guía le resulte útil.
2. Suponiendo que la API responda
La razón de ser de CrowdHandler es estar disponible cuando su sitio no lo esté. Sin embargo, hay muchas razones legítimas por las que su servidor puede ser temporalmente incapaz de conectarse a la API de CrowdHandler, incluyendo problemas generales de enrutamiento de Internet o problemas del centro de datos. Si su código presupone que siempre recibirá una respuesta bien formada, es probable que muestre un feo error al usuario cuando se produzcan estas situaciones. Soluciones:
- Al realizar la llamada a la API, especifique un tiempo de espera breve (lo óptimo son 2 segundos)
- Si la llamada se interrumpe, o la respuesta no está bien formada, considere lo que quiere hacer. En la mayoría de los casos usted querrá confiar en este usuario y permitir el acceso a la url, porque esto significa que si la interrupción ocurre mientras usted no está ejecutando una cola el usuario no será interrumpido. En escenarios de baja confianza, es posible que desee enviar al usuario a la sala de espera - la sala de espera CrowdHandler intentará establecer una conexión API y hacer lo mejor que pueda con el usuario hasta que reciba una respuesta bien formada de la API.
3. Presunción del formato de respuesta
En la mayoría de los casos recibirá una respuesta detallada, incluidos los mensajes de la sala de espera, etc. He aquí un ejemplo:
{
"result": {
"status": 1,
"token": "tok_7pDi5dRB2nUi",
"title": "The Herb Girls Reunited!",
"position": 964,
"promoted": 0,
"urlRedirect": null,
"onsale": "2021-12-06T12:20:00Z",
"message": "Booking is very busy right now. We appreciate your patience and will forward you shortly.",
"slug": "herb-girls",
"priority": null,
"priorityAvailable": 1,
"logo": "https://crowdhandler-templates.s3.amazonaws.com/public/94ea09f553bf57af84c21427c68b3c89fc64e2044c347522ba4ca01363ffaf8b/Queen Victoria Hall-logo-2.png",
"responseID": "e0abd8dbb8d2810fad16855622dcd45f",
"captchaRequired": 0,
"rate": 50,
"hash": null,
"ttl": 55
}
}
Sin embargo, algunos estados proporcionan poca información.
Por ejemplo, si comprueba una solicitud de una URL que no está protegida por ninguna sala de espera CrowdHandler.
{
"result": {
"status": 0,
"token": null,
"responseID": null,
"promoted": 1
}
}Otras respuestas que puede ver es si su clave no es válida (un error HTTP 401), si la sala está llena (Estado: 5), o si la IP que está enviando ha sido colocada en la lista de bloqueadas (Estado: 4).
Soluciones:
- Dedique algún tiempo a comprender el significado de los códigos de respuesta que le devuelvan. Se trata de situaciones que tal vez deba tener en cuenta.
- Para saber si se debe conceder acceso al usuario o enviarlo a la sala de espera, sólo es necesario comprobar el atributo booleano promoted, que, a menos que se produzca un error, siempre estará presente y será 0 o 1. Si la integración es muy sencilla y sólo se tiene en cuenta este atributo, es posible enviar al usuario a la sala de espera. Si tu integración es muy simple, y sólo miras este atributo, realmente no necesitas entender las diferentes respuestas y estados, porque si promoted es 0, puedes enviar al usuario a la sala de espera, y la sala de espera sabrá qué hacer.
- Si has construido una aplicación o usas un framework que requiere que el objeto respuesta sea consistente en todo momento por razones OO, deberías empezar con tu propio objeto base o clase para representar la respuesta, especificando valores por defecto sensibles, y luego establecer sólo los valores que vuelven de la respuesta de la api.