# TRAIL DPS - LOT 1 Workspace - Correctif Authorization OVH 1.0.2

## Objet

Correction du refus HTTP 401 observe sur les routes protegees apres une authentification reussie, notamment `GET /api/v1/me/context`.

## Cause identifiee

Sur l'hebergement OVH Apache/FastCGI, l'en-tete HTTP `Authorization: Bearer ...` n'etait pas toujours expose a PHP sous `HTTP_AUTHORIZATION`. Le login fonctionnait car il ne depend pas de cet en-tete, alors que toutes les routes protegees etaient refusees avec `AUTH_REQUIRED`.

## Fichiers modifies

- `public/.htaccess` : recopie de l'en-tete Authorization dans l'environnement Apache avant la reecriture vers le front controller.
- `SRC/Infrastructure/Request.php` : lecture robuste de `Authorization` depuis les en-tetes natifs et les variables `HTTP_AUTHORIZATION`, `REDIRECT_HTTP_AUTHORIZATION` ou leurs variantes apres reecritures successives.
- `tests/run.php` : ajout d'un test contractuel du fallback FastCGI.
- `VERSION` : passage a `1.0.2-lot1`.

## Non-regression

- Aucun changement de schema MySQL.
- Aucune migration a rejouer.
- Aucun changement de contrat API.
- Aucun changement PLACE, Licence, Tracking ou mobile.
- Les jetons restent obligatoirement signes et lies au `client_instance_uuid`.

## Deploiement

Remplacer uniquement les fichiers presents dans ce ZIP en respectant l'arborescence, puis executer :

```bash
cd ~/programme/traildpsworkspace-staging
php -l SRC/Infrastructure/Request.php
php tests/run.php
```

Le resultat attendu est `8/8 tests reussis`.

## Test de recette

1. Appeler `POST /api/v1/auth/login`.
2. Reutiliser immediatement le meme access token et le meme `X-Client-Instance-UUID`.
3. Appeler `GET /api/v1/me/context`.
4. Verifier une reponse HTTP 200 avec `ADMIN_ORGA`, les permissions et les entitlements.