WooCommerce Redsys Gateway 32.1.x

O desenvolvimento desta versão custou 2.300 euros. O custo acumulado para este ano é de 37.430 euros. O custo acumulado desde a primeira versão é de 236.160 euros, mas o custo para você é apenas a licença de 79€.

Nova versão 32.1.x do plugin Redsys para WooCommerce de WooCommerce.com.

Versões da versão

• 32.1.0

32.1.0

Novo:

• O relatório de estado do WooCommerce (WooCommerce – Estado) agora lista também o que está ativado na aba “Configurações avançadas” do Redsys: notificações push, faturas sequenciais, códigos QR, cartões salvos, sobrescrita de estados de pedidos, regras condicionais, assinaturas, conciliação por e-mail, os protocolos de comércio agêntico e a API do aplicativo de gestão. As credenciais nunca são impressas: de cada uma é indicado apenas se está configurada ou não. Está incluído ao copiar o relatório para enviá-lo ao suporte, que é exatamente o objetivo: um pedido de suporte chega já com a configuração dentro.
• Agora você pode decidir se seus clientes têm a opção de “Adicionar um cartão de crédito para Assinaturas” em Minha conta – Métodos de pagamento. Até agora, essa opção aparecia sozinha assim que havia um plugin de assinaturas ativo, sem maneira de removê-la, e isso não é o que toda loja deseja: em uma loja onde o cartão da assinatura é capturado sempre durante a compra, a única coisa que fazia era convidar o cliente a salvar um cartão que nunca seria cobrado. O novo interruptor está em Redsys – Configurações avançadas – Cartões salvos, vem ativado para que nada mude nas lojas que já o ofereciam, e ao desativá-lo fica apenas o cartão de 1-clique. Também é informado no relatório de estado do WooCommerce.

Segurança:

• O plugin escrevia em seu próprio arquivo de registro o endereço da página de “pedido recebido” de cada compra, em todos os pagamentos, e esse endereço contém a chave do pedido: o testemunho privado que o WooCommerce coloca no link de pagamento do comprador e que este plugin exige antes de mostrar um pedido. Qualquer um com acesso de leitura ao arquivo de registro poderia, portanto, abrir esses pedidos e ver o nome, o e-mail, o telefone e os endereços que contêm. Isso ocorria independentemente de o registro de depuração estar ativado na loja, porque esse ponto específico escrevia no log sem verificar essa configuração. Agora respeita a configuração de depuração como o restante dos registros que o plugin escreve, e a chave é substituída por “[redacted]” antes de escrever qualquer coisa, de modo que não fica registrada nem com o log ativado. Essa substituição foi aplicada depois a todas as linhas de registro do plugin, e não apenas à que foi relatada: cerca de noventa linhas a mais espalhadas pelas passarelas imprimiam esses mesmos endereços sempre que o registro de depuração estivesse ativo, incluindo as que despejam a mensagem completa enviada ao banco. Os arquivos de registro já escritos continuam contendo esses endereços: se você os tiver, exclua-os.
• A página que reencaminha o comprador para Redsys (e para Bizum) aceitava qualquer número de pedido escrito em seu endereço, sem verificar se quem o pedia era quem fez esse pedido. Como os números de pedido são correlativos, alguém poderia percorrê-los e ler os dados que o plugin envia ao banco dos pedidos de outros clientes: nome, e-mail, telefone e os endereços de faturamento e envio, junto com o valor e a descrição do que foi comprado. Em nenhum momento foi exposto um número de cartão, um código de segurança ou uma chave de assinatura, e por essa via não era possível pagar ou modificar nada. Essa página agora exige a chave do pedido que o WooCommerce inclui no link de pagamento do próprio comprador, de modo que um pedido que não corresponde ao pedido é respondido com uma página “Forbidden” em vez de ser atendido. A mesma verificação foi adicionada à janela pop-up de pagamento da página de finalização da compra. Reportado pela equipe de segurança da Tivify (TVUP Streaming Media), que descreveu o problema com clareza e nos deu tempo para corrigi-lo antes de torná-lo público. Obrigado.
• Os três botões de pré-autorização da tela de pedido (autorizar, anular e cobrar uma parte) e a busca de clientes de PayGold aceitavam suas solicitações sem um testemunho de segurança. A verificação de permissões já estava em seu lugar, assim que apenas um gestor de loja ou um administrador poderia usá-los e ninguém mais poderia tê-los executado, mas a um administrador com a sessão já aberta poderia ser enganado para dispará-los de outro site sem que percebesse. Os quatro agora levam e verificam um testemunho de segurança do WordPress, o que fecha essa via.
• O Protocolo de Comércio Agêntico poderia acabar ativado sem que ninguém o tivesse escolhido, em lojas que se atualizam automaticamente. Publica endereços com os quais máquinas podem falar, então está pensado para estar desativado a menos que você o ative, e agora está. Se você o tinha ativado, para você não muda nada.
• A biblioteca do Google incluída no plugin foi atualizada, o que corrige dois erros na parte que realiza solicitações de rede.

Atualizado:

• Quando falha a renovação de uma assinatura, a nota que é adicionada ao pedido agora diz exatamente qual passo falhou e com qual código de comércio e terminal foi feita a tentativa. Até agora, os seis possíveis erros escreviam a mesma nota, pouco informativa, o que tornava quase impossível diagnosticar uma renovação falhada sem acesso à loja, especialmente em lojas onde não se está escrevendo o log de depuração.
• Quando o Apple Pay não consegue validar a loja com a Apple, o registro agora coleta a explicação da própria Apple e se os arquivos do certificado podem ser lidos. A Apple responde com um genérico “Expectation Failed” e coloca o motivo real no corpo de sua resposta, que nunca estava sendo registrado, então esses erros eram um beco sem saída.
• O plugin distribuído não contém mais os scripts de desenvolvimento e compilação do projeto, a configuração de seu ambiente de testes local, seus diretórios de editor e de hooks de git, seu README para desenvolvedores nem um documento interno de revisão de segurança. Nada disso chegava a ser carregado quando o plugin é executado, mas também não tem relevância no servidor de uma loja. O que contém o pacote agora é verificado automaticamente, antes de cada publicação, contra uma lista do que o plugin realmente distribui, de modo que algo que seja adicionado ao projeto no futuro não possa viajar dentro do zip sem que ninguém perceba.
• A tarefa de conciliação por e-mail existe agora apenas enquanto essa função está ativada, e apenas uma vez. Antes era criada em todas as lojas e despertava a cada cinco minutos sem fazer nada.
• Todas as traduções estão novamente completas. Sessenta e nove textos adicionados por versões recentes continuavam aparecendo em inglês: etiquetas de ajustes, o relatório de estado e algumas mensagens que um comprador pode ver. Espanhol, catalão, euskera, galego, francês e português estão novamente cem por cento.
• O testemunho que protege o link de “adicionar um cartão” agora é comparado em tempo constante, como o restante dos segredos que este plugin compara. Cronometrar essa comparação através da internet não é um ataque praticável, então não havia nada explorável; o defeito era a inconsistência, porque esta era a única comparação que ficou para trás quando as demais foram migradas durante o trabalho de assinaturas.

Corrigido:

• Com InSite, pagar com um cartão que o comprador tinha salvo poderia cobrar o dinheiro e ainda assim mostrar o pedido como falhado. Quando o banco aprova um pagamento assim sem pedir ao comprador que confirme com o aplicativo de seu banco, que é o que acontece com um cartão salvo, o plugin buscava o resultado no lugar errado, não encontrava nada e tratava esse “nada” como um rejeição. A cobrança já havia sido feita, então compradores a quem era dito que o pagamento havia falhado pagavam uma segunda vez e eram cobrados duas vezes. O resultado agora é lido da própria resposta assinada do banco, a mesma que já usa o restante do pagamento. Afectava igualmente ao checkout clássico e ao de blocos, e também às renovações de assinaturas. Reportado por duas lojas com poucos dias de diferença, uma delas rastreando até a linha exata. Obrigado.
• Na passarela de cartão, um pagamento feito com um cartão salvo era dado como completo com apenas o número de autorização, sem verificar a resposta real do banco que vai ao seu lado. Um pagamento rejeitado que ainda assim tivesse algo nesse campo marcava, portanto, o pedido como pago, e a loja enviava a mercadoria sem ter cobrado. Agora é exigido que ambos coincidam antes de completar um pedido. Se a resposta do banco faltar completamente, o pagamento não é completado, porque não fica nada que diga que foi aprovado; uma loja cujo banco realmente omita esse campo pode restaurar propositalmente o comportamento anterior com o filtro redsys_allow_payment_without_ds_response, que está documentado e que não pode ser usado para aceitar um pagamento que o banco tenha rejeitado.
• Em lojas que usam certos plugins de finalização de compra, Fluid Checkout entre eles, todos os pagamentos eram rejeitados pelo Redsys com o erro SIS0574. O banco exige uma breve descrição do navegador do comprador com cada pagamento (seu idioma, o tamanho de sua tela e similares), que o plugin coleta através de campos ocultos que adiciona ao checkout. Esses campos eram adicionados no momento em que a passarela de cartão era construída, o que nessas lojas ocorre depois que outro plugin já pediu ao WooCommerce a lista definitiva de campos do checkout, e o WooCommerce constrói essa lista uma única vez e nunca mais. Os campos, portanto, não eram criados, não eram preenchidos e não eram enviados, e o banco rejeitava o pagamento. Agora são adicionados assim que o plugin carrega, antes que alguém possa pedir a lista, o que afeta todas as passarelas que os precisam, a de cartão, Bizum e as wallets, e não apenas ao InSite. No InSite, a descrição do navegador viaja também agora com o restante dos dados do pagamento em vez de depender apenas do pedido, de modo que sobrevive a um checkout que se reconstrói a si mesmo. Reportado por um integrador que já trazia o diagnóstico demonstrado. Obrigado.
• Se um pagamento era cancelado ou rejeitado, o comprador voltava à loja, mas o pedido ficava pendente e o carrinho não era restaurado. O endereço que o plugin dava ao banco para devolver ao comprador estava escrito na forma que se usa para links dentro de uma página web, não na que se usa para um endereço real, então a loja recebia o retorno sem a referência do pedido, sem seu número e sem seu testemunho de segurança, e não tinha nada que cancelar. Afectava ao Bizum, Google Pay, Apple Pay, débito automático, transferência, InSite e à passarela de cartão sempre que a configuração de “voltar para” estivesse definida para cancelar o pedido. No MasterPass, esse mesmo endereço era enviado diretamente vazio, por um erro de escrita de um único caractere repetido em três linhas. Tudo passa agora por uma única peça de código compartilhada, de modo que uma passarela que seja adicionada no futuro não possa voltar a errar.
• No modo de pagamento em janela pop-up (modal), cancelar um pagamento não fazia nada e o comprador ficava no carrinho com o pedido pendente. O endereço para o qual o plugin enviava ao navegador era escrito na página de uma forma que o navegador interpreta como um link dentro de um documento e não como um endereço web, então tudo que ia depois do primeiro parâmetro era descartado: a referência do pedido, seu número e seu testemunho de segurança desapareciam, e o WooCommerce não tinha nada que cancelar. O mesmo defeito afectava ao endereço para o qual se devolve ao comprador após pagar, onde perdia silenciosamente um parâmetro de rastreamento. Os dois estão corrigidos, na passarela de cartão e na de InSite, e o comportamento corrigido foi verificado em um navegador real.
• O checkout poderia falhar com um erro crítico, em vez de enviar o comprador ao banco, com um cliente registrado cuja ficha de cliente nunca tinha sido modificada desde que foi criada. O plugin constrói um conjunto de dados de segurança para o banco em cada pagamento, e um dos campos é a data em que a conta do cliente foi modificada pela última vez, que o WooCommerce deixa vazia em uma conta que nunca foi tocada, normalmente uma criada por uma importação, uma migração ou automaticamente por outro plugin. O plugin lia essa data vazia como se fosse uma data real e a página de pagamento parava ali. Agora recorre à data de criação da conta, que é o que significa “nunca modificada”, e a mesma proteção foi adicionada ao código equivalente que usam as assinaturas, onde essa mesma data vazia estava sendo reportada silenciosamente ao banco como “modificada hoje”, que é informação incorreta para seus controles de fraude.
• Redsys e as demais passarelas poderiam desaparecer do checkout para todos, incluindo os compradores normais, em lojas onde a lista de “mostrar apenas a esses usuários” do modo de testes nunca tinha sido preenchida. O plugin lia essa configuração vazia como “mostrá-lo a um usuário cujo id é nada”, que não coincide com ninguém, então o método de pagamento ficava oculto para todos os visitantes. Apenas afetava a

• Lojas cujas configurações foram escritas por algo diferente da tela de configurações, uma importação, uma migração ou a própria API de gerenciamento do plugin, porque salvar essa tela manualmente armazena um valor vazio diferente que nunca o provocava. Corrigido nas nove gateways que compartilhavam o mesmo código.
• As assinaturas pagas com Apple Pay ou Google Pay por um cliente sem conta nunca obtinham do banco a permissão de pagamento recorrente, então a primeira renovação falhava com uma nota dizendo que não havia cartão. Ocorreu em lojas onde a opção geral de “permitir que os clientes criem uma conta durante o pagamento” está desativada, algo comum em lojas que aceitam compras como convidado: os caminhos de pagamento das wallets não viam a sobrescrita que faz dessa opção a própria WooCommerce Subscriptions, então nenhuma conta era criada e, sem conta, a permissão do banco não podia ser salva. Corrigido nos quatro sites que o gerenciam (Apple Pay e Google Pay, tanto no checkout clássico quanto no de blocos).
• O script de pagamento do checkout de blocos estava compilado contra uma versão do React que o próprio WordPress não aceita. Uma dependência apenas de desenvolvimento arrastava um React mais novo para a compilação, e o WordPress rejeita os elementos produzidos por ele, então o método de pagamento poderia não aparecer no checkout de blocos. A compilação agora fixa a versão que o WordPress usa e o script foi regenerado.
• O carrinho e o checkout podiam se tornar notavelmente lentos, também para visitantes não identificados, em lojas com cartões salvos ou assinaturas. O assistente interno WCRed() do plugin construía uma nova cópia de seu objeto global toda vez que era chamado, e esse objeto registra três hooks do WordPress no momento de sua construção. O WordPress não substitui esses hooks, os adiciona, então em uma loja onde o assistente é chamado uma vez para cada cartão salvo ou assinatura, as mesmas três verificações acabavam registradas centenas de vezes e eram executadas novamente, todas, cada vez que o WooCommerce montava a lista de gateways de pagamento disponíveis. Em uma loja que relatou o problema, isso chegava a cerca de 438 registros duplicados por carga de página e cerca de 1,7 segundos de trabalho de PHP na página do carrinho, dos quais apenas 56 milissegundos eram consultas ao banco de dados. O assistente agora constrói esse objeto uma única vez e o reutiliza, de modo que os hooks são registrados exatamente uma vez por solicitação. O comportamento do plugin não muda em nada: o objeto não armazena dados próprios de cada solicitação. O mesmo tratamento de um objeto por solicitação foi aplicado ao assistente WCPSD2(), que tinha a forma idêntica.
• Em uma pequena parte das lojas, a chave de assinatura de mensagens de Comércio Agêntico (UCP) era armazenada de uma forma que nunca poderia ser usada, então toda verificação de assinatura contra ela falhava e o documento de chave publicado não seguia o padrão. Quando o plugin criava essa chave, uma de suas duas coordenadas às vezes retornava do OpenSSL um byte mais curta do que o exigido pelo padrão, cerca de 1 loja a cada 135, e o plugin a armazenava tal como estava em vez de preenchê-la. Desde então, a loja não podia verificar suas próprias assinaturas, nem podia fazê-lo qualquer agente externo, até que a chave fosse rotacionada. A chave agora é armazenada preenchida até o comprimento exigido, e uma chave já armazenada na forma curta é reparada automaticamente na primeira vez que é lida, então nenhum comerciante precisa rotacionar nada.
• Em lojas com PHP 8.0 ou anterior, ativar a conciliação por e-mail quebrava a página com um erro de servidor em vez de simplesmente não funcionar. O plugin agora verifica isso antes e deixa uma nota clara em seu registro. A função em si ainda precisa do PHP 8.1.
• Tarefas em segundo plano se acumulavam em dezenas de cópias de si mesmas na lista de ações programadas do WooCommerce. Corrigido em todos os sites onde o plugin programa algo, e as cópias que já estavam lá são limpas automaticamente.
• Uma notificação para o aplicativo móvel poderia ser perdida sem dar nenhum erro se enviada no momento errado.
• Avisos de PHP apareciam no registro do servidor a cada visita à página de “pagar pedido”, provenientes das gateways de Apple Pay e Google Pay. Para os compradores, nada estava quebrado, mas o log de depuração dessas gateways não estava registrando nada dessa etapa, então quem tentasse diagnosticar um problema ali estava olhando para uma falha e não para um silêncio. Reportado por um comerciante, e encontrado em três gateways em vez de na que foi reportada. Obrigado.
• Ativar o log de depuração para investigar um problema de pagamento com cartão produzia avisos em vez da informação para a qual havia sido ativado.
• O botão “Conectar com Google” das configurações de conciliação por e-mail nunca era exibido. Conceder o acesso já era possível preenchendo os dados do Google e clicando em “Salvar alterações”, então isso restaura um atalho, não desbloqueia a função.
• O plugin enviava para a loja um e-mail dizendo “Redsys não está enviando campos de tokenização” após pagamentos em que a Redsys havia enviado todos e cada um deles. A verificação por trás desse aviso testava uma variável que não existe em nenhuma parte do plugin, e um teste sobre algo que não existe sempre é verdadeiro, então o aviso aparecia em cada pagamento que salvava um cartão. Os comerciantes levavam isso ao seu banco, que respondia com razão que o terminal estava bem. O aviso agora informa apenas sobre ausências reais, e indica no registro qual campo estava faltando, a data de validade, a marca do cartão ou o número, em vez de dizer apenas que faltava algo. Também teve que parar de ler a marca depois que o plugin a converteu em um nome para exibição, porque essa conversão responde “Desconhecido” quando não há marca, o que teria tornado o aviso um que nunca poderia aparecer. Esse mesmo bloco escrevia “unknown” como número do cartão no log de depuração em cada pagamento, devido a um nome de variável com uma letra a mais; agora escreve o número mascarado real.
• Buscar na tela de tokens da Redsys (WooCommerce – Tokens Redsys) por e-mail ou por nome de usuário não encontrava nenhum cartão salvo a partir do vigésimo quinto. A tela pedia ao banco de dados uma página de tokens e buscava depois dentro dessa página, e como os pedia sem nenhuma ordem concreta, essa página era sempre os vinte e cinco tokens mais antigos da loja, então os cartões salvos recentemente, que são os únicos que alguém busca, tornavam-se inalcançáveis. A busca agora é feita no banco de dados, sobre todos os tokens, e a listagem chega do mais novo para o mais antigo. O contador que está acima da tabela e a lista abaixo já não podem discrepar, ordenar por nome de usuário ou por e-mail agora ordena toda a tabela em vez da página visível, e a tela já não carrega na memória todos os tokens da loja apenas para contá-los, coisa que em lojas com milhares de cartões salvos fazia em cada carga de página.