Re (encore moi) désolé, mais question sur les iframes cette fois.
Il me semble l’avoir déjà posé (re-désolé) mais je ne retrouve pas dans le forum (c’est sans doute dans l’ancien) ni dans la doc : quand on essaye de mettre en iframe un wiki dans un autre, si à l’affichage tout va bien, dès qu’on essaye de modifier une fiche d’un wiki depuis un autre, les navigateurs bloquent pour des questions de CSP ou X-frame.
Côté allowed_methods_in_iframe les 2 wikis sont bien réglés en [‹ iframe ›,‹ editiframe ›,‹ bazariframe ›,‹ render ›,‹ pdf ›,‹ pdfiframe ›,‹ all ›]
et
htmlPurifierActivated en false (je pensais de mémoire que c’était ce param qui était à la source)
Qu’est ce qui doit donc être modifié pour que l’édition soit possible en iframe ?!
Merci
a priori, ca se gère aussi au niveau de la configuration du serveur, et même si bien configure dans yeswiki, c’est la conf serveur qui a le dernier mot.
Il dit quoi dans ses en têtes HTTP le serveur qui sert l’iframe?
Les entêtes de la réponse :
accept-ranges bytes
| access-control-allow-credentials | true |
|---|---|
| access-control-allow-headers | X-Requested-With, Location, Link, Slug, Accept, Content-Type |
| access-control-allow-methods | POST, GET, OPTIONS, DELETE, PUT, PATCH |
| access-control-allow-origin | * |
| access-control-expose-headers | Location, Slug, Accept, Content-Type |
| access-control-max-age | 86400 |
| age | 0 |
| cache-control | no-store, no-cache, must-revalidate |
| content-security-policy | frame-ancestors ‹ none ›; |
| content-type | text/html; charset=UTF-8 |
| date | Tue, 12 Sep 2023 11:49:29 GMT |
| expires | Thu, 19 Nov 1981 08:52:00 GMT |
| pragma | no-cache |
| server | Apache |
| set-cookie | YesWiki-main=1df2ss7ctga2bnfdf7va8fl1ss; path=/; HttpOnly; SameSite=Lax |
| set-cookie | name=WikiAdmin; expires=Tue, 12-Sep-2023 12:49:30 GMT; Max-Age=3600; path=/; HttpOnly; SameSite=Lax |
| set-cookie | token=20230912-11-49-300%242y%2409%24QCyqz2FLOF0lfRncqhxPu.Ffnc4BfhJjGmex5yN66za.x6LixkNTW; expires=Tue, 12-Sep-2023 12:49:30 GMT; Max-Age=3600; path=/; HttpOnly; SameSite=Lax |
| vary | Accept-Encoding |
| via | 1.1 varnish (Varnish/6.3), 1.1 varnish (Varnish/6.3) |
| x-cache | MISS |
| x-cache-hits | 0 |
| x-content-encoding-over-network | gzip |
| X-Firefox-Spdy | h2 |
| x-frame-options | deny |
| x-powered-by | PHP/8.1.16 |
c’est lui qui pose problème : iframe non autorisé
cf. linux - Change the X-Frame-Options to allow all domains - Stack Overflow
Il faut soit virer cette regle pour que les iframes soient possible de partout, soit mettre un ALLOW-FROM et préciser le ou les domaines pouvant intégrer des iframes
Nickel merci, je vais voir ça avec l’hébergeur, je suis pas sûr qu’on ait la main là dessus.
En fait, si l’affiche dans le site distant fait appel à l’url en /edit, le réglage proposé va refuser l’inclusion iframe.
Pour contourner :
- soit mettre une url en
editiframe - soit modifier la valeur de
allowed_methods_in_iframepour mettre EXACTEMENTallen remplacement de['iframe','editiframe','bazariframe','pdf','all']quand on passe parGererConfig
Sinon YesWiki rajoute "X-frame-Options: deny" pour faire le blocage pour les vieux navigateurs.
Si le problème persiste en utilisant all (c’est-à-dire dans wakka.config.php avoir 'allowed_methods_in_iframe' => 'all',) ou en utilisant l’url editiframe, c’est qu’il y a un souci.
Mais vu les en-têtes fournies, le yeswiki est à l’origine du souci et pas l’hébergeur.
Merci, en effet cela fonctionne en mettant ‹ all › dans le GererConfig.
J’avais cependant testé avant, de modifier directement le wakka.config en mettant la même chose, mais ça n’est pas passé. À part une erreur de casse ou ce genre de chose de mon côté à la frappe, on est d’accord que si ça marche dans un sens, c’est censé marcher dans l’autre aussi ?
pour que ça fonctionne dans wakka.config.php il faut taper 'all' avec des guillemets, mais pour que ça fonctionne dans GererConfig, il faut mettre all sans les guillemets, tout seul