Aperçu PDF cassé ?

[MedShake]

Rapporté par @marsante :
"Bug qui touche tous les modules base compris sur la V8. Quand on veut visualiser un document PDF l'aperçu renvoie vers la page de login, se loguer ne change rien, ouvrir dans un nouvel onglet permet de visualiser le document. Quand c'est un jpg l'aperçu fonctionne."

Peux-tu préciser de quel aperçu tu parles ? Je suppose qu'il s'agit du dépliement d'une ligne d'historique ?
Je n'arrive pas à reproduire.

[marsante]

Oui l'aperçu au clique dans l'historique. Pour reproduire, il est possible de lancer une installation fraîche via le vagrant file du dépôt et d'être sur firefox ... En écrivant la phrase précédente ça m'a donné une idée, je viens de tester sur chromium et ça fonctionne en effet sur le module osteo et base parfaitement bien ... Peut-être un traitement un peu violent du cookie par firefox ou un truc à voir sur la politique CORS. Je vais regarder du coup :D

[marsante]

je viens de trouver ça dans les logs :

Le cookie « PHPSESSID » n’a pas de valeur d’attribut « SameSite » appropriée. Bientôt, les cookies dont l’attribut « SameSite » est manquant ou défini avec une valeur invalide seront traités comme « Lax ». Cela signifie que le cookie ne sera plus envoyé dans des contextes tiers. Si votre application dépend de la disponibilité de ce cookie dans de tels contextes, veuillez lui ajouter l’attribut « SameSite=None ». Pour en savoir plus sur l’attribut « SameSite », consultez https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

[MedShake]

J'ai aussi un message, mais voilà vers quoi cela renvoie, je n'ai pas encore analysé totalement :
https://developer.mozilla.org/en-US/docs/Web/Privacy/Storage_access_policy/Errors/CookiePartitionedForeign

Je n'ai pas encore analysé causes et conséquences, mais visiblement, il y a un durcissement de la politique d'accès aux ressources qui ne sont pas sur les mêmes canaux.

[marsante]

j'ai trouvé également ses explications dans le php ini

; Add SameSite attribute to cookie to help mitigate Cross-Site Request Forgery (CSRF/XSRF)
; Current valid values are "Strict", "Lax" or "None". When using "None",
; make sure to include the quotes, as none is interpreted like false in ini files.
; https://tools.ietf.org/html/draft-west-first-party-cookies-07
session.cookie_samesite =

[MedShake]

Curieux curieux tout ça. Ma piste n'est probablement pas la bonne car nous servons les PDF sur le même domaine et il n'y a donc pas de raison que ça coince. La tienne me laisse perplexe. Je ne comprends pas ce qu'un cookie de session pourrait faire là-dedans.

[marsante]

Je n'ai pas pris le temps de trop regarder non plus.

Pour l'hypothèse cookie

Note : Les normes relatives aux Cookies SameSite ont récemment changé de telle sorte que :
Le comportement d'envoi des cookies si SameSite n'est pas spécifié est SameSite=Lax. Auparavant, le comportement par défaut était que les cookies étaient envoyés pour toutes les requêtes.
Les cookies avec SameSite=None doivent désormais également spécifier l'attribut Secure (c'est-à-dire qu'ils nécessitent un contexte sécurisé).

Les options ci-dessous couvrent le nouveau comportement. Voir le tableau Compatibilité des navigateurs pour des informations sur la mise en œuvre spécifique des navigateurs (lignes : « SameSite : Defaults to Lax » et « SameSite : Secure context required »).

Est-ce que sinon l'aperçu est une sorte d'iframe et il y aurait une réécriture de l'url qui perturberait la vérification du domaine ?

[marsante]

Quand on regarde les cookies c'est le seul non sécurisé

[marsante]

J'ai fait varier les différents paramètres jusqu'à mettre en lax et en effet ça ne change rien, le cookie est innocent :D

[marsante]

J'arrive Quel que soit le réglage du cookie à faire inception par contre. C'est-à-dire qu'en me connectant dans l'aperçu ça me renvoie à la page d'accueil, mais en naviguant jusqu'au patient et en ouvrant le document dans l'aperçu de l'aperçu ça fonctionne. Bizarre cette affaire.