Piwigo.org

cmenness · 2012-09-27 11:49:36

Bonjour,
Lorsque Piwigo (version 2.4.4 mais les précédentes aussi) est installé derrière un reverse proxy, il y a un bug lors de la génération automatique des miniatures.
Voici la description :
- On accès à la galerie via une URL externe (visible sur Internet)
- Le navigateur affiche la page, puis lance des requeêtes HTTP pour chacune des miniatures
- Quand ces miniatures n'existent pas, la génération est lancée, et le navigateur retente qq secondes plus tard pour mettre à jour la miniature.
=> c'est lorsque de ces appels pour voir si la miniature est enfin génére qu'il y a un bug. C'est l'URL interne qui est utilisée. Donc les requêtes échouent.

Quand on accès à la galerie depuis le réseau interne, tout se passe bien.
Pouvez-vous confirmer mon analyse ?

Gotcha · 2012-09-27 12:06:08

Bonjour,

Je ne suis pas un specialiste mais dans la configuration (Via le plugin LocalFiles Editor !) il y a un paramètre pour configurer l'URL de votre galerie. D'après ce que je crois comprendre ce paramètre pourrait vous aider.

cmenness · 2012-09-27 12:32:49

Merci,
Mais quel serait le paramètre à ajouter ? le fichier est vide.

Gotcha · 2012-09-27 13:34:03

Sur la même page, sur le coté droit, vous pouvez consulter le contenu du fichier initial lequel contient les explications (en Anglais) des divers paramètres.
Le lien se nomme Afficher le fichier "config_default.inc.php"
Vous ne copiez que ce que vous allez modifier. Ne copiez pas tout !

Le partie qui vous concerne :

// gallery_url : you can set a specific URL for the home page of your
// gallery. This is for very specific use and you don't need to change this
// setting when move your gallery to a new directory or a new domain name.
$conf['gallery_url'] = null;

cmenness · 2012-09-27 14:29:20

Cela ne fonctionne pas. J'ai mis l'adresse externe mais le comportement est le même. J'ai l'impression qu'il existe un autre paramètre qqpart ou le nom du serveur est modifiable (qui doit contenir le nom interne et qui devrait contenir le nom externe). Mais je ne trouve pas.

Existe-t-il d'autre paramètres ?

rvelices · 2012-09-27 14:50:19

Si le chemin d'acces est identique en mode externe et interne (cad que seulement le serveur/port change), vous pouvez modifier a la main la fonction get_absolute_root_url (dans le fichier include/functions_url.inc.php)

cmenness · 2012-09-27 17:17:44

C'est pas du paramétrage ça ? A la prochaine montée de version, je suis bon pour recommencer ?

Gotcha · 2012-09-28 09:41:16

cmenness a écrit:
C'est pas du paramétrage ça ? A la prochaine montée de version, je suis bon pour recommencer ?

Oui :-/
Mais essayez de voir si effectivement ca solutionne votre problème. Il sera temps par la suite de voir comment rendre cette adaptation durable.

rvelices · 2012-09-28 10:25:54

cmenness a écrit:
C'est pas du paramétrage ça ? A la prochaine montée de version, je suis bon pour recommencer ?

Ca ne peut pas etre du parametrage si vous devez acceder a votre site de deux manieres differentes...
- par exemple piwigo.org/showcase/ et fr.piwigo.org/showcase/ sont la meme installation et heuresement nous n'avons pas ce parametre car sinon ca ne marchera pas. ca sera pareil dans votre cas ...
- ensuite pour les emails /flux rss/services web , il faut une adresse differente selon que vous l'accedez en externe ou en interne ...

je repete la seule solution est que vous detectez si c'est le proxy qui attaque piwigo et changer HOST/PORT dans ce cas la seulement ...

cmenness · 2012-09-28 19:45:48

Pour moi, la solution idéale est que l'application lise l'URL avec laquelle elle est accédée et lors de la ré-écriture d'URL à destination du navigateur, elle utilise le même serveur (et port). L'utilisation d'URL relative devrait même suffire. Je pense que la majeure partie des applications web fonctionne de cette manière.

Je pense que tous les autres écrans de PW fonctionnent déjà de cette manière. J'en veux pour preuve que nul-part dans l'application, j'ai paramétré l'URL externe et interne. Et ils fonctionnent tous (sauf la mise à jour de la miniature après génération). Donc pour moi, c'est un bug.

Ensuite, quant à modifier la fonction get_absolute_root_url, je ne pense pas en avoir les compétences. Si vous voulez me passer le code pour que je vous dise si cela corrige le problème, je veux bien essayer pour vous aider.

PS : Pour résoudre mon problème, est-il possible de retrouver la fonction de génération des miniatures qui existait en version 2.1.x ? C'est comme cela que je fonctionnais avant l'upgrade en 2.4.x.

Merci de votre aide.

rvelices · 2012-10-01 12:02:13

cmenness a écrit:
Pour moi, la solution idéale est que l'application lise l'URL avec laquelle elle est accédée et lors de la ré-écriture d'URL à destination du navigateur, elle utilise le même serveur (et port). L'utilisation d'URL relative devrait même suffire. Je pense que la majeure partie des applications web fonctionne de cette manière.

c'est bien de cette maniere que piwigo fonctionne

cmenness a écrit:
Je pense que tous les autres écrans de PW fonctionnent déjà de cette manière. J'en veux pour preuve que nul-part dans l'application, j'ai paramétré l'URL externe et interne. Et ils fonctionnent tous (sauf la mise à jour de la miniature après génération). Donc pour moi, c'est un bug.

je persiste a dire que vous n'avez pas vu tous les problemes (par exemple emails envoyes par piwigo, flux rss ou services web ...)

cmenness a écrit:
Ensuite, quant à modifier la fonction get_absolute_root_url, je ne pense pas en avoir les compétences. Si vous voulez me passer le code pour que je vous dise si cela corrige le problème, je veux bien essayer pour vous aider.

Un lien "externe" vers ton site stp ?

lildadou · 2012-10-21 19:25:47

Bonjour,
je me permet de taper l'incruste car j'utilise Piwigo derrière un reverse-proxy nginx qui attaque le cluster PHP sur un descripteur de socket (meilleures perfs). J'ai pas eu de manip particulières à réaliser excepté sur la gestion des permissions. Essayez de vérifier ce point.

Voici ma config nginx:

Code:

        ###### Piwigo ######
        ### Astuce pour utiliser le cache du navigateur
        location ~* ^/piwigo/.+\.(avi|mpg|mp4|swf|jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|js)$ {
                rewrite                 ^(/piwigo/.*)$  $1      break;
                expires                 max;
        }

        ### Proxy pour les pages PHP
        ### /!\ Socket Piwigo
        location ~* ^/piwigo/.+\.php$ {
                include fastcgi_params;

                # Assuming php-fpm is running on a local socket
                fastcgi_pass unix:/tmp/php-piwigo.sock;
                fastcgi_param           SCRIPT_FILENAME         $document_root$fastcgi_script_name;
                fastcgi_param           SCRIPT_NAME             $fastcgi_script_name;

                fastcgi_connect_timeout 3;
                fastcgi_send_timeout 7;
                fastcgi_read_timeout 86400;
                fastcgi_buffer_size 32k;
                fastcgi_buffers 64 32k;
                fastcgi_busy_buffers_size 256k;
                fastcgi_temp_file_write_size 256k;
                fastcgi_intercept_errors on;
        }

billporte · 2012-10-27 20:29:35

Bonjour lildadou,

Je me permets de rebondire sur c e message, car j'utilise également nginx pour un accès sur mon nas, malheureusement j'ai eu beau traumatiser nginx et piwigo, je n'arrive pas à m'authentifier une fois que je tente de m'authentifier sur mon nas à partir d'internet.

Si cela ne te dérange pas peux-tu zieuter un petit coup cette conf nginx et me dire si quelque chose te chatouille ????

server {
auth_basic "Restricted";
auth_basic_user_file htpasswd-tous;
listen 443;
server_name truc.homedns.org;
location / {
proxy_pass http://etrayz:8000/piwigo/;
proxy_redirect off;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
location /piwigo/ {
proxy_pass http://etrayz:8000/piwigo/;
proxy_redirect off;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}

En parallèle, pour l'instant dans la conf piwigo, le site est paramétré sur $conf['gallery_url']=http://etrayz:80000/piwigo

Je n 'ai pas trouvé de solution pour faire un message privé, mais je pense que dans tous les cas, d'autres pourrait être intéressé

Merci de ton temps passé.

Gotcha · 2012-10-27 20:31:06

billporte a écrit:
Je n 'ai pas trouvé de solution pour faire un message privé, mais je pense que dans tous les cas, d'autres pourrait être intéressés.

Tout à fait, même si perso je ne comprend pas le moindre mot de ce jargon :-D

loutremaline · 2019-06-20 14:23:53

Bonjour,

Je confirme le constat de cmenness qui date de 2012 et qui n'est pas résolu en 2019 (Piwigo 2.9.5).

Avec un reverse proxy, la génération à la volée des miniatures fonctionne mal : Piwigo lance la création de la miniature (via Ajax) mais quand celle-ci est prête, l'URL pour la récupérer n'est pas la bonne. Le script Ajax utilise l'adresse locale derrière le reverse proxy et non l'adresse publique.

Il s'agit bien d'un bug Piwigo qui ne gère qu'à moitié le cas d'utilisation d'un reverse proxy.

En effet, on peut paramétrer le reverse proxy pour indiquer à Piwigo que l'URL a été "traduite". Au niveau du nom de domaine, mais aussi du port ou du protocole, avec l'ajout des entêtes HTTP X-Forwarded-Host, X-Forwarded-Port, X-Forwarded-Proto.

Malheureusement le code de Piwigo ne gère que l'entête X-Forwarded-Host, ignorant l'indication de traduction de HTTPS vers HTTP et provoquant la création d'une mauvaise URL pour accéder à la miniature.

Pourtant une correction à déjà été partagée à ce sujet en 2016 : https://piwigo.org/forum/viewtopic.php?id=25782 .

Peut-on espérer une correction prochaine qui permettrait d'utiliser Piwigo selon des configurations classiques de sécurisation de SI ?

Pour ma part j'ai effectué un ajout dans la fonction get_absolute_root_url en ajoutant les lignes suivantes, mais je perdrais tout à la prochaine mise à jour... :

if (isset($_SERVER['HTTPS']) &&
((strtolower($_SERVER['HTTPS']) == 'on') or ($_SERVER['HTTPS'] == 1)))
{
$is_https = true;
$url .= 'https://';
}
+ else if (isset($_SERVER['HTTP_X_FORWARDED_PROTO'])
+ && (strtolower($_SERVER['HTTP_X_FORWARDED_PROTO']) == 'https'))
+ {
+ $is_https = true;
+ $url .= 'https://';
+ }
else
{
$url .= 'http://';
}

Cordialement.

Piwigo.org

Annonce

#1 2012-09-27 11:49:36

Derrière un reverse proxy : mauvaise gestion d'URL

#2 2012-09-27 12:06:08

Re: Derrière un reverse proxy : mauvaise gestion d'URL

#3 2012-09-27 12:32:49

Re: Derrière un reverse proxy : mauvaise gestion d'URL

#4 2012-09-27 13:34:03

Re: Derrière un reverse proxy : mauvaise gestion d'URL

#5 2012-09-27 14:29:20

Re: Derrière un reverse proxy : mauvaise gestion d'URL

#6 2012-09-27 14:50:19

Re: Derrière un reverse proxy : mauvaise gestion d'URL

#7 2012-09-27 17:17:44

Re: Derrière un reverse proxy : mauvaise gestion d'URL

#8 2012-09-28 09:41:16

Re: Derrière un reverse proxy : mauvaise gestion d'URL

cmenness a écrit:

#9 2012-09-28 10:25:54

Re: Derrière un reverse proxy : mauvaise gestion d'URL

cmenness a écrit:

#10 2012-09-28 19:45:48

Re: Derrière un reverse proxy : mauvaise gestion d'URL

#11 2012-10-01 12:02:13

Re: Derrière un reverse proxy : mauvaise gestion d'URL

cmenness a écrit:

cmenness a écrit:

cmenness a écrit:

#12 2012-10-21 19:25:47

Re: Derrière un reverse proxy : mauvaise gestion d'URL

Code:

#13 2012-10-27 20:29:35

Re: Derrière un reverse proxy : mauvaise gestion d'URL

#14 2012-10-27 20:31:06

Re: Derrière un reverse proxy : mauvaise gestion d'URL

billporte a écrit:

#15 2019-06-20 14:23:53

Re: Derrière un reverse proxy : mauvaise gestion d'URL

Pied de page des forums