Je recherche un hébèrgeur (éventuellement mutualisé) qui offre toutes les
fonctions et modules existants. Je pense entre autres à register_globals...
La solution d'un serveur dédié sera étudiée en dernier recours parce que
c'est coûteux.
et facilement automatisable dans l'interface d'admin pour un hebergeur "digne de ce nom" !
Spyou, sors de ce corps.
J'ai pas compris là par contre. Tu peux m'expliquer ? Tu crois que je suis Spyou ? Si c'est le cas tu te trompe.
Thomas
Stephane Kanschine
On Fri, 21 Oct 2005 15:13:06 +0200, GPLHost wrote:
Tu penses à combien de vhosts en disant cela ? A quelques 1000 ou 10000, mais bon, mettre 10000 sites sur une seule
machine, c'est beaucoup quand meme non ?
Vi, sur un cluster avec des configurations dynamiques, paramétrer un php.ini ou ini_set() à la volée, c'est plus sport.
Mon avis est que c'est totalement inutile dans le cadre de scripts web. C'est totalement indispensable lorsque tu souhaite utiliser certaines
applications PHP qui ne fonctionnent que comme ça, et où tu n'as pas le choix.
Certes, mais même dans OsCommerce, ils ont pas du comprendre que ça allait être utilisé en environnement mutualisé et qu'il pouvaient faire bien mieux autrement.
-- Stephane Kanschine
On Fri, 21 Oct 2005 15:13:06 +0200, GPLHost wrote:
Tu penses à combien de vhosts en disant cela ?
A quelques 1000 ou 10000, mais bon, mettre 10000 sites sur une seule
machine, c'est beaucoup quand meme non ?
Vi, sur un cluster avec des configurations dynamiques, paramétrer un
php.ini ou ini_set() à la volée, c'est plus sport.
Mon avis est que c'est totalement inutile dans le cadre de scripts web.
C'est totalement indispensable lorsque tu souhaite utiliser certaines
applications PHP qui ne fonctionnent que comme ça, et où tu n'as pas
le choix.
Certes, mais même dans OsCommerce, ils ont pas du comprendre que ça
allait être utilisé en environnement mutualisé et qu'il pouvaient faire
bien mieux autrement.
On Fri, 21 Oct 2005 15:13:06 +0200, GPLHost wrote:
Tu penses à combien de vhosts en disant cela ? A quelques 1000 ou 10000, mais bon, mettre 10000 sites sur une seule
machine, c'est beaucoup quand meme non ?
Vi, sur un cluster avec des configurations dynamiques, paramétrer un php.ini ou ini_set() à la volée, c'est plus sport.
Mon avis est que c'est totalement inutile dans le cadre de scripts web. C'est totalement indispensable lorsque tu souhaite utiliser certaines
applications PHP qui ne fonctionnent que comme ça, et où tu n'as pas le choix.
Certes, mais même dans OsCommerce, ils ont pas du comprendre que ça allait être utilisé en environnement mutualisé et qu'il pouvaient faire bien mieux autrement.
-- Stephane Kanschine
Eric Demeester
dans (in) fr.reseaux.internet.hebergement, GPLHost ecrivait (wrote) :
Bonsoir Thomas,
Un hébergeur "digne de ce nom" connait les applications hébergé par ses utilisateur.
Certes.
Un hébergeur "digne de ce nom" à des clients qui utilise (par exemple) OSCommerce, qui a besoin du register global.
Pourquoi pas, mais dans ce cas, l'hébergeur responsable et soucieux de sa qualité de service ne proposera le register_globals On qu'aux clients qui le demandent, et _uniquement_ en hébergement dédié, parce que l'autoriser en mutualisé constituerait une faille de sécurité de classe Tsunami :)
Un hébergeur "digne de ce nom", vu que certaines apps php en on besoin, laissera la possibilité à ses clients de choisir individuellement pour chaque vhost, d'activer register_global ou non.
Si c'est en hébergement mutualisé, encore une fois, non. Un hébergeur digne de ce nom se doit avant tout d'assurer une qualité de service irréprochable à _tous_ ses clients, ce qui implique de fait des restrictions parfois désagréables en environnement mutualisé, mais c'est à ce prix que le service fourni est fiable...
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, GPLHost
<nospam@nospam.gplhost.com> ecrivait (wrote) :
Bonsoir Thomas,
Un hébergeur "digne de ce nom" connait les applications hébergé par ses
utilisateur.
Certes.
Un hébergeur "digne de ce nom" à des clients qui utilise (par exemple)
OSCommerce, qui a besoin du register global.
Pourquoi pas, mais dans ce cas, l'hébergeur responsable et soucieux de
sa qualité de service ne proposera le register_globals On qu'aux clients
qui le demandent, et _uniquement_ en hébergement dédié, parce que
l'autoriser en mutualisé constituerait une faille de sécurité de classe
Tsunami :)
Un hébergeur "digne de ce nom", vu que certaines apps php en on besoin,
laissera la possibilité à ses clients de choisir individuellement pour
chaque vhost, d'activer register_global ou non.
Si c'est en hébergement mutualisé, encore une fois, non. Un hébergeur
digne de ce nom se doit avant tout d'assurer une qualité de service
irréprochable à _tous_ ses clients, ce qui implique de fait des
restrictions parfois désagréables en environnement mutualisé, mais c'est
à ce prix que le service fourni est fiable...
dans (in) fr.reseaux.internet.hebergement, GPLHost ecrivait (wrote) :
Bonsoir Thomas,
Un hébergeur "digne de ce nom" connait les applications hébergé par ses utilisateur.
Certes.
Un hébergeur "digne de ce nom" à des clients qui utilise (par exemple) OSCommerce, qui a besoin du register global.
Pourquoi pas, mais dans ce cas, l'hébergeur responsable et soucieux de sa qualité de service ne proposera le register_globals On qu'aux clients qui le demandent, et _uniquement_ en hébergement dédié, parce que l'autoriser en mutualisé constituerait une faille de sécurité de classe Tsunami :)
Un hébergeur "digne de ce nom", vu que certaines apps php en on besoin, laissera la possibilité à ses clients de choisir individuellement pour chaque vhost, d'activer register_global ou non.
Si c'est en hébergement mutualisé, encore une fois, non. Un hébergeur digne de ce nom se doit avant tout d'assurer une qualité de service irréprochable à _tous_ ses clients, ce qui implique de fait des restrictions parfois désagréables en environnement mutualisé, mais c'est à ce prix que le service fourni est fiable...
-- Eric Demeester - http://www.galacsys.net
Eric Demeester
dans (in) fr.reseaux.internet.hebergement, GPLHost ecrivait (wrote) :
Bonsoir,
[autoriser register_globals à ON en PHP]
C'est totalement indispensable lorsque tu souhaite utiliser certaines applications PHP qui ne fonctionnent que comme ça, et où tu n'as pas le choix.
C'est totalement irresponsable de l'autoriser au prétexte que des scripts écrits avec les pieds en ont besoin pour fonctionner.
Reprenons : autoriser register_globals à ON est une faille de sécurité d'anthologie (fais une recherche sur Google et lis les réponses si tu n'es pas convaincu), c'est d'ailleurs la raison pour laquelle ce n'est plus la configuration par défaut en php4.
-- Eric Demeester - http://www.galacsys.net
dans (in) fr.reseaux.internet.hebergement, GPLHost
<nospam@nospam.gplhost.com> ecrivait (wrote) :
Bonsoir,
[autoriser register_globals à ON en PHP]
C'est totalement indispensable lorsque tu souhaite utiliser certaines
applications PHP qui ne fonctionnent que comme ça, et où tu n'as pas le
choix.
C'est totalement irresponsable de l'autoriser au prétexte que des
scripts écrits avec les pieds en ont besoin pour fonctionner.
Reprenons : autoriser register_globals à ON est une faille de sécurité
d'anthologie (fais une recherche sur Google et lis les réponses si tu
n'es pas convaincu), c'est d'ailleurs la raison pour laquelle ce n'est
plus la configuration par défaut en php4.
dans (in) fr.reseaux.internet.hebergement, GPLHost ecrivait (wrote) :
Bonsoir,
[autoriser register_globals à ON en PHP]
C'est totalement indispensable lorsque tu souhaite utiliser certaines applications PHP qui ne fonctionnent que comme ça, et où tu n'as pas le choix.
C'est totalement irresponsable de l'autoriser au prétexte que des scripts écrits avec les pieds en ont besoin pour fonctionner.
Reprenons : autoriser register_globals à ON est une faille de sécurité d'anthologie (fais une recherche sur Google et lis les réponses si tu n'es pas convaincu), c'est d'ailleurs la raison pour laquelle ce n'est plus la configuration par défaut en php4.
-- Eric Demeester - http://www.galacsys.net
Spyou
et facilement automatisable dans l'interface d'admin pour un hebergeur "digne de ce nom" !
Spyou, sors de ce corps.
Nan eh, j'ai arreté de posseder l'esprit des gens le jour ou j'ai arreter les jeux de role
PS : notre interface d'admin mutu est une mouise, malgré le fait que beaucoup de gens nous qualifient d'hebergeur "digne de ce nom"
et facilement automatisable dans l'interface d'admin pour un hebergeur
"digne de ce nom" !
Spyou, sors de ce corps.
Nan eh, j'ai arreté de posseder l'esprit des gens le jour ou j'ai
arreter les jeux de role
PS : notre interface d'admin mutu est une mouise, malgré le fait que
beaucoup de gens nous qualifient d'hebergeur "digne de ce nom"
et facilement automatisable dans l'interface d'admin pour un hebergeur "digne de ce nom" !
Spyou, sors de ce corps.
Nan eh, j'ai arreté de posseder l'esprit des gens le jour ou j'ai arreter les jeux de role
PS : notre interface d'admin mutu est une mouise, malgré le fait que beaucoup de gens nous qualifient d'hebergeur "digne de ce nom"
GPLHost
Eric Demeester wrote:
C'est totalement irresponsable de l'autoriser au prétexte que des scripts écrits avec les pieds en ont besoin pour fonctionner.
Je ne suis pas responsable des choix de mes clients. Mon role, c'est de leur faciliter la vie, pas de leur mettre des battons dans les roues, meme si les choix sont mauvais. Au passage, trouve-moi un équivalent a OSCommerce qui n'utilise pas register global et on en reparle !!!
Reprenons : autoriser register_globals à ON est une faille de sécurité d'anthologie (fais une recherche sur Google et lis les réponses si tu n'es pas convaincu), c'est d'ailleurs la raison pour laquelle ce n'est plus la configuration par défaut en php4.
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité, c'est juste qu'il est très facile d'oublier des cas.
Il faut arreter de dire n'importe quoi, j'ai l'impression que tu n'as jamais écrit de script php pour poster un truc comme ça...
Thomas
Eric Demeester wrote:
C'est totalement irresponsable de l'autoriser au prétexte que des
scripts écrits avec les pieds en ont besoin pour fonctionner.
Je ne suis pas responsable des choix de mes clients. Mon role, c'est de
leur faciliter la vie, pas de leur mettre des battons dans les roues,
meme si les choix sont mauvais. Au passage, trouve-moi un équivalent a
OSCommerce qui n'utilise pas register global et on en reparle !!!
Reprenons : autoriser register_globals à ON est une faille de sécurité
d'anthologie (fais une recherche sur Google et lis les réponses si tu
n'es pas convaincu), c'est d'ailleurs la raison pour laquelle ce n'est
plus la configuration par défaut en php4.
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise
habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou
des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité,
c'est juste qu'il est très facile d'oublier des cas.
Il faut arreter de dire n'importe quoi, j'ai l'impression que tu n'as
jamais écrit de script php pour poster un truc comme ça...
C'est totalement irresponsable de l'autoriser au prétexte que des scripts écrits avec les pieds en ont besoin pour fonctionner.
Je ne suis pas responsable des choix de mes clients. Mon role, c'est de leur faciliter la vie, pas de leur mettre des battons dans les roues, meme si les choix sont mauvais. Au passage, trouve-moi un équivalent a OSCommerce qui n'utilise pas register global et on en reparle !!!
Reprenons : autoriser register_globals à ON est une faille de sécurité d'anthologie (fais une recherche sur Google et lis les réponses si tu n'es pas convaincu), c'est d'ailleurs la raison pour laquelle ce n'est plus la configuration par défaut en php4.
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité, c'est juste qu'il est très facile d'oublier des cas.
Il faut arreter de dire n'importe quoi, j'ai l'impression que tu n'as jamais écrit de script php pour poster un truc comme ça...
Thomas
GPLHost
Eric Demeester wrote:
Pourquoi pas, mais dans ce cas, l'hébergeur responsable et soucieux de sa qualité de service ne proposera le register_globals On qu'aux clients qui le demandent
Oui, c'est ce que je fais
et _uniquement_ en hébergement dédié,
Non, beaucoup de clients demande ça en mutualisé aussi
parce que l'autoriser en mutualisé constituerait une faille de sécurité de classe Tsunami :)
NON ! Ce n'est PAS une faille de sécurité. C'est juste une mauvaise habitude de programmation qui PEUT mener à des problèmes, mais en soit cela remet en cause le script qui a besoin de register_global a on, mais ça ne remet pas en cause la sécurité du serveur lui-meme si tout est bien configuré.
Si c'est en hébergement mutualisé, encore une fois, non. Un hébergeur digne de ce nom se doit avant tout d'assurer une qualité de service irréprochable à _tous_ ses clients, ce qui implique de fait des restrictions parfois désagréables en environnement mutualisé, mais c'est à ce prix que le service fourni est fiable...
Entièrement d'accord, mais ça n'inclus pas le register_global qui peut et doit etre configurable (ce qui ne remet PAS en cause la sécurité global du service, mais juste la qualité du script qui a besoin de cette option, (j'insiste lourdement...)).
Thomas
Eric Demeester wrote:
Pourquoi pas, mais dans ce cas, l'hébergeur responsable et soucieux de
sa qualité de service ne proposera le register_globals On qu'aux clients
qui le demandent
Oui, c'est ce que je fais
et _uniquement_ en hébergement dédié,
Non, beaucoup de clients demande ça en mutualisé aussi
parce que
l'autoriser en mutualisé constituerait une faille de sécurité de classe
Tsunami :)
NON ! Ce n'est PAS une faille de sécurité. C'est juste une mauvaise
habitude de programmation qui PEUT mener à des problèmes, mais en soit
cela remet en cause le script qui a besoin de register_global a on, mais
ça ne remet pas en cause la sécurité du serveur lui-meme si tout est
bien configuré.
Si c'est en hébergement mutualisé, encore une fois, non. Un hébergeur
digne de ce nom se doit avant tout d'assurer une qualité de service
irréprochable à _tous_ ses clients, ce qui implique de fait des
restrictions parfois désagréables en environnement mutualisé, mais c'est
à ce prix que le service fourni est fiable...
Entièrement d'accord, mais ça n'inclus pas le register_global qui peut
et doit etre configurable (ce qui ne remet PAS en cause la sécurité
global du service, mais juste la qualité du script qui a besoin de cette
option, (j'insiste lourdement...)).
Pourquoi pas, mais dans ce cas, l'hébergeur responsable et soucieux de sa qualité de service ne proposera le register_globals On qu'aux clients qui le demandent
Oui, c'est ce que je fais
et _uniquement_ en hébergement dédié,
Non, beaucoup de clients demande ça en mutualisé aussi
parce que l'autoriser en mutualisé constituerait une faille de sécurité de classe Tsunami :)
NON ! Ce n'est PAS une faille de sécurité. C'est juste une mauvaise habitude de programmation qui PEUT mener à des problèmes, mais en soit cela remet en cause le script qui a besoin de register_global a on, mais ça ne remet pas en cause la sécurité du serveur lui-meme si tout est bien configuré.
Si c'est en hébergement mutualisé, encore une fois, non. Un hébergeur digne de ce nom se doit avant tout d'assurer une qualité de service irréprochable à _tous_ ses clients, ce qui implique de fait des restrictions parfois désagréables en environnement mutualisé, mais c'est à ce prix que le service fourni est fiable...
Entièrement d'accord, mais ça n'inclus pas le register_global qui peut et doit etre configurable (ce qui ne remet PAS en cause la sécurité global du service, mais juste la qualité du script qui a besoin de cette option, (j'insiste lourdement...)).
Thomas
FightClub!
Eric Demeester wrote:
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité, c'est juste qu'il est très facile d'oublier des cas.
Il faut arreter de dire n'importe quoi, j'ai l'impression que tu n'as jamais écrit de script php pour poster un truc comme ça...
Tout à fait, d'ailleurs il faut 3 lignes(*) de PHP en début d'un script pour simuler le register global à On quand il est à Off (on a alors exactement les mêmes effets pervers que si il était réellement à On) => donc à mon avis l'hébergeur qui ne veut pas le passer à On ne fait qu'emm..der ses propres clients
Et il s'agit bien d'"effet pervers" et non de "faille", une faille est un trou de sécurité systématique, et il beaucoup plus dangereux de laisser un client installer un logiciel qui a une faille que de passer le register_globals à On, nous en avons fait les frais le jour du nouvel an 2005 après qu'un client aie installé un phpBB (j'ai du me contenter d'un minute-maid à l'orange pendant que le reste du monde faisait la fete... pour sauver le serveur !)
Bref, AMHA il vaut mieux investir dans les explications de ces effets pervers aux clients, et comment les éviter, plutot que de mécontenter les clients. Si cette options avait été une "faille de sécurité" comme certains l'avance, le staff PHP l'aurait enlevée, le passé montre qu'ils n'ont pas peur de casser BC quand c'est nécessaire (exemple récemment, un code qui fonctionne en PHP4 provoquera une erreur fatale en PHP5 : voir dans la base des bugs PHP les commentaire de Rasmus dans le #33643 et l'explication dans le #33516)
(*) il me parait évident que l'hébergeur qui bloque le register_globals à Off va aussi bloquer les ini_set et la modif du vhost, donc je parle de trois lignes qui transferent le contenu de _GET/_POST/etc. dans HTTP_*_VARS, par exemple avec la fonction extract, chose que l'hébergeur ne peut pas empecher, à moins de sa taper à la paluche tous les scripts de ses clients
JJ.
Eric Demeester wrote:
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise
habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou
des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité,
c'est juste qu'il est très facile d'oublier des cas.
Il faut arreter de dire n'importe quoi, j'ai l'impression que tu n'as
jamais écrit de script php pour poster un truc comme ça...
Tout à fait, d'ailleurs il faut 3 lignes(*) de PHP en début d'un script
pour simuler le register global à On quand il est à Off (on a alors
exactement les mêmes effets pervers que si il était réellement à On)
=> donc à mon avis l'hébergeur qui ne veut pas le passer à On ne fait
qu'emm..der ses propres clients
Et il s'agit bien d'"effet pervers" et non de "faille", une faille est
un trou de sécurité systématique, et il beaucoup plus dangereux de
laisser un client installer un logiciel qui a une faille que de passer
le register_globals à On, nous en avons fait les frais le jour du nouvel
an 2005 après qu'un client aie installé un phpBB (j'ai du me contenter
d'un minute-maid à l'orange pendant que le reste du monde faisait la
fete... pour sauver le serveur !)
Bref, AMHA il vaut mieux investir dans les explications de ces effets
pervers aux clients, et comment les éviter, plutot que de mécontenter
les clients. Si cette options avait été une "faille de sécurité" comme
certains l'avance, le staff PHP l'aurait enlevée, le passé montre qu'ils
n'ont pas peur de casser BC quand c'est nécessaire (exemple récemment,
un code qui fonctionne en PHP4 provoquera une erreur fatale en PHP5 :
voir dans la base des bugs PHP les commentaire de Rasmus dans le #33643
et l'explication dans le #33516)
(*) il me parait évident que l'hébergeur qui bloque le register_globals
à Off va aussi bloquer les ini_set et la modif du vhost, donc je parle
de trois lignes qui transferent le contenu de _GET/_POST/etc. dans
HTTP_*_VARS, par exemple avec la fonction extract, chose que l'hébergeur
ne peut pas empecher, à moins de sa taper à la paluche tous les scripts
de ses clients
Alors là, tu vas trop loin. register_global est peut-etre une mauvaise habitude, ou quelque chose QUI PEUT provoquer des erreurs, des bugs ou des trous de sécu. Mais en soit CE N'EST PAS une faille de sécurité, c'est juste qu'il est très facile d'oublier des cas.
Il faut arreter de dire n'importe quoi, j'ai l'impression que tu n'as jamais écrit de script php pour poster un truc comme ça...
Tout à fait, d'ailleurs il faut 3 lignes(*) de PHP en début d'un script pour simuler le register global à On quand il est à Off (on a alors exactement les mêmes effets pervers que si il était réellement à On) => donc à mon avis l'hébergeur qui ne veut pas le passer à On ne fait qu'emm..der ses propres clients
Et il s'agit bien d'"effet pervers" et non de "faille", une faille est un trou de sécurité systématique, et il beaucoup plus dangereux de laisser un client installer un logiciel qui a une faille que de passer le register_globals à On, nous en avons fait les frais le jour du nouvel an 2005 après qu'un client aie installé un phpBB (j'ai du me contenter d'un minute-maid à l'orange pendant que le reste du monde faisait la fete... pour sauver le serveur !)
Bref, AMHA il vaut mieux investir dans les explications de ces effets pervers aux clients, et comment les éviter, plutot que de mécontenter les clients. Si cette options avait été une "faille de sécurité" comme certains l'avance, le staff PHP l'aurait enlevée, le passé montre qu'ils n'ont pas peur de casser BC quand c'est nécessaire (exemple récemment, un code qui fonctionne en PHP4 provoquera une erreur fatale en PHP5 : voir dans la base des bugs PHP les commentaire de Rasmus dans le #33643 et l'explication dans le #33516)
(*) il me parait évident que l'hébergeur qui bloque le register_globals à Off va aussi bloquer les ini_set et la modif du vhost, donc je parle de trois lignes qui transferent le contenu de _GET/_POST/etc. dans HTTP_*_VARS, par exemple avec la fonction extract, chose que l'hébergeur ne peut pas empecher, à moins de sa taper à la paluche tous les scripts de ses clients
