- Navios
- 10 de maio de 2026 às 00:09 UTC
- Autor
- Kamo
- Enviar
- 6c3757d
Substituir a Operação Não SuportadaException stubs em cada provedor de nuvem com chamadas HTTP reais contra a API de administrador de cada infraestrutura: - Microsoft 365 → Microsoft Graph (/usuários, /domínios, /verificar, ...) usando o per-org OAuth token de acesso. - Google Workspace → Admin SDK Directory + Verificação do Site usando o per-org OAuth token de acesso. - Zoho Mail → Zoho Mail Admin API ******************* usando o token de acesso OAuth per-org. - IceWarp → IceWarp REST API ({serverUrl}/api/v1/...) usando o apiKey armazenado no provedorConfig. - Exchange (Online) → Microsoft Graph através de um cliente-credenciais token cunhado do locatárioId/clientId/clientSecret armazenado no provedorConfig. Também expandir os escopos OAuth solicitados pela Microsoft, Google e Zoho flui para que o token de administrador per-org tenha os privilégios do novo código necessidades (User.ReadWrite. Todos / Domínio. ReadWrite. Tudo pelo Graph, admin.directory.user / admin.directory.domain / siteverification for Google, ******************* para Zoho). Conexões existentes terá que re-autorizar com o consentimento do administrador para pegar os novos escopos. O encanamento HTTP compartilhado vive em ProviderHttpClient — Carregador / Basic / API-key Auth, codificação JSON e extração de mensagem de erro através dos vários envelopes de erro do provedor. O que ainda está furado (e porquê): - Notificador em tempo real na Microsoft 365, Google Workspace, IceWarp, e Exchange — API push-notificação de cada provedor precisa de um webhook público receptor hospedado pelo EmailService, além (para o Gmail) de um tópico Cloud Pub/Sub. A instalação desse sistema é a sua própria tarefa infra. - Bolsa on-prem (authMethod != OAUTH) — precisa da API SOAP EWS; o ExchangeProvider lança um erro claro nesse caminho até que EWS seja adicionado.