Soy nuevo utilizando la API de Paybook y funciona muy bien, aunque “a veces” las peticiones abortan con un status code 520.
Mencioné “a veces” ya que en promedio 1 de 5 AJAX se caen, y esto me sucede con TODOS los endpoints de manera aleatoria.
Probablemente esté haciendo algo mal, lo único que veo sospechoso en mi código es que estoy enviando origin: null en mis Headers y las respuestas de la API dicen Origin 'null' is therefore not allowed access.
Actualmente estoy utilizando JavaScript y jQuery y desarrollando sobre el Sandbox con AJAX nativos, pero lo más probable es que solo cambie los AJAX y me mueva a Sync-php.
Alguien más tiene este problema? Cómo pudiera solucionarlo? Muchas gracias de antemano.
Hola Jorge buenas tardes, no se ha reportado antes un caso similar.
Sin embargo, me llama mucho la atención que estás trabajando toda tu implementación en el lado del cliente ya que se expondría tu API KEY y por lo tanto información sensible en el navegador.
Lo recomendable es, que en un ambiente de BackEnd gestiones la creación de usuarios y sesiones de dichos usuarios, una vez que generes la sesión podrás enviar el token a tu FrontEnd para realizar cualquier operación propia del usuario dueño de la sesión, por ejemplo con el token puedes habilitar el Widget que asiste al usuario en la creación de las credenciales.
Respecto a tu reporte original, analizaremos qué puede estar pasando, si nos compartes el fragmento de código donde haces la petición nos ayudará mucho importante, no pegar api key
Correcto, la intención no es dejar la aplicación de esa manera.
Al decir “probáblemente” me refiero a que aun estamos evaluando si utilizar sync-php o sync-js ya que la aplicación apenas está en desarrollo y es para practicar la API (igual muchas gracias por la llamada de atención sobre ese punto).
Esta es la función Ajax que se está manejando actualmente, junto con una consulta a mis usuarios:
Probablemente el error de CORS se solucione apuntando los ajax a mi server y utilizando alguna de las librerías BackEnd, aun así se me hizo extraño que a veces se aborte la petición.
@miguelmateo Buenas tardes Miguel, solo para mantener al tanto que ese supuesto “bug” solo sucede cuando manejas la API del lado del cliente. Al usarla en el lado del servidor funciona perfecto!
Este error puede reproducirse cuando se intenta enviar las credenciales de TWO-FA desde el lado del cliente, utilizando:
token (de sesión)
twofa: {token: ‘…’}
Es una configuración de CORS inexistentes, que en mi opinión deberían ser más abiertas para TWO-FA post del lado del Browser, pues de lo contrario aumentan la complejidad al tener que hacer un proxy desde Back End
La respuestas del API regresan el header “Access-Control-Allow-Origin” para poder hacer peticiones sin problema de CORS y sin usar un proxy en backend.
Sin embargo creo que el 520 lo esta regresando Cloud Flare, ese código lo usan como un comodín de errores, y supongo que en los headers omiten el header de control origin.
Entonces para identificar correctamente este problema necesitaría identificar la petición. Para poder hacer eso necesitaría el Request ID de la petición (viene en el body y en los headers) o el token de la session o la fecha y hora en lo que sucedió para intentar identificar esta petición en los logs.
Este es el RID más reciente que me regresa ese CORS error: aecbe3ca-d84e-4cbb-95e4-173470543500
Sin embargo, es importante comentar que la operación si se ejecuta correctamente, sin embargo, el browser regresa ese CORS error.
Puede ser como comentas, un problema con Cloud Flare, pues todos los requests que hago se ejecutan, sin embargo, al recibir en mi browser este error, he tenido que hacer un Back end proxy para resolverlo.
En particular el RID aecbe3ca-d84e-4cbb-95e4-173470543500 regresa el header correcto, tardo 0.5 segundos. Al menos desde nuestro servidor de aplicación todo se ve como debería.
Ese RID te mando un error de CORS o es el ultimo RID que tenias a la mano?.
Hemos intentado replicar el problema sin embargo aun no tenemos nada en concreto porque parece algo espontaneo.
Estaba revisando el RAY-ID, y veo en los logs la petición al API. La respuesta tardo 12 ms.
Lo unico extraño que puedo identificar por el momento, es que hay muchas peticiones en el mismo segundo que se podria reducir a una. El endpoint de accounts se consumio 5 veces en el mismo segundo, adicional se consumo el endpoint de credential también en el mismo segundo.
Podrias reducir la cantidad de peticiones a 1?, a ver si eso corrige tu problema.
Has considerado usar el widget?. Basicamente maneja la lógica de la interfaz con el usuario final, entre otras cosas escucha via websocket los cambios de estatus y te hace el render de los objetivos necesarios para autenticar al usuario.
Y adicionalmente con los webhooks puedes recibir cuando una credential termina de ejecutarse. En este momento podrias ir al endpoint de accounts y transactions a descargar la información.
El widget no me sirve debido a que necesito una customización más completa, adicionalmente a diseño propietario.
En el caso de Websockets, originalmente iniciaba una conexión con WS al punto indicado al crear una credencial, pero en el caso del ambiente de pruebas, había varias situaciones en que el websocket se conectaba ya terminado el job.
Esto causaba incertidumbre en algunas cuentas donde el job demo terminaba muy rápido.
Por ahora mi sistema funciona de la siguiente manera, usando webhooks y un WS interno nuestro:
Se crea la credencial
Webhooks recibe “credential_create”
WS emite este evento a Front end, donde FE vuelve a pedir las credenciales solamente.
Webhooks recibe “credential_update”
WS emite este evento a Front end, donde FE pide el Sync status de las credenciales para el job
Si el job regresa 410, entonces abro un modal para subir el twofa.
Webhooks recibe “refresh”
WS emite este evento a Front end, donde FE vuelve a pedir las credenciales y las accounts.
Esta bien esta lógica?
En cuanto al error donde se emitía muchas veces “get accounts”, era causado por un web-component que lo ejecutaba siempre que su parent component tenía un cambio, ya se corrigió a una sola lógica centralizada.
Hola Gabriel, creo que parte de tu lógica está muy bien pero tengo algunas dudas puntuales.
1. Se crea la credencial
¿Almacenas el URL de /status para monitorear el estado de la conexión o toda la lógica de tracking la haces con webhooks?
3.- WS emite este evento a Front end, donde FE vuelve a pedir las credenciales solamente…
¿Por qué vuelves a pedir las credenciales?
4.- Webhooks recibe “credential_update”
Me pregunto si tu lógica soporta la recepción del evento “credential_update” más de una vez.
Por lo general, se recibe el evento “credential_update” dos veces, por la siguiente razón:
1.- credential_update
Se modifica la propiedad dt_authorized y code del objeto Credential, ésto para indicar que se ha iniciado sesión, se puede identificar que el proceso sigue ejecutándose debido a que en el mensaje viene la propiedad is_executing con valor 1.
2-. credential_update
Al concluir la conexión, se envía el evento nuevamente debido a que se actualizan la propiedad Credential.code con un código final de la conexión. Se puede determinar que el proceso terminó debido a que la propiedad is_executing del mensaje tiene valor 0.
7.- Webhooks recibe “refresh”
¿Qué sucede en caso de que no recibas el evento “refresh”?
No almaceno el URL de status asociado a su job, probablemente sería buena idea implementarlo y eliminarlo de la base de datos una vez reciba un status final ( >= 200, excepto 410). Por ahora toda la lógica de tracking la hago con webhooks, esperando una notificación de cambio. Crees que sería buena idea guardar el status ur para un “job”? o puedo fiarme de webhooks completamente?
En el caso de volver a pedir las credenciales al recibir WS event, es debido a que su respuesta alimenta la interfaz donde muestro el estado de credenciales (UI muestra “Credencial creada”).
La razón por la cual no lleno esta lista de credenciales registradas directamente de la respuesta de paybook POST .../credentials es para mantener un solo origen de datos.
Adicionalmente, este proceso permite a dos usuarios en dos computadoras diferentes, ser notificados del cambio de credenciales, aunque solo haya sido un usuario el que realizó el cambio.
Webhooks puede recibir cualquier evento las veces que sea necesario, esencialmente, este WebHook solamente notifica por WebSocket al Front-end, con{event, id_job, id_site, id_credential}.
El Front end se encarga de solicitar el status del job, y si hay un cambio en el último status proceso su status (two-fa, etc.), de lo contrario es ignorado.
En caso de no recibir “refresh”
En este caso, no se actualizaría los accounts, por ahora he recibido “refresh” siempre que agrego una cuenta que regresa status 200, ACME - Normal & ACME - Token.
1.- No deberías hacer el tracking de la conexión mediante Webhooks, para eso se expone un endpoint de /status y un websocket. El tracking de la conexión deberá hacerse específicamente mediante alguno de éstos dos canales ya que te permite revisarlo en tiempo real.
2.- Actualmente en los Webhooks se entregan mensajes para informar la actividad de la credencial y notificar cuando hay información disponible para descarga, pero éstos mensajes no llegan precisamente en tiempo real. Debido a que algunos procesos pueden tardar más tiempo es por eso que se mandan en segundo plano vía Webhook.
3.- El 410 no notifica “credential_update”, si en algún comentario lo mencioné, fue una equivocación.
En resúmen, debes hacer el tracking vía /status o WebSocket y la información obtenida por la credencial la procesas con los mensajes del Webhook.
