storage-p

Documentation de l'API

La même API REST que celle utilisée par le client web. Chaque élément est chiffré dans votre navigateur avant de quitter l'appareil — le serveur ne voit que du texte chiffré et n'a aucun moyen de le lire. Utilisez-la pour construire vos propres clients ou pour donner à une intégration un accès limité et confirmable à quelques éléments. URL de base : https://storage-p.com

Spécification OpenAPI (lisible par machine, pour les intégrations) /openapi.yaml

Guides

Des tutoriels de bout en bout de ce que fait réellement storage-p — fondés sur les fonctionnalités réelles, sans rien inventer.

Auto-hébergement sur votre propre serveur

Exécutez storage-p en conteneur Docker derrière Caddy, sur votre domaine. Caddy sert le client statique et fait du reverse-proxy de /api vers le backend ; la base de données SQLite est chiffrée au repos avec SQLCipher. Vous le gérez de bout en bout — personne d'autre ne détient les clés.

Stocker et générer des clés SSH / TLS

Générez des clés SSH Ed25519 (format OpenSSH) et des certificats TLS auto-signés dans l'onglet Générateurs, ou importez vos fichiers de clés/certificats existants (jusqu'à 1 Mo). Le matériel privé est chiffré dans le navigateur avant l'envoi : il n'existe donc jamais en clair sur le serveur.

Liens à usage unique, burn-after-read

Partagez un élément ou un dossier entier via un lien dont la clé de déchiffrement ne vit que dans le fragment de l'URL (#…) — la partie que les navigateurs n'envoient jamais au serveur. Définissez un TTL et un nombre de vues ; après la dernière vue, les données ne peuvent plus être ouvertes.

Tokens API limités avec confirmation

Créez un token qui ne peut lire que les éléments ou projets que vous autorisez. Activez la confirmation à chaque lecture : chaque accès est suspendu jusqu'à ce que vous l'approuviez depuis la cloche de l'application ou un message Telegram ; ajoutez une limite de débit et une expiration. L'intégration reçoit l'élément encore chiffré ainsi qu'une clé d'accès à usage unique pour le déchiffrer localement.

Projets et accès en équipe

Transformez un dossier en projet doté de sa propre clé. Accordez à un autre utilisateur un accès en lecture ou en écriture : la clé du projet est scellée avec sa clé publique (X25519), il travaille donc avec les éléments les plus récents sans que le serveur n'en voie jamais de copie lisible. Révoquez n'importe quel accès à tout moment.

TOTP / 2FA intégré

Stockez le secret TOTP d'un identifiant juste à côté et lisez le code rotatif en direct au même endroit — storage-p fait aussi office d'authentificateur. Vous pouvez également protéger votre propre compte avec une double authentification TOTP.

Importer depuis un autre gestionnaire

Importez un fichier Bitwarden JSON, un CSV KeePass, ou tout CSV avec les colonnes name/username/password/url/notes. L'analyse et le chiffrement s'exécutent sur votre appareil : les entrées sont rechiffrées avec votre clé et ne sont jamais envoyées en clair.

Documentation de l'API · API

Authentification

Obtenez un token d'accès via register/login, puis envoyez-le en tant que token Bearer. Les tokens d'accès sont de courte durée (15 min) ; renouvelez-les avec le refresh token.

Authorization: Bearer <access_token>

Auth

Inscription, connexion et maintien de la session. Le mot de passe maître ne quitte jamais le navigateur — seul un auth-hash Argon2id est envoyé.

POST /api/v1/auth/register
Créer un compte. Le client choisit les paramètres KDF et envoie sa clé privée déjà chiffrée.
Corps{ email, master_password, kdf_salt_b64, kdf_memory_kib, kdf_iters, kdf_parallelism, pubkey_b64, privkey_enc_b64 }
Réponse{ access_token, refresh_token, user_id, kdf_* }
POST /api/v1/auth/login
Se connecter. Renvoie les tokens ainsi que le sel KDF dont le client a besoin pour dériver la clé du coffre-fort.
Corps{ email, master_password, totp_code? }
Réponse{ access_token, refresh_token, user_id, kdf_*, totp_required }
POST /api/v1/auth/refresh
Échanger un refresh token contre un nouveau token d'accès de courte durée.
Corps{ refresh_token }
Réponse{ access_token, refresh_token }
POST /api/v1/auth/logout Bearer
Révoquer le refresh token actuel.
Réponse{ ok }
POST /api/v1/auth/totp/setup Bearer
Activer la double authentification TOTP pour le compte.
Corps{ secret_b32, current_code }
Réponse{ ok }

Vault

CRUD sur vos éléments. Tout entre et sort déjà chiffré ; le serveur ne stocke et ne renvoie que du texte chiffré.

GET /api/v1/vault Bearer
Lister tous les éléments (texte chiffré) de votre coffre-fort.
Réponse[ { id, meta_enc_b64, body_enc_b64, version, created_at, updated_at } ]
POST /api/v1/vault Bearer
Ajouter un élément. meta/body sont déjà chiffrés côté client avant l'envoi.
Corps{ meta_enc_b64, body_enc_b64, blind_index_b64? }
Réponse{ id, ... }
GET /api/v1/vault/:id Bearer
Récupérer un élément par son id.
PUT /api/v1/vault/:id Bearer
Mettre à jour un élément ; expected_version protège contre l'écrasement d'une modification plus récente.
Corps{ meta_enc_b64?, body_enc_b64?, expected_version }
DELETE /api/v1/vault/:id Bearer
Déplacer un élément vers la corbeille (suppression réversible).
GET /api/v1/vault/trash Bearer
Lister les éléments actuellement dans la corbeille.
POST /api/v1/vault/:id/restore Bearer
Restaurer un élément depuis la corbeille.
DELETE /api/v1/vault/:id/purge Bearer
Supprimer définitivement un élément — irréversible.

Sharing

Deux façons de transmettre un secret à quelqu'un : un lien à usage unique burn-after-read, ou une livraison de bout en bout sealed-box à un autre utilisateur.

POST /api/v1/share Bearer
Créer un lien à usage unique. La clé de déchiffrement réside dans le fragment de l'URL et n'atteint jamais le serveur.
Corps{ payload_b64, nonce_b64, ttl_secs, max_views }
Réponse{ id, expires_at }
GET /api/v1/share/:id
Ouvrir un lien à usage unique. Détruit après le nombre de vues autorisé.
Réponse{ payload_b64, nonce_b64 }
GET /api/v1/users/lookup?email= Bearer
Trouver la clé publique d'un utilisateur par e-mail afin de partager de bout en bout avec lui.
Réponse{ user_id, pubkey_b64 }
POST /api/v1/shares/user Bearer
Envoyer un élément à un autre utilisateur, scellé avec sa clé publique — lui seul peut l'ouvrir.
Corps{ to_email, payload_b64 }
GET /api/v1/shares/incoming Bearer
Lister les éléments que d'autres utilisateurs ont partagés avec vous.
DELETE /api/v1/shares/:id Bearer
Supprimer un partage entrant ou sortant.

Tokens & confirmations

Les tokens limités permettent à une intégration de lire des éléments sélectionnés, éventuellement soumis à votre confirmation dans l'application ou via Telegram.

GET /api/v1/tokens Bearer
Lister vos tokens API.
POST /api/v1/tokens Bearer
Créer un token limité pour une intégration — choisir quels éléments il peut lire et si chaque lecture nécessite une confirmation.
Corps{ name, item_ids[], require_confirmation, rate_limit_per_hour, ttl_secs }
Réponse{ id, token, expires_at }
DELETE /api/v1/tokens/:id Bearer
Révoquer un token immédiatement.
GET /api/v1/confirmations/pending Bearer
Lister les demandes d'accès en attente de votre approbation.
POST /api/v1/confirmations/:id/resolve Bearer
Approuver ou refuser une demande en attente.
Corps{ decision: "approve"|"deny" }
GET /api/v1/api/vault/:id Bearer (scoped token)
Comment une intégration lit un élément limité. Si une confirmation est requise, le premier appel renvoie un confirmation_id à interroger jusqu'à votre approbation.

Tokens API limités (pour les intégrations)

Créez un token limité dans l'interface (Tokens API). Il ne peut lire que les éléments autorisés, et les lectures peuvent exiger une confirmation. Flux : le premier GET renvoie un confirmation_id avec le statut pending_confirmation ; le propriétaire approuve dans l'application ou via Telegram ; répétez le GET avec ?confirmation_id= pour recevoir l'élément (toujours chiffré côté client).

Notes

meta_enc / body_enc sont nonce(24)‖ciphertext, chiffrés avec la clé du coffre-fort dérivée du mot de passe maître. Le serveur ne peut pas les déchiffrer.