- Spegnimento
- 5 settembre 2026 alle ore 16:14 UTC
- Autore
- Kamo
- Impegno
- e09f341
Il pannello dei calendari personali ha chiesto a GET di... che non è mai stato mappato -- così ha fallito su ogni aperto -- e per Google e Microsoft non ha avuto modo di autorizzare nulla affatto. Questa è la metà del servizio per farlo funzionare. Il membro viaggia nello stato OAuth, e questa è l'unica cosa che separa i due flussi. La registrazione dell'app, gli ambiti e l'URI redirect registrato sono tutti org-scoped e byte-identical per una connessione personale e un a livello di organizzazione, e il callback è senza sessione -- quindi senza un membro id in `state` una persona che autorizza il proprio account Google atterrerebbe la sovvenzione su la fila dell'ORGANIZZAZIONE e ridefinisce la sincronizzazione di ogni collega a una persona calendario. Absent significa ancora l'organizzazione, che è ciò che ogni stato scritto prima che sembri. /oauth/url, /oauth/status e DELETE /oauth take ?member=true, and the member proviene dalla SESSIONE piuttosto che dalla query -- un cliente che nomina un membro id sarebbe scegliere il cui calendario per connettersi. salvareMemberOAuth upserts da (membro, fornitore) piuttosto che inserire come salvareMemberIntegration lo fa. Insert è giusto per un server DAV digitato, dal momento che un persona può mantenere due, e sbagliato per una sovvenzione: c'è un account Google collegato alla volta, e riconsentare deve sostituirlo piuttosto che lasciare una seconda fila per i lavori di sincronizzazione per entrambi. GET /member/{memberId} ora esiste e rifiuta qualsiasi id ma il chiamante. Goccia l'id e la lettura della sessione invece sarebbe stato più semplice e sbagliato: chiedere per i calendari di qualcun altro sarebbe allora rispondere con il proprio. Non c'è diritto che lo apre -- una sovvenzione privata di Google non è un asset di organizzazione, quindi un l'amministratore non ha nemmeno letto su di esso.