- Navios
- 5 de setembro de 2026 às 06:31 UTC
- Autor
- Kamo
- Enviar
- cbc238a
A guia CalDAV/CardDAV Connect via botão OAuth levantou um alerta dizendo o o fluxo não foi implementado e configurar credenciais através da API. Agora. executa uma conexão real, e a restrição que o moldou é que um redirecionamento OAuth URI vive em um console de uma TERCEIRA PARTE: Google e Entra cada segurar exatamente um endereço por inscrição do aplicativo, digitado por quem o registrou, então um segundo O fluxo não pode ter uma segunda chamada. Por conseguinte, ambos os fluxos caem no endereço já registrados e são contados separadamente por um marcador `flow` dentro de `state` -- OAuthFlowKinnd, ausente significando EMAIL assim callbacks no voo continuam completando onde Sempre o fizeram. Sem alteração da consola, sem nova rota de gateway, sem nova sessão isenção de uma via pública. O que o novo fluxo compartilha com o fluxo de caixa de correio que ele compartilha deliberadamente: - O registo da aplicação. GroupwareOAuthService pergunta PlatformOAuthClientResolver a mesma pergunta que a guia Configuração do Provedor pergunta -- Google Próprio da organização ou aplicativo Entra se ele registrou um lá, senão aplicativo de plataforma de Kamo -- assim credenciais introduzidas uma vez servir ambos, e uma org que não tem nenhum é dito assim em vez de ser enviado para uma tela de consentimento que rejeita um cliente id em branco. - Redireccionar o URI, ler de... Reafirmado. Uma cópia, porque um segundo seria um redirecionamento uri missmatch esperando para alguém mover uma chamada de volta, e já está coberto por OAuthRedirectUriTest contra a tabela OAuthCallbackPaths partilhada. O que não partilha é o subsídio. Pede Calendário e Contactos que o Gmail e o Admin SDK, e armazena seus tokens no org's ContatoIntegração em vez de sua linha de provedor de e-mail, então conectando calendários não pode perturbar uma caixa de correio que funcione. escopos de leitura-escrita, não .readonly: two-way sync é um interruptor que o membro muda após o consentimento, e os escopos são fixados no consentimento. O connect prova-se antes de relatar o sucesso -- ele lê a conta que acesso concedido e lista um calendário. Uma subvenção que não possa ler calendários, ou que voltou sem nenhum token de atualização, é armazenado e sinalizado com o que fazer sobre isso; ambos são invisíveis até uma sincronização dias depois. Credenciais são escritos na forma das quatro actualizações existentes já lidas pela tecla de texto (accessToken / re updateToken / tokenExpirar como epoch milis / clientId / clienteSecret / locatárioId), então uma conexão permanece viva sem mais trabalho, e GroupwareOAuthServiceTest fixa esses nomes: renomeando um compila, implementa, conecta-se, e pára de trabalhar uma hora depois. Ao lado, três fixações na mesma superfície: - GET /settings/integrations/org devolveu a entidade, que colocou o org's Credenciais criptografadas por AES blob em um corpo de resposta, um cache de navegador e cada log proxy entre aqui e o membro, em cada carga de uma tela que nunca lê o campo. Ambos os terminais de org agora retornam uma visão explícita da linha, informando apenas se uma credencial está em arquivo. - applyConfig leia 'bidirecional' enquanto cada tela de configurações sempre enviou 'bidirecionalSync', então o interruptor de duas vias nunca persistiu. Aceita ambos. - clearOrgCredentials, por isso desconecte esquece o subsídio sem redefinir o opções de sincronização que o membro escolheu -- que deleteOrgIntegration faria. A sincronização calendários e contatos em si é inalterada e ainda não construída: o Google e Microsoft GroupwareProviders são stubs delegando para o DB local, ProviderRegistry vincula KamoGroupwareProvider qualquer tipo de provedor, e As tarefas de sincronização do DaemonService só batem uma sincronizaçãoToken. Isto aterra a credibilidade daqueles vai precisar, e nada ainda lê.