Compte
Un compte facultatif pour l’expéditeur : connexion par lien e-mail sur la page de livraison, et colis connexion dans un terminal.
Envoyer un fichier ne demande pas de compte : c’est toujours vrai, sur le service public comme sur
votre déploiement. Le compte est facultatif et ne concerne que l’expéditeur ; votre client n’en a
jamais besoin. Connecté, vos envois sont rattachés à votre compte. Un compte est sur la formule
gratuite, avec les mêmes limites qu’un envoi sans compte, ou sur la formule Pro
là où le service la propose : des fichiers plus gros et des liens qui durent plus longtemps. La
page Mon compte (/compte), en cliquant sur votre adresse en haut de la page, montre votre
formule, ses limites et votre abonnement.
Se connecter dans le navigateur
Pas de mot de passe : un lien envoyé par e-mail.
- Cliquez sur Se connecter en haut de la page de livraison, puis donnez votre adresse. Elle ne sert qu’à vous connecter.
- Ouvrez le lien reçu. La page qui s’ouvre demande encore un clic sur Me connecter : un antivirus de messagerie qui visite les liens ne peut donc pas l’utiliser à votre place.
- Le navigateur reste connecté 30 jours. Votre adresse s’affiche en haut de la page, à côté de Se déconnecter.
Le lien est valable 15 minutes et ne sert qu’une fois. La réponse est la même que l’adresse ait déjà un compte ou non : le compte est créé à la première connexion.
Se connecter dans un terminal
colis connexionLa CLI affiche un code court, BCDF-GHJK, et ouvre la page /connexion?code=BCDF-GHJK. Connectez-vous
si besoin, vérifiez que le code est celui de votre terminal, puis cliquez sur Autoriser ce
terminal. La CLI reçoit une session d’un an, gardée dans ~/.config/colis/compte.json (lisible par
vous seul), et l’envoie avec chaque colis envoyer vers ce serveur :
colis compte # l’adresse, la formule, ses limites et le renouvellement
colis deconnexion # révoque la session et l’oublieVoir CLI.
Ce que change un envoi connecté
- Le colis est rattaché au compte : l’accusé de réception garde l’identifiant du compte, et un
marqueur
accounts/owned/<compte>/<CODE>le liste pour le futur tableau de bord. - Sur un déploiement ouvert, la limite d’envois par heure (
DROP_UPLOADS_PER_HOUR) se compte par compte, plus par adresse : elle vous suit d’un réseau à l’autre. - Une session expirée ou révoquée fait échouer l’envoi en
401 INVALID_SESSION. Il n’est jamais envoyé anonymement à la place.
Sur votre déploiement
Les comptes s’activent avec deux variables, sans quoi « Se connecter » n’apparaît pas et les routes
de connexion répondent 503 ACCOUNTS_DISABLED ; tout le reste fonctionne.
| Variable | Rôle |
|---|---|
RESEND_API_KEY | La clé Resend qui envoie le lien de connexion. Jamais dans le dépôt. |
COLIS_MAIL_FROM | L’expéditeur, colis <connexion@votre-domaine>, sur un domaine vérifié chez Resend. |
DROP_URL | L’adresse publique : le lien de l’e-mail est construit à partir d’elle. |
DROP_ACCOUNTS_PREFIX | Le dossier des comptes dans le bucket, accounts par défaut. |
Les comptes vivent dans le même bucket, sous accounts/, sans base de données. La règle de cycle de
vie qui supprime les colis doit porter sur leur préfixe (drop/) et pas sur accounts/, sinon
les comptes disparaissent avec les colis. Les liens de connexion et les codes de terminal expirent
d’eux-mêmes ; une règle d’un jour sur accounts/login/ et accounts/device/ les efface du bucket.
Aucun secret n’est stocké : liens, sessions et codes de terminal sont des jetons aléatoires de 32 octets dont seul le
SHA-256 nomme l’enregistrement. Le cookie de session est HttpOnly, SameSite=Lax et Secure en HTTPS, et chaque
requête qui modifie la session vérifie l’en-tête Origin.
Les routes
| Route | Rôle |
|---|---|
POST /api/auth/login { email } | Envoie le lien. Toujours la même réponse 200, que l’adresse soit connue ou non. |
POST /api/auth/verify { token } | Utilise le lien, une seule fois, et pose le cookie de session. |
GET /api/me | Le compte de la session (cookie ou Bearer), sa formule et ses limites, ou 401. |
POST /api/auth/logout | Révoque la session. |
POST /api/auth/device | Un terminal demande un code : deviceCode, userCode, verificationUrl. |
POST /api/auth/device/approve { userCode } | Le navigateur connecté confirme le code. |
POST /api/auth/device/token { deviceCode } | Le terminal attend : pending, puis { token, account }, une seule fois. |
Les types et les codes d’erreur sont dans @colis/protocol ; voir Erreurs.