Kioob

Si "zlib" n'est pas présente, ob_gzhandler ne fonctionnera pas pour autant. De plus, "ini_set()" retourne par défaut l'ancienne valeur. Donc un "if( ! ini_set( 'zlib.output_compression', true ) )" sera déclenché à chaque fois que la compression n'était pas déjà active. Quant au fait de couper ini_set(), déjà ce serait idiot de la part de l'hébergeur et de plus je ne suis pas certain que ça ne plante pas complètement le script avec un "fatal error, call to undefined function ini_set()" ou un truc du genre.

Je crois que personne ne serait assez fou pour faire de l'infogérance sur du Plesk . J'ai eu la "chance" de travailler avec des machines sous Plesk, et sait donc à peu près où sont stockés ces fichus fichiers... et encore. En tous cas là c'était un joli fichier de log Apache qui faisait quelques 60Go sur une partition de 70Go.

Idem.... sinon je vois pas bien l'intérêt de tout flinguer en changeant l'auto_increment

N'est ce pas risqué dans ce cas de prendre une machine chez ce type de fournisseur ?

Et bien si tu n'as pas les compétences pour trouver ce qui sature cet espace disque, le mieux est de passer par les services de quelqu'un qui les a (Dan par exemple). Après, intervention en urgence un week end, faut voir Dans tous les cas : ton "hébergeur" n'est pas sensé avoir un support ?

Bonjour, une partition saturée à 100%, ce n'est jamais bon effectivement. Et si les données MySQL y sont stockées, c'est évident que c'est la cause des corruptions de la base. Le problème serait plutôt de trouver ce qui sature complètement cette partition : fichiers temporaires de mod_deflate (dans /tmp en théorie), fichiers de logs Apache (avec Plesk dans /home/vhost/SITE/logs/ je crois), fichiers de sessions non effacés (aucune idée du lieu de stockage avec Plesk). Le tout agrémenté d'un partitionnement "à la con" made in OVH, c'est pas gagné

Hello, si c'est juste l'ID de l'auto_increment qui te gène, ça se passe coté MySQL (tu devrais meme pouvoir le modifier simplement via phpMyAdmin). Si j'en crois une rapide recherche Google, en SQL directement ça donnerait : alter table XXXX auto_increment=1. Toutefois : es tu certain que ce soit bien utile ? C'est sensé être un numéro "interne", qui n'a aucune importance en soit.

Hello, problème délicat effectivement. Je rencontre parfois le même problème : mes clients me demandent souvent si je n'aurais pas un "bon" développeur à leur conseiller, étant moi même très rarement disponible. Parmis les forums auxquels j'ai participé, j'avoue avoir rarement (si ce n'est phpApps, il y a bien longtemps) croisé quelqu'un qui semblait remplir toutes les caractéristiques d'un tel profil. Maintenant si je devais vraiment partir en chasse, je suppose que je commencerais par phpFrance qui me semble présenter des réponses relativement pertinentes aux différentes questions posées (toutefois je n'ai fait que survoler quelques sections du forum). Si je prends mon cas j'ai été recruté via WebmasterClub, et mon collègue via Viadeo. WebmasterHub correspond plus à des profils "webmaster" pour moi : un peu touche à tout, avec des connaissances dans de nombreux secteurs. Profils très polyvalents à priori, mais pas adaptés à un "gros" projet où chacun a une tâche "pointue" qui lui est propre. Mais je peux me tromper hein D'ailleurs dans ton offre, quelques points me gènent : - tu ne tiens compte vraiment que de l'expérience en "agence web, en SSII ou comme indépendant" ? Je veux dire, on a pas forcément les mêmes références, mais de ce que j'ai vu ce ne sont pas forcément les meilleurs profils : comme tu as indiqué, on y croise le pire comme le meilleur. - un bon développeur qui aurait également de solides connaissances d'administration système ; la double compétence cela diminue fortement le nombre de candidats non ? - j'ai sûrement de bien mauvais préjugés mais pour moi rechercher un "bon développeur expert en CMS" c'est comme rechercher un bon chef cuisinier expert en plats préparés. C'est à dire que ce n'est pas forcément incompatible, mais ce n'est (pour moi) vraiment pas lié. Bonne chance dans tes recherches en tous cas.

Si le ini_set( "zlib.output_compression" ) ne fonctionne pas, je ne vois pas pourquoi le ob_gzhandler fonctionnerait... enfin sauf si on parle de versions archaïques de PHP (inférieures à la 4.3 à priori).

histoire de chipoter, c'est un script SH là

Oki, effectivement s'il s'agit d'UTF-16, ça change la donne. Je suis loin d'être expert en la matière, mais pour le coup je verrais bien un coup de mb_ereg_replace(), non ? PS : normalement dans un fichier XML l'encodage est précisé non ?

Bonsoir, donc pour la première partie, en fait tu crées un "compte administrateur" (couple login/pass) que tu stocks dans un simple fichier. A la limite pourquoi pas. Mais as tu vérifié les droits d'accès à ce fichier ? Car après tout, c'est sûrement le plus important : une fois créé, il devrait avoir 0600 voir 0400. C'est à dire que seul l'utilisateur faisant tourner PHP devrait pouvoir lire ce fichier. Pour ce qui est de la "sécurité" apportée, elle est très très relative : à la moindre "faille" sur ton site permettant d'inclure ou lire un fichier arbitraire, ces identifiants seront accessibles. Ce qui ne serait pas forcément le cas s'ils étaient stockés en base de données (les identifiants d'accès à la base de données peuvent être eux aussi compromis, mais celle ci est rarement accessible de l'extérieur, contrairement à ton site). Pour le deuxième point, pourquoi pas. Je ne pense pas que ça ne changera grand chose non plus, le contenu de ce fichier bénéficiant d'un hachage avec grain de sel, même l'attaque par dico prendrait des plombes. Ce qui me fait peur, c'est surtout la suite. Pour moi là on a juste évoqué des "petits plus" qui sont à mon sens très loin de constituer des failles de sécurité... Si au final tu mets tout ça en place pour utiliser une bête identification à la ".htaccess/.htpasswd" c'est vraiment se donner du mal pour rien : le protocole n'étant pas sécurisé, tu pourras faire toutes les galipettes que tu veux que ça n'y changera rien du tout. Quant aux permissions d'accès à des fichiers/dossiers, tu n'as pas te ré-identifier : le script tourne déjà sous un certain compte utilisateur, et hérite donc des droits d'accès associés. D'où l'importance des droits sur les dossiers et fichiers.

Hello, question (vraiment) bête : ta variable $xml, tu en fais quoi après le str_replace ?

Hello, l'entête "expires" était déjà une bonne chose oui. Après quelques retouches pour limiter la latence et la conso mémoire, ça donnerait ça : header('Content-type: text/html; charset: ISO-8859-1'); header('Cache-Control: must-revalidate'); /** * Active la compression interne de PHP. */ ini_set( 'zlib.output_compression', true ); $lastModified = filemtime( $file ); header('Last-Modified: '. gmdate('D, d M Y H:i:s', $lastModified) . ' GMT' ); $offset = 7 * 24 * 60 * 60; header('Expires: ' . gmdate('D, d M Y H:i:s', time() + $offset) . ' GMT' ); $etag = 'x-'.dechex($lastModified).'-'.dechex(filesize($file)); header('ETag: "'.$etag.'"' ); $modified = true; if( isset( $_SERVER[ 'HTTP_IF_MODIFIED_SINCE' ] ) ) { $last_load = @ strtotime( substr( $_SERVER[ 'HTTP_IF_MODIFIED_SINCE' ], 0, 29 ) ); if( $last_load >= $lastModified ) $modified = false; } if( ( $modified === false ) or ( isset( $_SERVER[ 'HTTP_IF_NONE_MATCH' ] ) and strpos( $_SERVER[ 'HTTP_IF_NONE_MATCH' ], $etag ) !== false ) ) { if( substr( php_sapi_name(), 0, 3 ) === 'cgi' ) header( 'Status: 304 Not Modified' ); else header( 'Not Modified', true, 304 ); /** * Evite que PHP envoi malgré tout l'entête GZIP */ ini_set( 'zlib.output_compression', false ); exit; }

Yep, s'il s'agit du code HTML ce n'est certainement pas à PHP de faire ça en interne, mais comme le cap'tain l'indique tu peux malgré tout lui indiquer spécifiquement une telle conversion. S'il s'agit d'HTML pur, tu peux même éviter l'étape de bufferisation, avec un simple file_get_contents(). Mais dans la mesure du possible, autant modifier directement la source non ?

Non, le mot de passe circule dans les entêtes HTTP en clair (en base64), ce n'est qu'une fois obtenu par Apache que celui ci utilise crypt() pour le comparer avec la version hachée stockée dans le .htpasswd. Le fichier ".htpasswd" est sécurisé oui ; mais le protocole ne l'est absolument pas. Pour remédier à cela il y a l'identification "Digest" prévue dans la RFC ; mais aucun navigateur de la gère... Essaye par toi même tu verras bien. Il existe de nombreux outils de ce genre, qui affichent en temps réel les mots de passe HTTP, SMTP, POP, IMAP et FTP qui circulent sur le réseau...

En cas de "sniffer" réseau, ou même d'attaque "man in the middle" (généralement assez facile affaire par les autres clients de votre hébergeur), même sur court instant le pirate obtiendra le mot de passe (en clair) du fichier .htpasswd ainsi que la jolie URL... Au moins avec les sessions et un mécanisme anti "vol", il n'y a que la soumission du formulaire de connexion qui reste sensible.

Hello, tout dépend de ton niveau je dirais : via le système de template ça peut être une bonne solution pour apprendre le HTML dans un cas concret. Mais ce n'est clairement pas en utilisant un CMS que tu vas comprendre les rouages du protocole HTTP, le fonctionnement de PHP, ou l'interrogation de base de données. Certains pourraient te dire que tu peux "regarder" le code de Joomla pour comprendre comment ça marche ; mais du coup pour le coté mise en pratique de l'apprentissage c'est zéro. Sans oublier que Joomla est loin d'être une référence pour ce qui est de la qualité du code. Joomla ça revient presque à faire du Word, avec le coté "gestion de document" en plus quoi. Pour un diplome de documentaliste c'est peut être très bien. En tous cas je trouve ça étonnant de la part d'une boite spécialisée de vouloir utiliser un produit résolument grand public. Histoire de ne pas partir de rien, et de vraiment "programmer", je conseillerais plutôt l'utilisation d'un Framework PHP récent. Mais un framework qui reste un framework (pas Symphony quoi), comme Zend Framework par exemple. Coté Framework français, tu peux toujours regarder Jelix et Copix sinon, même si je n'ai jamais vraiment regardé ce que ça donnait.

Oulah... je vais tenter de décortiquer tout ça, du moins partiellement. === htmlspecialchars / htmlentities La différence entre htmlspecialchars et htmlentities vient surtout des accents : htmlspecialchars n'échape que les caractères "HTML" : < > & et je suppose le " tandis qu'htmlentities fait aussi les accents. Donc si ta page est en ISO-8859-1, et que tu n'affiches aucun accent, htmlspecialchars suffit. Si ta page est en ISO-8859-15, et que tu n'utilises que des accents français, htmlspecialchars suffit aussi. Sinon c'est htmlentities qu'il faut utiliser. Cerise sur le gateau, si tes accents proviennent d'un Windows, c'est du cp1252. Et htmlentities ne travail qu'avec l'ISO-8859-1 ; donc il faudra une fonction maison. Autre solution, tu fais comme 90% des webmasters, tu ignores complètement ça et tu croises les doigts pour que ça passe chez tes visiteurs. C'est plutôt risqué / crade, mais les webmasters sont souvent fainéants Pour ce qui est de la fiabilité de htmlspecialchars, bah ça dépend de quoi tu parles Il empèchera systématiquement du code HTML d'être interprété comme tel oui. Mais ce n'est pas du tout un mega firewall de la mort qui tue... rien à voir même === mysql_real_escape_string mysql_real_escape_string est "suffisant" si on respecte quelques règles : déjà c'est à utiliser sur les chaines. Exemple : $requete = "select unchamp from unetable where autrechamp = " . mysql_real_escape_string( $tavariable ); Dans ce cas mysql_real_escape_string() ne protégera rien du tout... il faut au moins : $requete = "select unchamp from unetable where autrechamp = '" . mysql_real_escape_string( $tavariable ) . "'"; A condition que tu sois absolument certain que "$tavariable" soit toujours de type numérique quoi. De plus, suivant les librairies qu'on utilise il est possible d'oublier d'utiliser mysql_real_escape_string(). C'est pour cela qu'on conseille généralement l'utilisation de syntaxes du genre PDO, qui évitent les oublis : $query = "select unchamp from unetable where autrechamp = ?"; $params = array( $tavariable ); Là tu es certain de ne pas oublier les échapements, c'est pris en charge "automatiquement". Evidément un goret peut toujours s'amuser à mettre directement ses variables PHP dans le code SQL, mais ça on ne pourra jamais l'empècher. === pim, pam, poum et sa clique Là tout comme les autres je sèche. A mon avis tu ajoutes plus de failles potentielles que tu n'en résouds. Pour un truc sécurisé je conseillerais plutôt : - SSL, pour que toutes les communications soient cryptés. - éventuellement un JS pour envoyer une version "hachée" du mot de passe, si jamais tu n'as pas de SSL. - se baser ensuite sur les sessions, en acceptant les ID de session que via cookie et non URL. - utiliser un mécanisme de type "regenerate_id" pour limiter les possibilités de vol de session.

Hello, j'ai du mal à saisir quel est ton soucis exactement : c'est le code HTML qui est en ISO, ou bien il s'agit des données en base ? Parce que s'il s'agit juste des commentaires dans le code PHP, on s'en fout un peu beaucoup

Si j'ai bonne mémoire la version Vista d'Outlook Express (= Windows Mail) n'utilise plus exactement le même algo (NTLM/SPA) pour "l'authentification par mot de passe sécurisé" ; si bien que des programmes comme Exim déconnent pas mal avec. Diverses solutions : - passer en SSL - désactiver toute sécurité - se débarasser une bonne fois pour toute de cette pourriture d'Outlook Express Nota : bon je viens de relire, le soucis avec le NTLM et Exim ne concerne évidement que l'émission, pas la réception...

Pour résumer un peu ces 3 "versions principales" : - mod_php : ce qu'on appel "module", c'est la version intégrée à Apache. Il s'agit généralement de la version la plus rapide en terme de PHP pur, mais remis dans le contexte d'un site Web complet ce n'est pas forcément le cas. Toutefois le principal soucis reste la sécurité (tous les sites et applications utilisant PHP tournent sous le même utilisateur Unix). C'est la configuration la plus répandue sur les serveurs dédiés pour des raisons historiques d'après moi, et aussi parce que c'est la plus simple à installer. - la version (fast)CGI, qui est compatible avec tous les serveurs web. Si utilisée via fastcgi et suexec, implique une légère baisse de performances par rapport à mod_php ; mais apporte en contrepartie une sécurité fortement accrue (un user différent par site, application, ou sous domaine, comme on le sent). Elle permet également d'utiliser des serveurs web beaucoup plus performants que le "vieux" Apache prefork : apache2 event et lighttpd par exemple. Configuration qu'on retrouve chez la grande majorité des hébergeurs mutualisés, notamment pour l'aspect sécurité. De plus avec le safe_mode et l'open_basedir qui disparaissent de PHP 6, ce sera bientôt notre seule solution sécurisée. - la version CLI (Command Line Interface) : totalement indépendante du moindre serveur Web. Pour utiliser ses scripts PHP comme tout autre langage de script à la Perl, SH, Python, etc. La configuration par défaut est légèrement modifiée : les erreurs ne sont pas affichées au format HTML, la bufferisation est désactivée, et il n'y a pas de "time_limit". C'est pour moi la meilleure solution pour les crons. Bien sûr il s'agit de "généralités", il y a toujours des cas particuliers...

Il demande une solution propre et vous lui conseillez le wget Ca peut avoir quelques avantages dans le cas de PHP en module Apache si le serveur n'a aucune sécurité, mais quand même : ça reste la solution la moins propre... (mais la plus simple, je vous l'accorde). Grasshoper : je ne connais pas ta distribution, mais pour reprendre l'exemple de Debian les 3 versions peuvent être installées simultanément sans soucis oui.

Bonjour, oui : installer également PHP en cli Je ne sais pas ce qu'il en est des autres distributions, mais sous Debian les trois versions principales de PHP sont disponibles simultanément et sans le moindre conflit. aptitude install php5-cli

Hello, peux être devrais tu commencer par demander à l'éditeur du soft en question d'où vient ce bug, non ? Et éventuellement de le corriger