Piwigo.org

jed · 2008-11-30 09:15:30

Bonjour,
J'utilise depuis plusieurs années PWG 1.4 sur mon site (www.sportmeca.com) or je change d'hébergeur (sfr.fr) et je n'arrive pas à faire fonctionner PWG. En effet après installation, lorsque je rentre sur la page d'itentification, j'obtiens en retour le message suivant :
"Fatal error: SUHOSIN - Use of preg_replace() with /e modifier is forbidden by configuration in /var/www/j/je/je./je.descombes.perso.sfr.fr/public_html/phpwebgal/include/template.php(458) : regexp code on line 458"
Et là je ne sais plus quoi faire. Apparemment il s'agit d'un problème de sécurité...
Que puis-je faire ?
Merci d'avance pour votre aide.
Cdlt
jed

ddtddt · 2008-11-30 09:41:54

Peut être en profiter pour migrer cela te permettra de profiter de toutes les dernière nouveauté notamment des plugins :)

jed · 2008-11-30 10:28:02

Mais c'est bien ce que j'ai fait. J'ai installé la version 1.7.3... et c'est pareil.
Par contre s'il y a un plug-in qui évite ce problème, je suis preneur.
Merci

ddtddt · 2008-11-30 10:32:32

jed a écrit:
Mais c'est bien ce que j'ai fait. J'ai installé la version 1.7.3... et c'est pareil.
Par contre s'il y a un plug-in qui évite ce problème, je suis preneur.
Merci

As tu fait une migration de la 1.4 ou est ce avec une installation "propre" que tu as également ce problème ?

Peut tu mettres un liens en direction de la galerie qui pose le problème ?

[edit] est ce que tu as supprimé dans le répertoirelanguage, le répertoire en_UK.iso-8859-1 [/edit]

P@t · 2008-11-30 11:24:03

Bizarre de bloquer l'option preg_replace_eval...
Tu devrais contacter ton hébergeur et leur demander s'il est possible de réactiver ca.

Pour le moment, il n'y a pas grand chose à faire puisque le moteur de template utilisé en 1.7.3 utilise ceci tout le temps.
Par contre, je ne pense pas qu'il y ait de soucis avec la future 2.0.0... pourrais-tu tester la 2.0.0RC4 et nous dire si c'est ok?

EDIT: A ta place, je fuirais cet herbégeur. Voila ce que j'ai pu trouver sur le net:
Fonctions interdites chez leneuf/sfr
get_current_user / php_uname / putenv / set_time_limit / getmyuid / getmypid / dl / ini_alter / ini_restore / ini_set / exec / passthru / system / popen / pclose / leak / mysql_list_dbs / listen / sk_total_space / disk_free_space / realpath / tmpfile / link / shell_exec / proc_open / chroot / openlog / closelog / syslog / flock / socket_create_listen / socket_accept / socket_listen / sleep / usleep / set_include_path / restore_include_path / symlink / imagerotate / phpinfo / mail / posix_getpwuid / posix_kill /

A leur place, je laisserai juste la fonction echo pour etre tranquille!

Dernière modification par P@t (2008-11-30 11:29:34)

jed · 2008-11-30 12:20:50

ddtddt a écrit:
jed a écrit:
Mais c'est bien ce que j'ai fait. J'ai installé la version 1.7.3... et c'est pareil.
Par contre s'il y a un plug-in qui évite ce problème, je suis preneur.
Merci
As tu fait une migration de la 1.4 ou est ce avec une installation "propre" que tu as également ce problème ?

Peut tu mettres un liens en direction de la galerie qui pose le problème ?

[edit] est ce que tu as supprimé dans le répertoirelanguage, le répertoire en_UK.iso-8859-1 [/edit]

J'ai fait les 2 avec le même résultat.
le lien : http://je.descombes.perso.sfr.fr/phpweb … cation.php
Je vais essayer la 2.0RC4 pour voir
merci

jed · 2008-11-30 13:01:54

P@t a écrit:
Bizarre de bloquer l'option preg_replace_eval...
Tu devrais contacter ton hébergeur et leur demander s'il est possible de réactiver ca.

Pour le moment, il n'y a pas grand chose à faire puisque le moteur de template utilisé en 1.7.3 utilise ceci tout le temps.
Par contre, je ne pense pas qu'il y ait de soucis avec la future 2.0.0... pourrais-tu tester la 2.0.0RC4 et nous dire si c'est ok?

EDIT: A ta place, je fuirais cet herbégeur. Voila ce que j'ai pu trouver sur le net:
Fonctions interdites chez leneuf/sfr
get_current_user / php_uname / putenv / set_time_limit / getmyuid / getmypid / dl / ini_alter / ini_restore / ini_set / exec / passthru / system / popen / pclose / leak / mysql_list_dbs / listen / sk_total_space / disk_free_space / realpath / tmpfile / link / shell_exec / proc_open / chroot / openlog / closelog / syslog / flock / socket_create_listen / socket_accept / socket_listen / sleep / usleep / set_include_path / restore_include_path / symlink / imagerotate / phpinfo / mail / posix_getpwuid / posix_kill /

A leur place, je laisserai juste la fonction echo pour etre tranquille!

Je viens d'essayer et j'ai le problème dès l'installation.
Je suis vraiment coincé et je n'imagine pas SFR modifier ses consignes de sécurité pour moi !!!

jed · 2008-11-30 14:12:44

ddtddt a écrit:
[edit] est ce que tu as supprimé dans le répertoirelanguage, le répertoire en_UK.iso-8859-1 [/edit]

Non, l'arborescence de pwb est d'origine. J'ai copier le répertoire complet sur le site et fait l'install... et ça plante :-((

P@t · 2008-11-30 14:59:43

jed a écrit:
Non, l'arborescence de pwb est d'origine. J'ai copier le répertoire complet sur le site et fait l'install... et ça plante :-((

Ne cherche pas... PWG 1.7 ne peut pas fonctionner chez sfr.
Il ne te reste plus qu'à essayer la 2.0.0RC4 (mais il y a des chances que ce ne soit pas bon non plus vu le nombre de fonctions désactivées)
Une autre (très bonne) solution serait de changer d'hébergeur, car on ne peut pas faire grand chose avec un hébergeur qui bride aurant... (à part du bon vieux HTML!)

jed · 2008-11-30 15:08:25

P@t a écrit:
jed a écrit:
Non, l'arborescence de pwb est d'origine. J'ai copier le répertoire complet sur le site et fait l'install... et ça plante :-((
Ne cherche pas... PWG 1.7 ne peut pas fonctionner chez sfr.
Il ne te reste plus qu'à essayer la 2.0.0RC4 (mais il y a des chances que ce ne soit pas bon non plus vu le nombre de fonctions désactivées)
Une autre (très bonne) solution serait de changer d'hébergeur, car on ne peut pas faire grand chose avec un hébergeur qui bride aurant... (à part du bon vieux HTML!)

Le problème est que j'étais chez Club-internet avant et suite au rapprochement avec Neuf et ensuite SFR, j'ai "glissé" vers ce dernier. Cher Club il n'y avait pas de pb. Je me vois mal changer de fournisseur maintenant. A part ça le service est bon (pour le moment)
Par contre si je regarde la liste des fonction interdite (officiel sfr) :
* get_current_user
* php_uname
* putenv
* set_time_limit
* getmyuid
* getmypid
* dl
* ini_alter
* ini_restore
* ini_set
* exec
* passthru
* system
* popen
* pclose
* leak
* mysql_list_dbs
* listen
* disk_total_space
* disk_free_space
* realpath
* tmpfile
* link
* shell_exec
* proc_open
* chroot
* openlog
* closelog
* syslog
* flock
* socket_create_listen
* socket_accept
* socket_listen
* sleep
* usleep
* set_include_path
* restore_include_path
* symlink
* imagerotate
* phpinfo
* mail
* posix_getpwuid
* posix_kill
je n'y trouve pas preg_replace() et c'est ce qui m'inquiète...

P@t · 2008-11-30 15:36:44

Ce n'est pas la fonction preg_replace qui est bloquée, mais l'option PREG_REPLACE_EVAL (qui permet d'évaluer du code php par la fonction preg_replace).

Un hébergeur payant, ce n'est vraiment pas la ruine (compter environ 2euros/mois tout compris pour l'hébergement + un nom de domaine). Jette un oeil chez OVH ou 1and1...

jed · 2008-11-30 16:00:34

P@t a écrit:
Ce n'est pas la fonction preg_replace qui est bloquée, mais l'option PREG_REPLACE_EVAL (qui permet d'évaluer du code php par la fonction preg_replace).

Peut-être... mais elle n'est pas non listée.
En parallèle j'ai mis un mot sur le forum SFR, je vais bien voir leur réaction.

P@t a écrit:
Un hébergeur payant, ce n'est vraiment pas la ruine (compter environ 2euros/mois tout compris pour l'hébergement + un nom de domaine). Jette un oeil chez OVH ou 1and1...

Merci de l'info, je vais me renseigner.
;-)

Dernière modification par jed (2008-11-30 16:00:51)

ddtddt · 2008-11-30 16:07:27

P@t a écrit:
Un hébergeur payant, ce n'est vraiment pas la ruine (compter environ 2euros/mois tout compris pour l'hébergement + un nom de domaine). Jette un oeil chez OVH ou 1and1...

ou 1hebergement qui héberge gratuitement la demo de la prochaine version

P@t · 2008-11-30 16:38:09

Je sens que ca te tracasse...
Je me répète, PREG_REPLACE_EVAL (e) est une option de la fonction preg_replace, et n'est donc pas listée dans liste des fonctions interdites...
Pour plus d'infos, c'est ici

jed · 2008-11-30 16:56:41

P@t a écrit:
Je sens que ca te tracasse...
Je me répète, PREG_REPLACE_EVAL (e) est une option de la fonction preg_replace, et n'est donc pas listée dans liste des fonctions interdites...
Pour plus d'infos, c'est ici

En effet, j'avais bien compris cela comme ça.
Ce n'est pas listé, mais cela ne marche pas quand même. Je vais bien voir ce que SFR me répond. Mais je ne me fais guère d'illusion.
Je viens de regarder vers mon fournisseur de nom de domaine (amen.fr) et leurs offres d'hébergement semblent correctes. J'attends quelques jours et je verrai bien.
Merci

Piwigo.org

Annonce

#1 2008-11-30 09:15:30

Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

#2 2008-11-30 09:41:54

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

#3 2008-11-30 10:28:02

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

#4 2008-11-30 10:32:32

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

jed a écrit:

#5 2008-11-30 11:24:03

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

#6 2008-11-30 12:20:50

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

ddtddt a écrit:

jed a écrit:

#7 2008-11-30 13:01:54

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

P@t a écrit:

#8 2008-11-30 14:12:44

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

ddtddt a écrit:

#9 2008-11-30 14:59:43

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

jed a écrit:

#10 2008-11-30 15:08:25

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

P@t a écrit:

jed a écrit:

#11 2008-11-30 15:36:44

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

#12 2008-11-30 16:00:34

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

P@t a écrit:

P@t a écrit:

#13 2008-11-30 16:07:27

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

P@t a écrit:

#14 2008-11-30 16:38:09

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

#15 2008-11-30 16:56:41

Re: Utilisation de "preg_replace() /e" impossible sur nouvel hébergeur

P@t a écrit:

Pied de page des forums