WooCommerce Redsys Gateway 32.1.x

El desenvolupament d’aquesta versió ha costat 2.300 euros. El cost acumulat per a aquest any és de 37.430 euros. El cost acumulat des de la primera versió és de 236.160 euros, però el cost per a tu és només la llicència de 79€.

Nova branca 32.1.x del plugin Redsys per a WooCommerce de WooCommerce.com.

Versions de la branca

• 32.1.0

32.1.0

Nou:

• L’informe d’estat de WooCommerce (WooCommerce – Estat) ara també llista el que està activat a la pestanya “Ajustos avançats” de Redsys: notificacions push, factures seqüencials, codis QR, targetes guardades, sobreescriptura d’estats de comanda, regles condicionals, subscripcions, conciliació per correu electrònic, els protocols de comerç agent i l’API de l’app de gestió. Les credencials no s’imprimeixen mai: de cada una s’indica únicament si està configurada o no. S’inclou al copiar l’informe per enviar-lo a suport, que és just l’objectiu: una petició de suport arriba ja amb la configuració dins.
• Ja pots decidir si als teus clients se’ls ofereix “Afegir una targeta de crèdit per a Subscripcions” a La meva compte – Mètodes de pagament. Fins ara aquesta opció apareixia sola quan hi havia un plugin de subscripcions actiu, sense manera de treure-la, i això no és el que vol tota botiga: en una botiga on la targeta de la subscripció es captura sempre durant la compra, l’únic que feia era convidar al client a guardar una targeta que mai es cobraria. L’interruptor nou està a Redsys – Ajustos avançats – Targetes guardades, ve activat perquè res canviï a les botigues que ja ho oferien, i al desactivar-lo es queda sola la targeta de 1-click. També s’informa d’ell a l’informe d’estat de WooCommerce.

Seguretat:

• El plugin escrivia en el seu propi fitxer de registre l’adreça de la pàgina de “comanda rebuda” de cada compra, en tots els pagaments, i aquesta adreça conté la clau de la comanda: el testimoni privat que WooCommerce posa en l’enllaç de pagament del comprador i que aquest plugin exigeix abans de mostrar una comanda. Qualsevol amb accés de lectura al fitxer de registre podia, per tant, obrir aquestes comandes i veure el nom, el correu, el telèfon i les adreces que contenen. Ocorreixis estigués o no activat el registre de depuració a la botiga, perquè aquest punt concret escrivia al log sense comprovar aquest ajust. Ara respecta l’ajust de depuració com la resta de registres que escriu el plugin, i la clau es substitueix per “[redacted]” abans d’escriure res, de manera que no queda registrada ni amb el log activat. Aquesta substitució s’ha aplicat després a totes les línies de registre del plugin, i no només a la que es va reportar: al voltant de noranta línies més repartides per les passarel·les imprimien aquestes mateixes adreces sempre que el registre de depuració estigués actiu, incloses les que volquen el missatge complet enviat al banc. Els fitxers de registre ja escrits continuen contenint aquestes adreces: si els tens, esborrar-los.
• La pàgina que reenviava al comprador a Redsys (i a Bizum) acceptava qualsevol número de comanda escrit a la seva adreça, sense comprovar que qui ho demanava fos qui havia fet aquesta comanda. Com que els números de comanda són correlatius, algú podia recórrer-los i llegir les dades que el plugin envia al banc de les comandes d’altres clients: nom, correu, telèfon i les adreces de facturació i enviament, juntament amb l’import i la descripció del comprat. En cap moment es va exposar un número de targeta, un codi de seguretat ni una clau de signatura, i per aquesta via no es podia pagar ni modificar res. Aquesta pàgina exigeix ara la clau de la comanda que WooCommerce inclou en l’enllaç de pagament del propi comprador, de manera que una petició que no correspon a la comanda es respon amb una pàgina “Forbidden” en lloc d’atendre’s. La mateixa comprovació s’ha afegit a la finestra emergent de pagament de la pàgina de finalitzar compra. Reportat per l’equip de seguretat de Tivify (TVUP Streaming Media), que va descriure el problema amb claredat i ens va donar temps per corregir-ho abans de fer-ho públic. Gràcies.
• Els tres botons de preautoritzaió de la pantalla de comanda (autoritzar, anul·lar i cobrar una part) i la cerca de clients de PayGold acceptaven les seves peticions sense un testimoni de seguretat. La comprovació de permisos ja estava al seu lloc, així que només un gestor de botiga o un administrador podia fer servir-los i ningú més podria haver-los executat, però a un administrador amb la sessió ja oberta se li podia enganyar per disparar-los des d’una altra web sense que se n’adonés. Els quatre porten i verifiquen ara un testimoni de seguretat de WordPress, cosa que tanca aquesta via.
• El Protocol de Comerç Agent podia acabar activat sense que ningú ho hagués triat, en botigues que s’actualitzen automàticament. Publica adreces amb les quals poden parlar màquines, així que està pensat per estar desactivat a menys que ho activis tu, i ara ho està. Si ho tenies activat, per a tu no canvia res.
• S’ha actualitzat la biblioteca de Google inclosa al plugin, cosa que corregeix dos fallos en la part que realitza peticions de xarxa.

Actualitzat:

• Quan falla la renovació d’una subscripció, la nota que s’afegeix a la comanda diu ara exactament quin pas ha fallat i amb quin codi de comerç i terminal es va fer l’intent. Fins ara els sis fallos possibles escrivien la mateixa nota, poc informativa, cosa que feia gairebé impossible diagnosticar una renovació fallida sense accés a la botiga, especialment en botigues on no s’està escrivint el log de depuració.
• Quan Apple Pay no aconsegueix validar la botiga amb Apple, el registre recull ara l’explicació de la pròpia Apple i si els fitxers del certificat es poden llegir. Apple respon amb un genèric “Expectation Failed” i posa el motiu real al cos de la seva resposta, que no s’estava registrant mai, així que aquests fallos eren un carreró sense sortida.
• El plugin distribuït ja no conté els scripts de desenvolupament i compilació del projecte, la configuració del seu entorn de proves local, els seus directoris d’editor i de hooks de git, el seu README per a desenvolupadors ni un document intern de revisió de seguretat. Res d’això arribava a carregar-se quan el plugin s’executa, però tampoc pinta res al servidor d’una botiga. El que conté el paquet es comprova ara automàticament, abans de cada publicació, contra una llista del que el plugin realment distribueix, de manera que alguna cosa que s’afegeixi al projecte en el futur no pugui viatjar dins del zip sense que ningú se n’adoni.
• La tasca de conciliació per correu electrònic existeix ara només mentre aquesta funció està activada, i només una vegada. Abans es creava en totes les botigues i es despertava cada cinc minuts sense fer res.
• Totes les traduccions tornen a estar completes. Seixanta-nou textos afegits per versions recents seguien apareixent en anglès: etiquetes d’ajustos, l’informe d’estat i alguns missatges que pot veure un comprador. Espanyol, català, euskera, gallec, francès i portuguès tornen a estar al cent per cent.
• El testimoni que protegeix l’enllaç d'”afegir una targeta” es compara ara en temps constant, com la resta de secrets que compara aquest plugin. Cronometrar aquesta comparació a través d’internet no és un atac practicable, així que no hi havia res explotable; el defecte era la inconsciència, perquè aquesta era la única comparació que es va quedar enrere quan es van migrar les altres durant el treball de signatures.

Arreglat:

• Amb InSite, pagar amb una targeta que el comprador tenia guardada podia cobrar els diners i, tot i així, mostrar la comanda com a fallida. Quan el banc aprova un pagament així sense demanar-li al comprador que confirmi amb l’app del seu banc, que és el que passa amb una targeta guardada, el plugin buscava el resultat al lloc equivocat, no trobava res i tractava aquest “res” com un rebuig. El càrrec ja s’havia fet, així que compradors als quals se’ls deia que el pagament havia fallat pagaven una segona vegada i se’ls cobrava dues vegades. El resultat es llegeix ara de la pròpia resposta signada del banc, la mateixa que ja fa servir la resta del pagament. Afectava per igual al checkout clàssic i al de blocs, i també a les renovacions de subscripcions. Reportat per dues botigues amb pocs dies de diferència, una d’elles rastrejant-ho fins a la línia exacta. Gràcies.
• A la passarel·la de targeta, un pagament fet amb una targeta guardada es donava per completat només amb el número d’autorització, sense comprovar la resposta real del banc que va al seu costat. Un pagament rebutjat que, tot i així, portés alguna cosa en aquest camp marcava per tant la comanda com a pagada, i la botiga enviava la mercaderia sense haver cobrat. Ara s’exigeix que ambdós coincideixin abans de completar una comanda. Si la resposta del banc falta completament, el pagament no es completa, perquè no queda res que digui que va ser aprovat; una botiga el banc de la qual ometi realment aquest camp pot restaurar a propòsit el comportament anterior amb el filtre redsys_allow_payment_without_ds_response, que està documentat i que no es pot fer servir per acceptar un pagament que el banc hagi rebutjat.
• En botigues que fan servir certs plugins de finalitzar compra, Fluid Checkout entre ells, tots els pagaments eren rebutjats per Redsys amb l’error SIS0574. El banc exigeix una breu descripció del navegador del comprador amb cada pagament (el seu idioma, la mida de la seva pantalla i similars), que el plugin recull mitjançant camps ocults que afegeix al checkout. Aquests camps s’afegien en el moment en què es construïa la passarel·la de targeta, cosa que en aquestes botigues passa després que un altre plugin hagi demanat ja a WooCommerce la llista definitiva de camps del checkout, i WooCommerce construeix aquesta llista una sola vegada i mai més. Els camps, per tant, no es creaven, no es omplien i no s’enviaven, i el banc rebutjava el pagament. Ara s’afegeixen tan bon punt carrega el plugin, abans que ningú pugui demanar la llista, cosa que afecta a totes les passarel·les que els necessiten, la de targeta, Bizum i les wallets, i no només a InSite. A InSite la descripció del navegador viatja a més ara amb la resta de dades del pagament en lloc de dependre només de la comanda, de manera que sobreviu a un checkout que es reconstrueix a si mateix. Reportat per un integrador que ja portava el diagnòstic demostrat. Gràcies.
• Si un pagament es cancel·la o és rebutjat, el comprador tornava a la botiga però la comanda es quedava pendent i el carro no es restaurava. L’adreça que el plugin donava al banc per retornar al comprador estava escrita en la forma que s’utilitza per als enllaços dins d’una pàgina web, no en la que s’utilitza per a una adreça real, així que la botiga rebia el retorn sense la referència de la comanda, sense el seu número i sense el seu testimoni de seguretat, i no tenia res a cancel·lar. Afectava a Bizum, Google Pay, Apple Pay, domiciliació bancària, transferència, InSite i a la passarel·la de targeta sempre que l’ajust de “tornar a” estigui posat en cancel·lar la comanda. En MasterPass aquesta mateixa adreça s’enviava directament buida, per un error d’escriptura d’un sol caràcter repetit en tres línies. Tot passa ara per una única peça de codi compartida, de manera que una passarel·la que s’afegeixi en el futur no pugui tornar a equivocar-se.
• En el mode de pagament en finestra emergent (modal), cancel·lar un pagament no feia res i el comprador es quedava al carro amb la comanda pendent. L’adreça a la qual el plugin enviava al navegador s’escrivia a la pàgina d’una manera que el navegador interpreta com un enllaç dins d’un document i no com una adreça web, així que tot el que anava després del primer paràmetre es descartava: la referència de la comanda, el seu número i el seu testimoni de seguretat desapareixien, i WooCommerce no tenia res a cancel·lar. El mateix defecte afectava a l’adreça a la qual es retorna al comprador després de pagar, on perdia en silenci un paràmetre de seguiment. Els dos estan corregits, a la passarel·la de targeta i a la d’InSite, i el comportament corregit s’ha verificat en un navegador real.
• El checkout podia morir amb un error crític, en lloc d’enviar al comprador al banc, amb un client registrat la fitxa del qual no s’havia modificat mai des que es va crear. El plugin construeix un conjunt de dades de seguretat per al banc en cada pagament, i un dels camps és la data en què es va modificar per última vegada el compte del client, que WooCommerce deixa buida en un compte que no s’ha tocat mai, normalment una creada per una importació, una migració o automàticament per un altre plugin. El plugin llegia aquesta data buida com si fos una data real i la pàgina de pagament es detenia allà. Ara recorre a la data de creació del compte, que és el que significa “mai modificada”, i la mateixa protecció s’ha afegit al codi equivalent que fan servir les subscripcions, on aquesta mateixa data buida s’estava reportant en silenci al banc com “modificada avui”, que és informació incorrecta per als seus controls de frau.
• Redsys i les altres passarel·les podien desaparèixer del checkout per a tothom, incloent els compradors normals, en botigues on la llista de “mostrar només a aquests usuaris” del mode de proves no s’havia omplert mai. El plugin llegia aquest ajust buit com “mostrar-ho a un usuari el id del qual és res”, que no coincideix amb ningú, així que el mètode de pagament quedava ocult per a tots els visitants. Només afectava a
  • Botigues els ajustos haurien estat escrits per alguna cosa diferent de la pantalla d’ajusts, una importació, una migració o l’API de gestió del plugin, perquè guardar aquesta pantalla a mà emmagatzema un valor buit diferent que mai ho provocava. Corregit en les nou passarel·les que compartien el mateix codi.
  • Les subscripcions pagades amb Apple Pay o Google Pay per un client sense compte no obtenien mai del banc el permís de pagament recurrent, així que la primera renovació fallava amb una nota dient que no hi havia targeta. Ocorre en botigues on l’opció general de “permetre als clients crear un compte durant el pagament” està desactivada, cosa habitual en botigues que admeten la compra com a convidat: els camins de pagament de les wallets no veien la sobrescriptura que fa d’aquesta opció el mateix WooCommerce Subscriptions, així que no es creava cap compte i, sense compte, el permís del banc no es podia guardar. Corregit en els quatre llocs que ho gestionen (Apple Pay i Google Pay, tant en el checkout clàssic com en el de blocs).
  • El script de pagament del checkout de blocs estava compilat contra una versió de React que el mateix WordPress no accepta. Una dependència només de desenvolupament arrossegava un React més nou a la compilació, i WordPress rebutja els elements produïts per ell, així que el mètode de pagament podia no arribar a aparèixer en el checkout de blocs. La compilació fixa ara la versió que utilitza WordPress i el script s’ha tornat a generar.
  • El carro i el checkout podien tornar-se notablement lents, també per a visitants no identificats, en botigues amb targetes guardades o subscripcions. L’ajudant intern WCRed() del plugin construïa una còpia nova del seu objecte global cada vegada que se li cridava, i aquest objecte registra tres hooks de WordPress en el moment de construir-se. WordPress no substitueix aquests hooks, els afegeix, així que en una botiga on l’ajudant es crida una vegada per cada targeta guardada o subscripció les mateixes tres comprovacions acabaven registrades centenars de vegades i es tornaven a executar, totes, cada vegada que WooCommerce muntava la llista de passarel·les de pagament disponibles. En una botiga que va reportar el problema això arribava a uns 438 registres duplicats per càrrega de pàgina i a prop de 1,7 segons de treball de PHP en la pàgina del carro, dels quals només 56 milisegons eren consultes a la base de dades. L’ajudant construeix ara aquest objecte una sola vegada i el reutilitza, de manera que els hooks es registren exactament una vegada per petició. El comportament del plugin no canvia en res: l’objecte no guarda dades pròpies de cada petició. El mateix tractament d’un objecte per petició s’ha aplicat a l’ajudant WCPSD2(), que tenia la forma idèntica.
  • En una petita part de les botigues, la clau de signatura de missatges de Comerç Agèntic (UCP) es guardava en una forma que no es podia utilitzar mai, així que tota comprovació de signatura contra ella fallava i el document de clau publicat no seguia l’estàndard. Quan el plugin creava aquesta clau, una de les seves dues coordenades tornava de tant en tant d’OpenSSL un byte més curta del que exigeix l’estàndard, al voltant d’1 botiga de cada 135, i el plugin la guardava tal qual en lloc de completar-la. Des d’aquell moment la botiga no podia verificar les seves pròpies signatures, ni podia fer-ho cap agent extern, fins que es rotava la clau. La clau es guarda ara completada fins a la longitud exigida, i una clau ja guardada en la forma curta es repara automàticament la primera vegada que es llegeix, així que cap comerciant ha de rotar res.
  • En botigues amb PHP 8.0 o anterior, activar la conciliació per correu electrònic trencava la pàgina amb un error del servidor en lloc de simplement no funcionar. El plugin ho comprova ara abans i deixa una nota clara en el seu registre. La funció en si continua necessitant PHP 8.1.
  • Les tasques en segon pla s’acumulaven en desenes de còpies de si mateixes en la llista d’accions programades de WooCommerce. Corregit en tots els llocs on el plugin programa alguna cosa, i les còpies que ja estiguessin allà es netegen automàticament.
  • Una notificació a l’app mòbil podia perdre’s sense donar cap error si s’enviava en el moment equivocat.
  • Apareixien avisos de PHP en el registre del servidor en cada visita a la pàgina de “pagar comanda”, procedents de les passarel·les d’Apple Pay i Google Pay. Per als compradors no hi havia res trencat, però el log de depuració d’aquestes passarel·les no estava registrant res d’aquest pas, així que qui intentés diagnosticar un problema allà estava mirant un error i no un silenci. Reportat per un comerciant, i trobat en tres passarel·les en lloc de en la que es va reportar. Gràcies.
  • Activar el log de depuració per investigar un problema de pagament amb targeta produïa avisos en lloc de la informació per la qual s’havia activat.
  • El botó “Connectar amb Google” dels ajustos de conciliació per correu electrònic no es mostrava mai. Concedir l’accés ja era possible omplint les dades de Google i prement “Desar canvis”, així que això restaura un drecera, no desbloqueja la funció.
  • El plugin enviava a la botiga un correu dient “Redsys no està enviant camps de tokenització” després de pagaments en els quals Redsys havia enviat tots i cadascun d’ells. La comprovació que hi ha darrere d’aquest avís provava una variable que no existeix en cap lloc del plugin, i una prova sobre alguna cosa que no existeix sempre és certa, així que l’avís sortia en cada pagament que guardava una targeta. Els comerciants se’l portaven al seu banc, que responia amb raó que el terminal estava bé. L’avís informa ara només d’absències reals, i indica en el registre quin camp faltava, la data de caducitat, la marca de la targeta o el número, en lloc de dir únicament que faltava alguna cosa. També ha hagut de deixar de llegir la marca després que el plugin l’hagi convertit en un nom per mostrar, perquè aquesta conversió respon “Unknown” quan no hi ha marca, el que hauria convertit l’avís en un que no podria aparèixer mai. Aquest mateix bloc escrivia “unknown” com a número de targeta en el log de depuració en cada pagament, per un nom de variable amb una lletra de més; ara escriu el número enmascarat real.
  • Cercar a la pantalla de tokens de Redsys (WooCommerce – Redsys tokens) per correu electrònic o per nom d’usuari no trobava cap targeta guardada a partir de la vigesimoquinta. La pantalla demanava a la base de dades una pàgina de tokens i cercava després dins d’aquesta pàgina, i com els demanava sense cap ordre concret, aquesta pàgina eren sempre els vint-i-cinc tokens més antics de la botiga, així que les targetes guardades recentment, que són les úniques que algú cerca, resultaven inabastables. La cerca es fa ara a la base de dades, sobre tots els tokens, i el llistat arriba de més nou a més antic. El comptador que hi ha a sobre de la taula i la llista de sota ja no poden discrepar, ordenar per nom d’usuari o per correu ordena ara tota la taula en lloc de la pàgina visible, i la pantalla ja no carrega en memòria tots els tokens de la botiga només per comptar-los, cosa que en botigues amb milers de targetes guardades feia en cada càrrega de pàgina.