matmiranda / wirecard-dotnet

🚾 - API do Wirecard para .NET - SDK
https://dev.wirecard.com.br/
MIT License
2 stars 1 forks source link

HttpClient sempre utiliza o primeiro access token fornecido #25

Closed christiansk closed 5 years ago

christiansk commented 5 years ago

Preciso usar a biblioteca em um marketplace onde os vendedores serão os recebedores primários, e a plataforma será o recebedor secundário. Para isso preciso ser capaz de fazer chamadas passando o access token dos vendedores, além de chamdas usando o token do próprio APP.

No entanto, quando instancio um WirecardClient passando um access token diferente, as chamadas continuam usando o access token fornecido no primeiro WirecardClient que foi criado. No meu caso as chamadas à API estão sempre sendo feitas em nome do marketplace, nunca em nome dos vendedores.

Em outras palavras, o HttpClient singleton está "memorizando" o primeiro access token utilizado pela aplicação, e não permite fazer chamadas usando um access token de outra conta.

Acho que a solução seria criar um HttpClientpara cada access token diferente, no lugar de um único para a aplicação. Ou então manter um único HttpClient mas permitir que o header de autorização seja substituído por um token diferente nas chamadas onde isso for necessário.

@matmiranda: O que você acha, faz sentido esse raciocínio? Ou eu deveria estar usando a biblioteca de um jeito diferente nesse cenário?

matmiranda commented 5 years ago

@christiansk ,

Tem um exemplo aqui passando accessToken do recebedor/vendedor.

Só faz sentido quando você tiver 2 marketplaces.

christiansk commented 5 years ago

@matmiranda ,

O problema específico que estou tendo é o seguinte: para criar um pedido onde o recebedor primário é o vendedor (marketplace será o secundário), preciso usar o access token do vendedor. Além disso, preciso da chave pública do vendedor para criptografar os dados do cartão.

Mas não consigo obter a chave pública do vendedor, pois ao chamar o método ClassicAccountController.GetPublickey() estou recebendo a chave pública do marketplace. Isso acontece mesmo ao usar um WirecardClient criado com o access token do vendedor (já que em uma chamada anterior precisei criar um client com o access token do marketplace, e nesse momento o HttpClient "memoriza" o token do APP para usar na autenticação).

Não entendi o cenário com 2 marketplaces a que você se refere. No meu caso tenho um único marketplace, mas preciso usar o access token e a chave pública do vendedor porque ele será o recebedor primário.

Obrigado novamente pelo apoio!

matmiranda commented 5 years ago

@christiansk ,

O que eu posso fazer é criar outro método passando accessToken do recebedor:

public async Task<PublicKeyAccountWirecardResponse> GetPublickey(string accessToken);

Isso já resolve o seu problema.

Vou lançar outra atualização do pacote.

christiansk commented 5 years ago

@matmiranda ,

Sim, esse overload resolve meu problema para obter a chave pública. Mas na sequencia vou ter o mesmo problema para criar o pedido e o pagamento em nome do vendedor, então acho que o mesmo precisaria ser feito nos métodos correspondentes.

Só para deixar claro, segundo o pessoal da Wirecard:

no caso de marketplaces, o accesstoken que deverá ser utilizado deve ser sempre do receiver do tipo PRIMARY

Obrigado de novo!

matmiranda commented 5 years ago

@christiansk,

Agora entendi aonde você quer chegar...

O ideal é criar um HttpClient para cada access token diferente.

Estou sem tempo para fazer isso... Sábado agora posso tentar....

Se você quiser contribuir, fica a vontade.

christiansk commented 5 years ago

@matmiranda ,

Blz, obrigado. Infelizmente não vou conseguir fazer isso agora. Se tiver um tempo mais para a frente, tento voltar nisso. :+1:

matmiranda commented 5 years ago

@christiansk ,

Nova versão disponível 1.3.5.

Adicionei novo método que altera o accesstoken aqui.

Coloquei tbm um exemplo aqui no teste unitário.

christiansk commented 5 years ago

@matmiranda Beleza Matheus, assim já consigo fazer o que preciso usando a biblioteca. :tada: Obrigado!