Publier un lien public attend une adresse confirmée
Partager un document avec des personnes nommées fonctionne comme toujours, que l’adresse du compte ait été confirmée ou non. Le publier sous un lien que n’importe qui peut ouvrir demande désormais la confirmation d’abord — sur toutes les voies qui le permettent, et c’est là qu’était le vrai défaut : deux des trois ne demandaient rien.
Deux sortes de partage vivent derrière un même dialogue, et ce ne sont pas le même acte. Nommer des adresses ne publie rien : chaque lecteur doit se connecter avec l’adresse que vous avez nommée, le document est donc remis à des personnes que vous avez choisies. Un lien, lui, pose sous /s/<token> une page de notre domaine que quiconque détient l’URL peut lire — une page sur l’internet ouvert, avec le contenu de quelqu’un d’autre dessus.
Pourquoi la seconde est retenue
Une adresse que personne n’a prouvée ne peut pas être récupérée, ne peut rien recevoir, et il n’en coûte rien d’en fabriquer cent. Cent comptes de ce genre qui publient des pages sous notre domaine ont la forme d’une campagne d’hameçonnage, et ce domaine est partagé avec tous ceux qui utilisent le produit.
Deux choses attendent donc une confirmation, et rien d’autre : publier un lien, et accumuler du stockage — un compte non confirmé garde dix documents. Convertir, télécharger, l’API, le connecteur et le partage avec des adresses nommées marchent dès la première minute.
Comment confirmer
Un code à six chiffres depuis le menu du compte, valable dix minutes. Qui se connecte par Google n’a jamais eu rien à confirmer : le fournisseur atteste l’adresse, et ces comptes ont toujours pu publier.
La vérification se lit au moment de la requête et n’est pas portée par votre session : une confirmation prend donc effet dès la requête suivante, et non à la prochaine connexion — ce que tout le monde attend après avoir tapé un code.
Trois portes, dont deux étaient ouvertes
Un lien se publie de trois façons : PUT /api/v1/documents/:id/share, POST /api/v1/documents?share=link et la voie propre à l’application, PUT /api/documents/:id/share. Seule la première demandait quelque chose. C’est là la vraie correction : la règle existait et avait deux trous, parce qu’une règle écrite trois fois n’est entretenue qu’à un seul endroit.
C’est une seule fonction désormais, et les trois l’appellent. Un refus est un 403 qui dit quoi faire : confirmer l’adresse, en précisant que le partage avec des adresses nommées fonctionne de toute façon.
Autres lectures : partager un document sous forme de lien et si un convertisseur en ligne est sûr.