- Navios
- 5 de setembro de 2026 às 16:14 UTC
- Autor
- Kamo
- Enviar
- e09f341
O painel de calendários pessoais pediu-me para ir embora. que nunca foi mapeado -- então falhou em cada aberto -- e para o Google e Microsoft não tinha como autorizar nada. Este é o serviço metade de A fazer funcionar. O membro viaja no estado de OAuth, e essa é a única coisa que separa Os dois fluxos. O registro do aplicativo, os escopos e o redirecionamento de URI registrado são todos org-scoped e byte-identical para uma conexão pessoal e um organização-wide um, e o callback é sem sessão -- então sem um ID de membro em `state` uma pessoa que autorizasse sua própria conta do Google a linha da ORGANIZAÇÃO e remarcar a sincronização de cada colega em uma pessoa calendário. Ausente ainda significa a organização, que é o que cada estado escreveu Antes que isto pareça. /oauth/url, /oauth/status e DELETE/oauth take ?member=true, e o membro vem da SESSION em vez da consulta -- um cliente nomeando um membro id seria escolher o calendário para se conectar. salvar os upserts do MemberOuth por (membro, provedor) em vez de inserir como salvar a integração de membros faz. Inserir é certo para um servidor DAV digitado, uma vez que pessoa pode manter dois, e errado para uma bolsa: há uma conta do Google conectada em um momento, e re-consenting tem que substituí-lo em vez de deixar uma segunda linha para Os trabalhos de sincronização para ambos. GET /member/{memberId} agora existe e recusa qualquer ID exceto o do chamador. Largando o id e a leitura da sessão teriam sido mais simples e errados: Para que os calendários de outra pessoa fossem respondidos com os seus. Não existe direito que o abre -- uma bolsa privada do Google não é um ativo da organização, então um O administrador também não tem leitura.