- Utilise les mêmes règles de filtrage que `elastic-proxy-main-view` pour déterminer les index autorisés.
- Les résultats sont extraits des champs `highlight` retournés par Elasticsearch.
---
La gestion des permissions repose sur une séparation entre la logique d’accès (gérée côté Django) et le moteur de recherche (Elasticsearch). Chaque groupe d’utilisateurs (UserGroup) se voit attribuer un alias Elasticsearch portant son identifiant, associé à un filtre contenant uniquement les identifiants des jeux de données auxquels il a accès. Lorsqu’un utilisateur interroge Elasticsearch via le reverse proxy (Rproxy), ce dernier sélectionne dynamiquement les alias correspondant à ses droits et les utilise pour construire la requête.
#### avantages
* La logique de sécurité reste côté Django, Elasticsearch ne gère que des filtres prédéfinis.
* Les filtres sont pré-calculés dans les alias : aucune logique de permission n’est évaluée au moment de la requête.
* Les clients (frontend, scripts) interagissent avec Elasticsearch via des requêtes classiques (`_search`), sans se soucier des droits.
* Impossible pour un utilisateur d'accéder à des données non autorisées, car les alias ne pointent que vers des UUID explicites.
* Possibilité d’avoir des alias globaux (`main`, `harvest`, `pages`, etc.) ou propres à des groupes d’utilisateurs.
* Les signaux Django synchronisent automatiquement les alias lors des changements de permissions.
#### inconvénients
* La mise à jour des alias nécessite une coordination entre les signaux, Celery et Elasticsearch.
* Un alias par groupe peut entraîner une explosion du nombre d’alias si les groupes sont nombreux.
* En cas d’échec de tâche Celery ou de mise à jour d’alias, les données visibles peuvent ne pas refléter les droits réels.
* Les filtres sont statiques : ils ne prennent pas en compte des conditions dynamiques au moment de la requête.
