Patrick Alves

@Joffas Tenta essas configurações no ACBrMail: [Email] [email protected] Host=smtp-mail.outlook.com Port=587 [email protected] Pass=senha TLS=Sim SSL=Não [OAuth2] AccessTokenUrl=https://login.microsoftonline.com/common/oauth2/v2.0/token AuthorizationTokenUrl=https://login.microsoftonline.com/common/oauth2/v2.0/authorize ClientId=seu-client-id ClientSecret=(não informa) RedirectURI=http://127.0.0.1:1500 Scope=https://outlook.office.com/SMTP.Send offline_access TimeOut=120000 Verifica a configuração do app na microsoft. Supported account types = Accounts in any organizational directory and personal Microsoft accounts; Configure platforms = Mobile and desktop applications;

Alterações realizadas: * Adicionar propriedade UseAuthenticator para habilitar OAuth2; * Adicionar configuração para Proxy no OAuth2; @Joffas Adicionei a configuração do Proxy, só não consigo testar aqui... @EMBarbosa Só adicionei essas alterações por causa do amigo acima que precisou do proxy, a opção de ativar o OAuth já tinha um tempo que estava feita. Parece que ainda estão decidindo se vão adicionar a funcionalidade, vi em outro tópico que pode ter problemas com lgpd mas não entendi muito bem. Só pra informar: É possível usar o ACBrMail sem essas alterações para enviar o email com o OAuth2. O processo de autenticar e gerar o token de acesso pode ser feito usando componentes como TOAuth2Authenticator da paleta RestClient do Delphi, TIdHTTP da Indy ou THTTPSend da synapse (é o usado na implementação). Com o token de acesso gerado é só informar ele na propriedade Password do ACBrMail que vc vai conseguir fazer o login e enviar o email normalmente. ACBrMail.pas

@Leonardo Batista Verifica o numero da agencia (cooperativa) e do cliente, eles são usados para calcular o digito juntamente com o nosso numero. Pode ser que tenha alguma diferença do que vc esta informando para gerar o boleto para o que está definido no contrato do cliente.

Se usarmos GetAccessToken e a propriedade AccessToken estiver informada não vai ser chamado InteractiveAuthentication. A ideia do botão é justamente pedir o consentimento do usuário mesmo que em algum momento no passado já tenha sido feito isso, por isso que InteractiveAuthentication limpa os tokens, os que estavam informados não são mais válidos com o novo consentimento. Se ainda não foi dado consentimento, GetAccessToken vai fazer todo o processo. ACBrMail.Send já chama GetAccessToken capturando o AccessToken, mesmo que InteractiveAuthentication não faça todo processo e se InteractiveAuthentication ainda não foi chamado, GetAccessToken chama ele pra vc. Acho interessante por exemplo, na tela onde configura os parâmetros para envio do email colocar o botão chamando InteractiveAuthentication. No uso do programa para enviar os emails vai ser chamado ACBrMail.Send que chama GetAccessToken que se encarrega de obter ou atualizar o AccessToken. Supondo que no futuro vc precise alterar um scopo ou a chave secreta no seu app, é só o usuário ir nos parâmetros e clicar no botão para pedir o consentimento novamente e tudo volta a funcionar.

Pessoal eu acabei alterando o nome de algumas propriedades e métodos para seguir o padrão (inglês) adotado para o componente. Vai quebrar o código de alguém, mas achei que o melhor momento é agora que ainda não foi adicionado ao repositório. Desculpa ai!!! Alterações realizadas: * Mudar eventos de autenticação (antes e depois) para ACBrMail; * Alterar a classe Autenticador (SubComponent) para propriedade de classe (Persistent); * Alterar o nome da classe Autenticador para Authenticator (seguir padrão de nomenclatura) * Alterar o nome da property ExpiraEm para ExpiresIn (seguir padrão de nomenclatura); * Alterar as propriedades RefreshToken, AccessToken e ExpiresIn para leitura e escrita; * Alterar o nome do método AutorizacaoInterativa para InteractiveAuthentication (seguir padrão de nomenclatura); * Alterar o nome do método AtualizarAccessToken para GetAccessToken (seguir padrão de nomenclatura); * Adicionar propriedade ChallengeError para indicar se deve responder quando o login não é realizado com sucesso; * Adicionar método GetChallengeError para responder quando o login não é realizado com sucesso; * Corrigir identificação do login realizado (se for ESMTP, usuário e senha estiver informado, deve ser verificado SMTP.AuthDone); * Adicionar mensagem de erro decodificando o retorno quando não for possível realizar o login; * Enviar resposta com ChallengeError para capturar erros adicionais; * Alterar mensagens do tratamento de erros para inglês (seguir padrão de mensagens de erros); (unit1 é do exemplo) unit1.pas unit1.dfm ACBrMail.pas

@valterpatrick O meu problema foi que o email ([email protected]) que adicionei para testes no app não era email do gmail ([email protected]).

Parece que o Cliente ID que vc configurou no componente não existe. Verifica também se cadastrou corretamente o app no azure, quando cadastrei aqui segui essas orientações: https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app?tabs=client-secret. Em Supported account types eu selecionei Accounts in any organizational directory and personal Microsoft accounts e em configure platforms Mobile and desktop applications

No caso o email de teste cadastrado no app era de desenvolvedor e não tinha o gmail associado. Só removi esse email e utilizei outro.

Boa tarde Valter! Estava fazendo uns testes com outras contas do google aqui e me deparei com uma situação. A conta em questão era de desenvolvedor e não conta do gmail, dava erro ao tentar enviar e debugando percebi que o login no smtp não tinha sido feito, porém o componente indicava sucesso e tentava fazer o envio da mensagem. No google quando acontece erro no login do outh devemos responder um code challenge para capturarmos todas as mensagens. Fiz algumas modificações no componente para contornar isso... logo posto o fonte aqui. @RobsonLopes consegui enviar com essas configurações: [Email] [email protected] FromName=Patrick Host=smtp-mail.outlook.com Port=587 [email protected] Pass=strongpassword TLS=Sim [OAuth2] AccessTokenUrl=https://login.microsoftonline.com/common/oauth2/v2.0/token AuthorizationTokenUrl=https://login.microsoftonline.com/common/oauth2/v2.0/authorize ClientId=seuclientid ClientSecret=deixe em branco RedirectURI=http://127.0.0.1:1500 Scope=https://outlook.office.com/SMTP.Send offline_access

No seu passo a passo acredito ser necessário colocar o scopo, em tese vc tem que dar permissão pra alguma coisa, inclusive na tela de consentimento aparece a descrição dos acessos para os quais o usuário deve consentir

Acho que pode ser porque vc colocou o app para produção... acredito que a verificação é o processo que eles fazem pra certificar que é vc mesmo... Ainda não coloquei um app em produção... kkkk Se voltar o app para teste acho que não vai ter mais a verificação... Pra não ter erro nos testes que fiz eu coloquei o scopo global https://mail.google.com/

@valterpatrick Verifica se suas configurações estão parecidas com essa: [Email] [email protected] FromName=Patrick Host=smtp.gmail.com Port=587 [email protected] Pass=strongpassword TLS=Sim [OAuth2] AccessTokenUrl=https://oauth2.googleapis.com/token AuthorizationTokenUrl=https://accounts.google.com/o/oauth2/v2/auth ClientId=seuclientid ClientSecret=seuclientsecret RedirectURI=http://127.0.0.1:1500 Scope=https://mail.google.com/ * Lembrando que o scope deve estar definido também na configuração do aplicativo lá no Cloud Api Console do google

Vc conseguiu autenticar o usuário pelo componente? Capturou o AccessToken?

@valterpatrick UWP é para aplicativos publicados na Microsoft Store, acho que não é o seu caso! Tenta escolher app para computador.

o tipo de integração que vc está fazendo...