Kioob

Non : en France la limite est moitié moindre de celle des USA, mais les clients français sont pris pour des pigeons et on met en avant ces "faux" 100Mbps. Je préfère l'indication utilisée sur la version US...

Hello, et quand tu dis "ça ne fonctionne pas", tu entends quoi par là ? Sinon comme on peut le voir avec un var_dump($_COOKIE), le soucis viens des simples quote qui sont de trop (lors du setcookie uniquement hein). Donc essayes plutôt : setcookie("General[Score]", $score);

Si je ne me trompe pas (ce qui reste possible), 2000Go par mois, ça correspond à 6Mbps en continue. Donc bien loin des 100Mbps qu'on peut trouver en France. Par contre le trafic US est peut-être garanti, lui. Sinon en France, plusieurs acteurs (OVH en tête) ont fortement contribué à l'effondrement des prix. Edit : bonne blague de 1and1 en fait, si tu regardes à quoi correspond les "**" à coté de la bande passante, tu peux lire :

Aïe oui... c'est toujours délicat de remettre en cause la sécurité d'une plateforme à cause d'un seul prestataire

Hello, le plus simple serait probablement de regarder dans les logs du serveur de mail afin de savoir si oui ou non il a reçu le mail, et ce qu'il en a fait. Entre les annonces EHLO bidons, les règles SPF incomplètes, les reverses DNS foireux, les listes grises avec 2 de tensions, et les filtres heuristiques évoqués par Wefficient, les causes peuvent être nombreuses avant même d'en arriver au test de blacklistage de l'IP émettrice. Mais depuis un mois tu as eu peut-être trouvé la cause du problème ?

Un blocage sur le referer, c'est une "sécurité" utilisée pour empêcher le "hot linking" comme je disais dans ma première phrase. J'ose espérer que si tu avais mis ce genre de choses en place tu t'en souviendrais. Mais je n'ai pas l'impression que ce soit le cas ici : cette page fonctionne parfaitement chez moi, même en mettant un referer complètement bidon. Juste un truc : c'est drapo1.php ou bien drapo01.php l'url de la page ?

Hello, tu n'aurais pas mis en place un filtre dans un .htaccess pour bloquer le "hot linking" / "téléchargement des images depuis les autres sites" ? Enfin, indiques l'URL complète mais là comme ça d'après ta description ça ressemble à un blocage sur le REFERER.

Hello, tu peux également modifier ton traitement afin qu'il gère correctement un timeout, et/ou qu'il gère plusieurs accès réseau simultanément. Mais comme indiqué par Prélude, en passant par la version "CLI" de PHP (via un cron par exemple) tu n'auras pas de soucis de time_limit.

Hello, via un sniffeur Wifi il peut effectivement être très simple de voler la session PHP... voir même les logins/pass que tu utilises pour les formulaires, pour les .htpasswd, pour te connecter en POP, en IMAP, ainsi qu'en FTP. S'il existe des versions cryptées de ces protocoles, c'est bien parce que la version "classique" n'est pas suffisante. Et il n'y a pas que le Wifi qui est exposé. La plupart des autres clients de ton hébergeur peuvent facilement "piquer" l'IP de ta machine de temps à autre afin de tracer tout ce qui passe. Bref. Pour l'espace d'administration, une connexion via SSL serait la bienvenue. Pour les comptes "normaux", selon l'importance des données un simple mécanisme de protection pour se prémunir du vol de session devrait suffire. Sans oublier de changer tes mots de passe, évidement. Pour la connexion Wifi de ton pote, vérifier qu'elle est cryptée en WPA et pas en WEP. Maintenant si le gars a eu l'occasion de choper tes pass FTP, perso j'effacerais et ré-uploaderais tout le site.

et pourquoi pas un simple basename() ?

Mon post étant passé à la trappe à priori : htmlspecialchars() n'y changera rien. C'est un paramètre d'URL ici, même saisi "à la main" dans la barre d'adresse ça ne passera pas. Il faut utiliser rawurlencode() pour encoder correctement ce &. Et pour les & qui sont valides (ceux qui séparent les vrais arguments de la requête) c'est effectivement htmlspecialchars() (et donc & qui doit être utilisé). Et comme l'a rappelé steph29, une erreur d'encodage de ce type vient certainement d'une erreur de construction coté script (JS à priori), étant donné que dans le cas d'un formulaire classique (même en GET) le navigateur fait déjà très bien son boulot.

Le seul problème ce sont les "injections XSS" : par exemple tu ajoutes sur ton site une image "cachée" avec une adresse du genre "http://gmail.com/addRewrite.php?type=all&email=pirate_AT_tipiac.fr". S'il n'y a pas de vérification et qu'un gars avec une session valide "gmail" passe sur ton site, le traitement sera lancé... Bref, de manière générale tout ce qui est "action" devrait être déclenché via POST, même si c'est parfois contraignant. Par contre pour le problème en question : les navigateurs encodent déjà correctement les données... Donc soit le formulaire est (mal) soumis en JS, soit il y a une étape qui m'échappe coté PHP. S'il y a vraiment une étape coté PHP, c'est à coup de rawurlencode() qu'il faut protéger tes variables.

S'il s'agit vraiment d'un "kernel panic" un moyen de limiter la casse est d'ajouter un panic=N coté bootloader afin d'indiquer au kernel de rebooter après N secondes. Mais s'il s'agit d'un kernel OVH, la probabilité que ça coince sur leur matos me semble faible. Là comme ça, s'il n'y a absolument aucune trace dans les logs j'aurais plutôt vu un problème hardware...

Hello, tu fais ton ls et ton tar à partir du dossier courant, donc la commande dépendra du dossier depuis lequel elle est lancée ; est-ce bien ce que tu cherches à faire ? Si ce n'est pas le cas, essaye de remplacer ton path=XXX par un simple cd XXX.

Pour moi le plus chiant n'est même pas les clés SSH, mais plutôt le reste : les certificats SSL d'Apache, Dovecot, Exim, PureFTPd, voir MySQL, ainsi que les clés DomainKeys à régénérer, redéployer, revérifier, etc. D'ailleurs, quand on a un joli certificat acheté, ssh-vulnkey fonctionne dessus ? Je n'ai même pas vérifié tiens.

Pourtant le problème est exactement là : à chaque fois que tu utilises $config_cheminabsolu pour un include, les variables ne sont pas transmises.

euh... il dit qu'il voit pas le rapport :S Y a peut être un truc que j'ai pas pigé dans ta démarche, mais je ne vois vraiment pas dans quel cas pratique un include via HTTP est nécessaire. EDIT : si c'est le chemin "d'installation" de ton CMS que tu cherches, tu dois bien avoir un fichier "commun" à la racine de celui ci, dans ce cas il te suffit d'y placer dirname( __FILE__ ) pour avoir ton chemin d'installation.

Bah tu repasses par Apache, il s'agit donc d'une autre instance du script, et les variables ne sont évidement pas transmises. Tu fais un : include "$config_cheminabsolu/composant/com_$composant/index.php"; Alors que la variable $config_cheminabsolu est un chemin "externe", à coup de HTTP et compagnie. Pourquoi ne pas faire directement un : include "$VRAI_CHEMIN_DU_FICHIER/composant/com_$composant/index.php"; ?

Hello, je ne sais pas si cela existe en standard, mais tu devrais pouvoir faire ça "tout seul" à coup de PS + AWK + XARGS + KILL, en utilisant les "pipe". un truc du genre quoi : ps jolisoptions | awk filtre_sur_colonnes_et_lignes_qui_t_interesse | xargs kill -9 Après perso ça ne me semble pas forcément hyper prudent de tuer les process de manière automatique, mais je suppose que tu sais ce que tu fais.

Hello, coté softs "tout prêt", absolument aucune idée. Par contre vérifier que les "file doesn't exists" ne correspondent pas à des erreurs de liens/imgs sur tes sites semble un minimum. Apache indique aussi de temps à autre quand le "maxclient" sature, ou bien que le nombre de "spawned servers" semble trop faible. Ce peut être une bonne indication. Suivant le niveau d'erreur configuré pour ton Apache, tu peux avoir une floppée de "notice" aussi... généralement à ignorer je dirais. Pour peu que tu traces les erreurs PHP dans le même fichier, tu peux avoir beaucoup beaucoup plus de choses... Notamment si PHP est en module Apache et qu'il y a une erreur au chargement (une extension qui ne se charge pas par exemple), ce sera tracé dans le error.log d'Apache. De manière générale dans le traitement automatisé d'un fichier de log il ne faut pas chercher un truc inhabituel, mais plutôt ignorer ce qui est "normal" et traiter tout le reste

Hello, dans le message d'erreur il y a un beau HTTP/1.0 404 Not Found ; donc l'url include est actif, mais l'adresse indiquée est fausse. Par contre coté perfs l'URL include c'est généralement assez désastreux, es tu certain que ce soit ce que tu cherches à faire ?

A mon avis le "parse error" c'est PHP qui le balance à cause du short_open_tag. Je suppose que tu as des balises du genre : <?xml ... ?> dans ton fichier. Il faut les remplacer par quelque chose comme ça <<?='?'?>xml ... <?='?'?>>. (ou bien tu fais un echo massif de l'ensemble du tag... selon les préférences)

Hello, pour ce problème en particulier, il suffit généralement d'augmenter le "max_connections" coté MySQL (limité à 100 par défaut il me semble). Maintenant, s'il atteint souvent ce seuil, c'est très probablement qu'il y a un soucis dans la configuration de MySQL ou dans les requêtes SQL.

Hello, ça ne doit effectivement pas courir les rues : un hébergeur "vraiment pas cher" (cf paiement Allopass) qui autorise les gros traitements video (cf ffmpeg) ; je demande à voir

Dadou : si si, ça concerne aussi l'offre payante. Par contre histoire de nuancer un peu : certains sites ne mettent pas le tag xiti sur toutes les pages, et il semblerait que ce graphique représente le nombre de "visites", et non le nombre de "visiteurs uniques".