Category: Programación

Si en el dominio en el que queremos integrar Redsys usamos Cloudfare las notificaciones (webhooks) que nos quiera enviar Redsys no nos llegarán porque Cloudfare las bloquea al considerar que no las está realizando un navegador al uso. Bien por Cloudfare, que para mucha morralla antes de que llegue a nuestro servidor, pero mal por el Koas que se tira un día y pico sin comprender por qué el webhook funciona si se llama a mano y no cuando lo hace Redsys.

La solución es incluir una regla en el cortafuegos de Cloudfare para que las peticiones que lleguen desde Redsys a la dirección del webhook no realicen esa comprobación. La forma de hacerlo está perfectamente explicada en esta entrada del blog de Marc Pàmpols.

La integración de la pasarela de pago de Redsys en modo insite es bastante simple pero tiene algunos momentos wtf. Dejo aquí algunos apuntes para no volver a tropezar con ellos en el futuro:

• Hay que hablar con el contacto del banco que nos ofrezca la pasarela y pasarle una lista con todos los dominios en los que vayamos a usarla, tanto de desarrollo como de producción. Esto es lo primero que hay que hacer, hasta que no nos habiliten esos dominios no nos aparecerá el formulario incrustado para meter los datos de la tarjeta.
• No se pueden repetir números de pedido. Si lo hacemos la petición de id de operación se completará sin error pero nos devolverá un id de operación de -1.
• El código de comercio y el número de terminal deben enviarse sin ceros a la izquierda, y el número de pedido debe pasarse como string, si se pasa como número se nos devolverá un error (no un código de error, el iframe solo devolverá la palabra Error).

Actualización: los dos últimos puntos no vienen indicados en la documentación de integración del Santander, pero sí vienen en la oficial de Redsys, así que lo mejor es usar esa.

Hay veces que en una aplicación de Vue tenemos una pantalla donde puede haber un número variable de componentes que el usuario puede configurar, por ejemplo en un dashboard o en una pantalla de definición de filtros.

En estos casos usar la sintaxis habitual para importar componentes se hace tedioso y es más sencillo utilizar el componente de Vue component y un sistema de carga dinámica. En esta página lo explican perfectamente.

TL,DR: en la parte de template definimos el componente:

component(:is="currentComponent")

Y definimos la propiedad computada así:

currentComponent()
{
    let name = "Aquí establecemos el nombre del componente a cargar";
    return () => import(`@/components/Ruta1/Ruta2/${name}`);     
}

Después de releer el libro de Phil Sturgeon Build APIs you won’t hate dejo aquí estas notas a tener en cuenta para el diseño de APIs:

• No usar un número autoincremental como identificador de los recursos, es mejor utilizar un identificador alfanumérico.
• Nombres de los recursos en plural (places, users, etc.)
• Los nombres de los recursos no deben ser verbos sino sustantivos. Por ejemplo, en vez de /users/5/send-message es mejor /users/5/messages
• Para generar documentación: Api Blueprint
• Principales códigos de respuesta:
  • 200 – Generic everything is OK
  • 201 – Created something OK
  • 202- Accepted but is being processed async (like video encodings)
  • 204 – The server has successfully fulfilled the request and that there is no additional content to send in the response payload body
  • 400 – Bad Request (should really be for invalid syntax but some folks use it for validation)
  • 401 – Unauthorized (no current user and there should be)
  • 403 – The current user is forbidden from accessing this data
  • 404 – That URL is not a valid route, or the item resource does not exist
  • 410 – Data has been deleted, deactivated, suspended, etc
  • 405 – Method Not Allowed (your framework will probably do this for you)
  • 500 – Something unexpected happened and it is the APIs fault
  • 503 – API is not here right now, please try again later
• Ejemplo de paginado:

{
  "data": […],
  "pagination" :
  {
    "total": 1000,
    "count": 12,
    "per_page": 12,
    "current_page": 1,
    "total_pages": 84,
    "next_url": "/places?page=2&number=12",
  }
}

En este blog escribo básicamente para mí mismo, pero hay algunos temas sobre los que creo que puedo escribir artículos que realmente sean útiles para más personas. Esos artículos los escribiré (en inglés) en dev.to, que es un portal de contenido para desarrolladores.

Y aquí tenemos el primero, habla sobre cómo usar cabeceras HTTP para ayudarnos a depurar sitios web que están en producción.

A veces GitHub no detecta correctamente el lenguaje principal de un repositorio. Por ejemplo, para Mi Segundo PC como tiene más ficheros con extensión php que js decía que el lenguaje era PHP en vez de JS.

Para solucionarlo creamos un fichero .gitattributes en el directorio raíz del repositorio con este contenido:

* linguist-vendored
*.js linguist-vendored=false

Esto le indica a GitHub que desactive la detección de lenguaje para todos los ficheros y la active para los .js, haciendo así que el lenguaje detectado sea JavaScript.