Kioob

Tout simplement parce que les hébergeurs mutualisés font rarement tourner PHP en module ; et chaque client a son propre compte unix. Si ce n'était pas le cas, chaque client (ou site de client se faisant hacker...) pourrait sans contrainte aucune lire les fichiers "db.config.php" de ses voisins... Quant au fichier de configuration "par défaut" de PHP, il y est généralement écrit dès le début qu'il ne s'agit absolument pas d'un fichier utilisable en production (sinon on aurrait display_errors à off, log_errors à on et error_reporting à E_ALL).

Et bien pour moi faire sauter une sécurité, même quand on est "seul" sur le serveur cela reste risqué : pour peu qu'il utilise phpmyadmin, phpbb, roundcube (ou autre script externe du genre), en cas de faille dans l'un d'eux les autres applis ainsi que le site lui même sera inutilement exposé. Donc à moins d'utiliser un serveur dédié pour une seule application, il y a toujours un risque. Il s'agit quand même de faire tourner toutes les applications sous le même utilisateur... je suppose que ça ne te viendrais pas à l'idée pour les applications "non php" alors qu'elles sont beaucoup moins exposées que les applications PHP. Appel ça de la parano si tu veux, pour moi il s'agit juste de sécurité de base.

Bonsoir, les clés/index sur les champs de type BLOB/TEXT ne sont possibles que sur les premiers caractères du champ ; et il faut donc préciser cette limite. Dans ton cas plus précis, je pense que tu t'es simplement trompé de type de données : utilises VARCHAR au lieu de TEXT.

Dans le cas warnings déclenchées par l'open_basedir, je pense que la solution de l'arobase reste la plus propre malgré tout (sic...). file_exists() est déjà une fonction de test pour éviter ce genre d'erreurs non ? Pour moi c'est une idiotie d'avoir ajouté ce warning sur toutes les fonctions de test (is_dir, is_file, etc). On a à ma connaissance aucun moyen simple de faire un test "open_basedir" sans déclencher ces erreurs. Et désactiver une sécurité dès qu'on rencontre ce genre de petit "tracas" me semble bien imprudent : dans l'élan on vire le safe mode, l'openbasedir, on laisse PHP en module et on fait tourner Apache en root , comme ça on évitera aussi de se prendre la tête avec les droits d'accès.

Malheureusement si les requetes MySQL sont mal fichues, oui, cela peut vite grimper.

Je n'ai jamais dit le contraire : c'est bien pratique pour débuter. Mais quand la personne part d'une zone via formulaire, lui conseiller de faire machine arrière vers du .htaccess tout en affirmant que cela ne pose aucun problème de sécurité, je trouve ça très maladroit.

Euh petit rappel quand même : une sécurité basée sur le ".htaccess" est du genre "minimale". Le mot de passe sera envoyé en clair pour chaque fichier / hit du dossier... ce qui est nettement moins sécurisé qu'un formulaire POST suivi d'une session intégrant un mécanisme pour protéger du vol de session. De plus le mécanisme ".htaccess" n'intègre aucune mesure pour se protéger des brute force. Bref le .htaccess c'est rigolo quand on débute et bien pratique en dépannage, mais certainement pas à conseiller comme protection. L'idéal restant dans tous les cas le SSL, évidement.

Les périphériques mobiles sont de plus en plus répandus au fil des années, et leur résolution est très loin du 1280... Vous ne les voyez pas dans vos stats ? Simple : si votre design ne passe pas sur ces appareils, il y a peu de chance pour qu'ils viennent régulièrement... et qu'est ce qui vous dit que leur navigateur est compatible avec un tag xiti ? La liaison étant souvent mauvaise, il y a des chances pour que les images et autres tags "externes" soient bloqués... De plus sur mon PC j'ai deux écran 19" en mode portrait, soit deux affichages de 1024x1280. C'est à mon sens énormément plus confortable pour lire une page par exemple ; mais si le site en face ne gère pas le 1024 je vais galérer. Bref, les designs fluides on sait faire depuis des années, et les techniques se sont même améliorées depuis. Il serait idiot de s'en priver maintenant, alors que le parc est de plus en plus hétéroclite...

euh... parmis les risques : code incompréhensible, illisible, etc Utilises un tableau... // Création de la liste des articles, si besoin if( ! isset( $_SESSION['articles'] ) ) $_SESSION['articles'] = array(); // Ajout de l'article à la liste $_SESSION['articles'][] = $_GET['prod']; En tous cas et sans vouloir être méchant, se lancer dans un site "commercial" avec si peu de maîtrise du langage, c'est extrêmement risqué.

De rien C'est "automatique" tant que la zone / le domaine est également déclaré sur le serveur secondaire, et à condition que tu penses bien à modifier le numéro de série après une modification du fichier sur le serveur primaire. Et si possible, après chaque modification interroger le serveur secondaire pour s'assurer qu'il réponde bien ce que tu souhaites.

Hello, si ton serveur DNS primaire est correctement configuré toute la "zone" est recopiée par le serveur DNS secondaire, c'est à dire y compris les enregistrements MX. Et pour s'en assurer, et bien il suffit d'interroger le serveur DNS en question : nslookup -type=MX ton-domaine.tld ns.secondaire.tld

Hello, alors premier point : il y a peu de chance pour que Sivit laisse l'accès ouvert depuis l'extérieur.... demande leur, mais ça m'étonnerait fortement. Ensuite, la doc explique relativement clairement comment construire l'URL demandée ainsi que le pilote à utiliser (com.mysql.jdbc.Driver).

Vu le contexte je pense qu'il s'agit tout simplement de "mysql", et l'url serait l'host d'accès.

Hello, vaste question ici là. Par contre tu cherches un "tuto prémaché" ou bien tu veux faire toi même ? En tous cas, je vois différentes méthodes et aucune n'est parfaite : - analyse des logs du serveur web : c'est peut être la seule méthode qui est certaine de compter tous les visiteurs. Le hic c'est que c'est aussi la moins précise : ormis l'IP et le "user agent", tu n'as (en standard) aucune info sur l'internaute - via un élément "externe" : l'image par exemple, l'iframe, le script JS, voir la CSS, n'importe en fait. Il y aura toujours une petite partie du trafic qui n'appellera pas cet élément externe. - via un "include" depuis le site PHP, mais cela peu poser de gros soucis de sécurité, de performances, voir tout simplement de stabilité. Après pour obtenir des infos : via PHP tu as accès à tous les entetes HTTP, mais c'est bien tout. Et depuis JS tu as accès à plus d'infos (comme la résolution du navigateur et/ou de l'écran à priori). Commence par analyser comment font les "grands" du secteur : Xiti, Google Analytics, Weborama, etc. ainsi que les outils du genre Awstats par exemple. Bon courage en tous cas...

Hello, si j'en crois ton "top" la machine ne manque pas de mémoire : 250Mo libres et 350Mo de caches, sur 1Go c'est pas si mal. Cpu(s): 90.0% us, 10.0% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si Aucun soucis niveau disque également 0.0% wa... A moins que tu ais un kernel qui date du siècle dernier ? Par contre comme le souligne Dan, sur une dédibox le matos est de piètre qualité : c'est un processeur au rabais, et ça ne m'étonne guère qu'il sature. Perso je m'orienterais surtout vers cette piste : Apache/PHP bouffent pas mal, et il faudrait savoir pourquoi. Déjà utilises tu un cache d'opcode pour PHP : eAccelerator ou APC par exemple ? Sans faire de miracle, ça peut bien aider. Coté rewriting : je suis déjà tombé sur des sites avec plusieurs centaines (sic) de règles de rewriting dans un fichier .htaccess à la racine du site. Mine de rien ça veut dire que pour chaque fichier (html, php, images, css, js, etc) Apache se coltine ces centaines d'expressions régulières... Je ne sais pas si c'est ton cas, mais si c'est le cas : il faut structurer tout ça ; d'autant plus que ces règles ont rarement besoin d'être à la racine du site. Séparer le tout par dossier, est nettement plus efficace. Coté Apache également, as tu des modules consommateurs du genre mod_gzip installés ? Pour ce qui est de MySQL, une bonne piste pour débuter est la page "Statut du serveur" sur la page d'accueil de phpMyAdmin. Pas mal de conseils y sont donnés. Bon courage

Hello, j'en ai plus ou moins la même conception, et cela me semble très "subjectif". Mais parmis les nuances j'ajouterais : - il s'agit souvent plus "d'applications web" que de "sites web" : peu d'utilisateurs mais de gros traitements, au contraire d'un site web classique - tous les utilisateurs sont identifiés via une base centrale interne, via LDAP par exemple - si l'entreprise a plus de 10 employés, il y a fort à parier que le réseau soit basé sur ses propres serveurs DNS plutôt que le fichier hosts de chaque machine Et dans le résultat bien souvent : aucun respect des standards, aucune optimisation, et évolutivité proche de zéro (moi mauvaise langue ? ) Mais bon... c'est sûrement différent dans chaque entreprise...

re, pour ces logs d'email, ce sont surement des tentatives de spam oui ; après pour savoir si elles réussissent ou non il faudrait commencer par regarder les logs du serveur de mail (/var/log/mail.log généralement ; sauf avec Plesk...). Sinon il y a des outils qui vérifient qu'un serveur soit en "Open Relay" : demande à Google

Hello, question subsidiaire : puisque tu connais Debian, pourquoi ne pas virer cette distribution qui date de Mathusalem ? Pour ce qui est de SSH, et histoire de se rassurer un peu : tu peux limiter les accès SSH à seulement quelques utilisateurs (voir un seul) via l'option "AllowUsers" dans la config de SSH (/etc/ssh/sshd_config sous Debian) ; et tu peux également forcer l'utilisation d'une clé SSH au lieu d'un mot de passe. Pour le coup tout "brute force" sera quasiment impossible de ce coté. Et si les messages dans les logs te gènent, tu peux toujours changer le port d'écoute de SSH : ces scripts ne scannent que le port par défaut. Pour phpMyAdmin, la solution serait de ne pas le faire tourner sur le VirtualHost par défaut ; mais c'est déjà probablement le cas non ?

Et moi je déconseille vivement l'utilisation de mysql_num_rows(), sauf dans les (rares ?) cas où le développeur sait ce qu'il fait Télécharger des milliers voir millions de lignes puis les stocker entièrement en mémoire, tout ça juste pour un comptage, c'est plutôt catastrophique comme approche . La fonction count() de MySQL fait très bien son boulot, donc autant l'utiliser. D'autant plus qu'en l'occurance on pourrait regrouper en une seule requete : select id_option, count( id_utilisateur ) as nb from sondage where id_sondage = ? group by id_option

Yep Plesk, c'est tout joli, plutôt simple (clicodrome powa), mais coté technique (sécurité, maintenabilité, tunning) c'est zéro. Voir éventuellement du coté de VHCS, bien que je ne sois pas certain que ce soit beaucoup mieux.

hello, à vue de nez l'hébergeur conseille de mettre dans un fichier .htaccess : php_flag allow_url_fopen on Ce qui désactivera la sécurité qui te pose soucis.

A la louche vu le problème de départ je commencerais par mettre en place du rewriting, histoire d'utiliser le même script plutôt que de chercher à dupliquer l'index.php. Une URL du genre : /gite/france/lorraine/moselle/index.php?type=gite&pays=france&region=lorraine&departement=moselle Ca fait quand meme beaucoup de redondance. Autant utiliser uniquement : /gite/france/lorraine/moselle.html Qui redirigerait par exemple sur : /gite.php?pays=france&region=lorraine&deparement=moselle Non ? Pour ce qui est variables $_GET recopiées en $_SESSION, l'intérêt m'échappe : peux tu m'expliquer ta démarche ici ? Idem pour les "includes qui font des tris sur une base de données à partir des variables sessions" ; que veux tu dire par là ?

Mouais plus ou moins je me suis mal exprimé alors : cette URL est "relative" au site courant, mais est "absolue" pour ce site. En gros 3 cas : - URL complète, avec nom de domaine : http://truc.bidule.fr/styles/test.css - chemin "web" absolu : /styles/test.css - chemin relatif : styles/test.css Or là où le 1er et 3ème cas passeraient en local, le deuxième à très peu de chance de fonctionner. (Est ce assez détaillé cette fois ? )

hello, pour peu que les images / css / scripts soient indiqués en absolu ( exemple: /styles/test.css ), la page ne sera pas consultable en local.

Comme expliqué ci dessus le terme serveur est utilisé à la fois pour décrire un ordinateur/machine et pour décrire un programme fournissant un service. Il n'y a pas vraiment de limitations du nombre de services par machine ; toutefois pour des raisons de performances il est effectivement parfois conseillé de faire fonctionner le service MySQL sur une machine différente du service Apache. Quant au terme "Pentium Dual ++" je suppose qu'il s'agit du nom d'un produit qu'OVH proposait. Mais ils auraient visiblement renommé et/ou changé la gamme depuis.