Cas d’usage
Un livrable confidentiel
Un mot de passe que le client tape une fois, une durée courte, et un code qui disparaît au premier téléchargement.
curl -X POST https://drop.example.com/api/transfers \
-H 'content-type: application/pdf' \
-H "x-colis-filename: $(printf %s contrat.pdf | jq -sRr @uri)" \
-H 'x-drop-expires-in: 3600' -H 'x-drop-once: 1' \
-H 'x-drop-passphrase: open%20sesame' \
--data-binary @contrat.pdfLa situation
Ce qui se passe vraiment.
Le problème
Un contrat, des accès, un export de fichier clients : le lien ne doit pas traîner des mois dans une boîte mail, ni fonctionner pour quelqu’un d’autre.
Ce que colis y fait
Sur la page d’envoi, choisissez la durée de conservation (de dix minutes au maximum de votre déploiement), un mot de passe pour ce colis, et la destruction après le premier téléchargement. Le mot de passe est haché avec scrypt : jamais stocké en clair, jamais récupérable. L’aperçu reste gratuit ; le téléchargement consomme le code, et deux téléchargements lancés en même temps ne l’obtiennent pas tous les deux.
À surveiller
Les pièges faciles.
Deux canaux
Envoyez le code par un canal et le mot de passe par un autre. Le code seul ne vaut alors plus rien.
Les essais sont limités
Dix mauvais mots de passe depuis un même client, ou cinquante sur un même code, le verrouillent quinze minutes. Les compteurs vivent dans la mémoire de chaque instance : sur un hébergement serverless, ils ralentissent les essais plus qu’ils ne les arrêtent.
Un mot de passe perdu est perdu
Personne ne peut le relire ni le réinitialiser, pas même vous. Le colis n’est alors plus qu’un fichier qui expire.
Voir aussi
D’autres façons de livrer.
Vous envoyez. Ils valident. Vous le savez.
Votre stockage, une page de livraison à votre nom, un webhook à chaque étape. Rien d’hébergé chez un tiers.