Kioob

bonsoir, tu n'aurais pas un peu beaucoup oublié le mysql_real_escape_string() ?

Hello, c'est parfaitement possible mais : - aucune idée de comment mettre ça en place avec Plesk. - attention aux abus, un accès FTP un peu trop "libre" fini bien souvent "squatté" pour transfert de films illégalement Sinon avec PureFTPd et le module d'identification par MySQL c'est très facile oui. Il suffira d'un simple "insert" SQL ; il pourra même aller jusqu'à créer le dossier si vous voulez.

Hello, je m'écarte du sujet, mais en compressant les pages de cette manière tu fais souvent plus de dégats qu'autre chose à mon avis : *) déjà j'ose espérer que tu utilises readfile() pour le lire le fichier statique, ce qui devrait au moins limiter les dégats coté gestion mémoire. *) ob_start( 'gz_handler' ) stocke tout le contenu en mémoire, et envoi la version compressée du fichier qu'à la fin du traitement. Cela induit un léger lag pour l'utilisateur (=> impression de lenteur), en plus du surplus de consommation mémoire. Préférer un ini_set( 'zlib.output_compression' ) qui n'a aucun de ces deux effets négatifs ; en contre partie la page sera légèrement moins bien compressée, vu qu'il travaillera par petit tronçon (de 4Ko je crois). *) et quid des entêtes HTTP pour gérer le cache du navigateur ? Prends tu la peine de gérer ces entêtes correctement (au moins le "last-modified"), ou bien forces tu les navigateurs à re-télécharger ces pages systématiquement ? *) rediriger un fichier statique vers PHP peut induire une forte surcharge pour un serveur en fastcgi (souvent le cas chez les hébergeurs). Même si le but est louable (améliorer la qualité de navigation des visiteurs), j'ai bien peur que l'effet final soit inverse. Le mieux serait certainement de demander ce module à l'hébergeur non ? (désolé pour le HS...)

Pour le coté sécurité, je ne vois pas de soucis non. Maintenant, avec un error_reporting en E_ALL tu as au moins une erreur sur l'utilisation du cookie. Pour ce qui est de la maintenance du code... bah... ce n'est pas le sujet

Que ça risque de s'éterniser ? Regardes les logs, les crons, lance au moins chrootkit dans le doute, installe suhosin, passe en fastcgi, etc. Mais mettre en place un environnement "sécurisé" par dessus un environnement qu'on sait compromis, il n'y a que moi que ça choque ?

Le minimum serait déjà de faire tourner tout ça via FastCGI, avec chaque site sous un user différent ; ça permettrait de rapidement identifier le site fautif... et de limiter toute propagation en cas de "hack". Mais bon... les problèmes de sécurité sont bien souvent pris à la légère.

La colonne est ambigu car la table est utilisée deux fois. Le "group by" étant fait sur a.Dossards, c'est donc a.Dossards que tu dois sélectionner. Et met un "order by" ascendant, sinon tu risques de ne pas comprendre

Oui, ou un seul pour monter à 10Mbps... ça ne change rien au "problème" : sans plus d'infos sur le trafic "habituel" ni la durée du pic, on ne peut absolument pas se prononcer sur la valeur de ces 700Kbps.

Béh tout est relatif... si en temps normal le débit sortant dépasse pas les 100kbps, un "pic" à 700kbps peut être anormal.... tout comme un "pic" à 150Mbps sur certains serveurs peut être tout à fait justifié :S

euh... j'insiste, mais qu'est ce qui te gène dans cette requête ? select Dossards, 1+count(b.Total_points) as place from danseur_$Saison a left join danseur_$Saison b on a.Total_points < b.Total_points group by a.Dossards order by place desc, Dossards asc

S'il a eu les droits root il peut avoir installé un "root kit" ; et malgré les quelques outils de détection, dans ce cas c'est souvent "foutu" car il aura toujours la possibilité de masquer ses actions. Ici cela ne semble pas le cas mais bon... je n'en mettrais pas ma main à couper perso.

Hello, délicat quand même... je suis peut être extremiste mais pour moi à partir du moment où une machine a été compromise elle n'est plus fiable : il faut réinstaller. La release 1 d'OVH, c'est bien la vieille red hat 7 daubée ? Si c'est le cas, je ne pourrais guère t'aider non plus... c'est très éloigné de ce que j'utilise d'habitude.

Pourquoi y aurait il des problèmes plus "poussés" ? Le seul conflit avec XML (ou autre contenu) est évidement le fait que cela empèche l'utilisation des 2 caractères '<?' . Après c'est comme tout : si les bénéfices de cette syntaxe vous semble mériter la prise de risque qui en découle, et bien soit, continuez comme ça. On n'ira pas vous en empêcher ; et ça ne changera évidement rien pour un petit site perso. Ce que je trouve juste dommage c'est qu'à mon sens il n'y a justement aucun bénéfice. Donc c'est s'exposer volontairement à des soucis pour rien.

Sans oublier le coté "sécurité" : l'hébergeur met à jour sa version de PHP et vire le short open tags par mégarde => hop, tous les codes sources du site sont téléchargeables à cause de 3 petits caractères négligés. Note : pour continuer dans le HS, un code "light" ne sera pas forcément plus rapide. Déjà une page qui ne gère pas les réponses 304 aura de très grandes chances d'être beaucoup plus lente d'accès à l'internaute. De même que l'utilisation de CSS / JS non versionnés impose des requêtes inutiles au navigateur. C'est un peu le même principe que le cache de requete MySQL : il ralenti de 5% les requetes, mais dans 90% des cas il évite complètement l'exécution de la requête.

Oui le htmlspecialchars / htmlentities est souvent fait "inutilement", mais il est là en temps que sécurité justement : le fait de limiter l'accès uniquement aux méthodes et propriétés de l'objet ceci cumulé à l'échappement quasi systématique procure à mon sens un solide niveau de sécurité. Alors oui ça a un coût en terme de performances, mais pour moi c'est comme les "mysql_real_escape_string" : je préfère ne pas prendre de risque et être certain d'écarter cette possibilité. Tout ceci sans oublier les autres avantages d'un système de template, comme par exemple la compilation "statique" : même si la page utilise une dizaine de template, le code PHP généré est contenu dans un seul script, ce qui réduit "dramatiquement" le nombre d'include final. Au encore la génération d'etag : toutes les données affichées étant disponibles depuis le contexte de l'objet "template", il est très facile de générer un ETag avant l'affichage de la page... et donc de gérer le cache http de manière transparente et sans risque d'erreur. Au final, tous les petits plus de ce genre offrent une navigation plus rapide à l'internaute, une sécurité fortement accrue, et une facilité de maintenance exemplaire. Pour ma part, j'aurais beaucoup de mal à me passer de mon moteur de template. Mais bon.... je m'écarte un peu beaucoup du sujet ; tout ceci était pour dire que le {login} dans un moteur de template ne faisait pas "que" correspondre à un <?php echo $login ?> ; loin de là. Après il y a des moteurs de template qui acceptent la syntaxe PHP mais la modifient eux même. Pour le XHTML je ne sais pas exactement, en tout il y a peu de chance d'avoir plus d'une dizaine de balises de ce genre en tous cas. J'en ai régulièrement 4 pour ma part. Et pour le XML de manière générale, j'en sais encore moins... il faudrait regarder du coté de la spec. Pour le "<?php=" je ne serais pas d'accord non plus C'est là aussi le genre de raccourcis qui n'apportent rien au code selon moi, sinon d'en rendre la syntaxe encore un peu plus complexe à lire.

Bonsoir, détrompe toi justement, j'ai au moins rencontré l'hébergeur "réagi" dont le short open tags est/était désactivé pour PHP 5 (et ils utilisent APC pour info). Pour ce qui est de l'équivalent templates / PHP, le soucis c'est que le code exact correspondant à une {login} est <?php echo htmlspecialchars( $login ) ?> Voir même selon les moteurs : <?php echo html_entities( $this->login ) ?> Ce qui apporte (selon moi) une solide couche sécuritaire en plus. Edit : pour le point génant avec le XML, ne serait ce que pour du XHTML on a ces entêtes à placer ; ce qui en l'état provoque un "parse error". On est donc obligés d'utiliser PHP pour afficher ces tags, ce qui ne me semble pas très élégant. <?xml version="1.0" encoding="iso-8859-1" ?> <?xml-stylesheet type="text/css" href="/include/default.1204974022.css" ?>

PHP 6 se débarassant de beaucoup de "fausses bonnes idées" héritées des versions précédentes, ça ne m'étonnerait pas oui.

Que ça vienne de syscall ou non n'y change rien en tous cas : cette méthode fonctionne relativement bien, on a réduit le temps moyen de connexion durant ces "vagues" de pertes, et nous n'avons plus de connexions complètement perdues (le timeout d'origine était à 20 secondes). Sinon pour le fait que peu de gens n'ait remonté le problème, pour moi ça vient aussi du fait que peu de gens auditent leur code à mon avis La désactivation d'ipconntrack serait possible, mais je n'ai plus vraiment de temps à y consacrer : j'ai perdu un temps fou là dessus, et mon taff doit quand même être fait. Donc recompiler un kernel sur les 3 machines de prod, puis désactiver temporairement le firewall ; je ne suis pas trop motivé dsl. Sinon les 3 machines sont en 64bits, ce sont des Xeon d'ancienne génération (basés sur netburst) avec des cartes Intel. Sur les serveurs Web comme le serveur MySQL : 04:00.0 Ethernet controller: Intel Corporation 631xESB/632xESB DPT LAN Controller Copper (rev 01) 04:00.1 Ethernet controller: Intel Corporation 631xESB/632xESB DPT LAN Controller Copper (rev 01) Nous avons testé les deux interfaces, la première en 10Mbit/s FD et la deuxième en 100Mbit/s FD. Et n'ayant aucun client avec un code "propre" et centralisé, pas moyen d'auditer sur d'autres machines.

Depuis peu en fait on règle le timeout mysql assez bas, et on gère un vrai timeout coté PHP : c'est pas propre, mais au moins on arrive généralement à initialiser la connexion mysql dans un délai correct.

mmm soit j'ai fait une petite erreur en l'écrivant (de tete), soit tu en as fais une en adaptant. Mais cela fonctionne, j'en suis persuadé. J'ai utilisé ce genre de requêtes pendant des années. EDIT : donc je viens de tester sur une vieille table, et mis à part l'order by un peu foireux (la liste est à l'envers), ça fonctionne parfaitement.

<mauvaise langue>phpAdsnew / openads / openX a tellement mauvaise réputation qu'ils passent leur temps à changer de nom </mauvaise langue>

Fuzzy : regarde le pseudo de l'auteur sur le forum que tu indiques En tous cas pour moi l'IPv6 n'a réglé le soucis que durant quelques jours... ce fut une "trève" sympathique, mais le soucis n'est toujours pas réglé.

Coté "alourdissement" je suppose que tu mets toujours le tag '?>' à la fin de tes scripts non ? Et bien je vais te faire un petit cadeau : enlève ce tag de fin, qui a plus de chances de te causer des soucis qu'autre chose (retour chariot en trop...), et utilise ces quelques octets gagnés pour ajouter le "php" en début de script. Je ne sais pas comment tu structures ton code, mais s'il te semble plus clair avec une floppée de short tags, tu me fais un peu peur. Edit : je poserais même la question à l'envers : vu les problèmes que soulève cette syntaxe face à l'énorme gain de quelques octets, à quoi bon risquer les ennuis ?

Hello, pour moi : - le "<?" t'empêche d'avoir un code portable (certains hébergeurs le bloquent) - cette syntaxe n'est pas forcément claire - elle pose des problèmes pour la manipulation des fichiers XML (dont xhtml comme tu l'as souligné) - vu que de toutes façons on évite les mélanges PHP/HTML, ce "raccourci" ne sert plus à rien Voilou Pour moi c'est ce raccourci est une "Fausse Bonne Idée", je ne m'en sers plus depuis de nombreuses années et le déconseille à mes clients.

si si. Dans l'idée : select joueur_id, 1+count(b.points) as position from joueurs a left join joueurs b on a.points < b.points group by a.joueur_id order by position desc, joueur_id asc edit : j'avais oublié le "group by"...