- Spegnimento
- 5 settembre 2026 alle ore 06:31 UTC
- Autore
- Kamo
- Impegno
- cbc238a
Il Connetto della scheda CalDAV/CardDAV tramite il pulsante OAuth ha sollevato un avviso dicendo che flusso non è stato implementato e configurare le credenziali tramite l'API. Ora corre una connessione reale, e il vincolo che ha plasmato è che un reindirizzamento OAuth URI vive in una console di THIRD PARTY: Google e Entra ciascuno tengono esattamente uno indirizzo per registrazione app, digitato da chiunque l'abbia registrato, quindi un secondo il flusso non può avere un secondo richiamo. Entrambi i flussi quindi atterrare sull'indirizzo già registrato e viene detto a parte un marcatore `flusso` dentro `stato` -- OAuthFlowKind, assente significa EMAIL così callback in volo continuare a completare dove L'hanno sempre fatto. Nessun cambio console, nessun nuovo percorso gateway, nessuna nuova sessione esenzione per un percorso pubblico. Ciò che il nuovo flusso condivide con il flusso di posta condivide deliberatamente: - La registrazione dell'app. GroupwareOAuthService chiede PlatformOAuthClientResolver la stessa domanda che il Provider Setup scheda chiede -- l'organizzazione OWN Google o Entra app se ha registrato uno lì, altrimenti app piattaforma di Kamo -- così le credenziali inserite una volta servono entrambi, e un org che non è stato detto così piuttosto che inviare a una schermata di consenso che rifiuta un client id vuoto. - L'URIDICA Reindirizzante, letta da... ribadito. Una copia, perché un secondo sarebbe un redirect uri mismatch in attesa per qualcuno di spostare un callback, ed è già coperto da OAuthRedirectUriTest contro la tabella OAuthCallbackPaths condivisa. Ciò che non condivide è la sovvenzione. Richiede Calendario e Contatti piuttosto che Gmail e l'Admin SDK, e memorizza i suoi gettoni sull'org ContattoIntegrazione piuttosto che la sua riga di e-mail provider, in modo da collegare i calendari non può disturbare una casella di posta funzionante. Sconti di lettura-scrittura, non .readonly: sincronizzazione a due vie è un interruttore il membro capovolge dopo il consenso, e gli scopi sono fissati al consenso. La connessione si dimostra prima di segnalare il successo -- legge l'account che ha concesso l'accesso e elenca un calendario. Una sovvenzione che non può leggere calendari, o che è tornato senza token di aggiornamento, è memorizzato e contrassegnato con cosa fare circa esso; entrambi sono altrimenti invisibili fino a quando una sincronizzazione corsa giorni dopo. Credenziali sono scritti nella forma i quattro rinfrescatori esistenti già letti da chiave di stringa (accessToken / rinfrescaToken / tokenExpiry come epoca millis / clientId / clientSecret / inquilino), quindi una connessione rimane viva senza ulteriori lavori, e GroupwareOAuthServiceTest spilla quei nomi: rinominando uno compila, distribuisce, collega, e smette di lavorare un'ora dopo. Accanto, tre correzioni nella stessa superficie: - GET /settings/integrations/org ha restituito l'entità, che ha messo l'org AES-encrypted credenziali blob in un corpo di risposta, una cache del browser e ogni registro proxy tra qui e il membro, su ogni carico di uno schermo che mai legge il campo. Entrambi gli endpoint org ora restituiscono una visione esplicita della riga, riferire solo WHETHER una credenziale è sul file. - applicareConfig leggere `bidirezionale` mentre ogni schermata delle impostazioni ha sempre inviato `bidirectionalSync`, quindi l'interruttore bidirezionale-sync non perse mai. Accetta entrambi. - ClearOrgCredentials, quindi Disconnect dimentica la sovvenzione senza resettare la opzioni di sincronizzazione che il membro ha scelto -- che deleteOrgIntegration avrebbe. La sincronizzazione dei calendari e dei contatti è invariata e ancora inedita: Google e Microsoft GroupwareProviders sono stubs delegare al DB locale, ProviderRegistry lega KamoGroupwareProvider qualsiasi tipo di fornitore, e I lavori di sincronizzazione di DaemonService solo urtano una sincroniaToken. Questo atterra le credenziali quelle avrà bisogno, e nulla ancora lo legge.