Mise en production d'un site PHP-MySQL

Mise en production d'un site PHP-MySQL - PHP - Programmation

Marsh Posté le 06-11-2007 à 14:22:01    

Bonjour à tous !
 
Je travaille actuellement sur une banque d'image et je ne suis pas très loin d'avoir fini...
 
J'aurais voulu savoir ce qu'on entend exactement par "Mettre un site en production".
 
Ca veut juste dire que le site est effectivement en ligne et accessible au public ?
Qu'est-ce que cela implique ?
 
A quoi faut-il être attentif AVANT de le mettre production (pour un site en PHP avec une DB MySQL) ?
P.ex. : enlever les messages d'erreurs qui sont sources d'infos pour d'éventuels nuisibles.
 
Merci d'avance !
 
(°-°)

Reply

Marsh Posté le 06-11-2007 à 14:22:01   

Reply

Marsh Posté le 06-11-2007 à 16:10:34    

Dans les très gros projets, t'as plusieurs types de serveurs :
- les serveurs de développements et/ou de test qui servent à développer et tester les modifications
- le(s) serveur(s) d'intégration(s) qui servent à vérifier que tout ce qu'on veut envoyer sur le serveur de production ne vont pas poser de problème
- le(s) serveur(s) de production(s) qui sont les serveurs finaux, ceux qui sont donc accéssible par les utilisateurs.
 
Mettre un site en production veut donc dire qu'on le met en ligne pour qu'il soit utilisé par tout le monde.
 
Comme tu dis, ce qu'il faut faire quand on met un site en ligne, c'est de cacher les messages d'erreurs qui peuvent fournir des informations gênantes.
Il faut aussi vérifier les limitations des temps d'exécutions et de taille mémoire autorisé par demande d'une page (afin d'éviter de saturer le serveur) mais les valeurs par défaut sont généralement suffisante.
On peut aussi modifier quelques autres réglages dans le php.ini (si on y a accés) afin de limiter les risques si on est pas sur de ce que d'autres personnes mettront comme script php sur le serveur. A noter aussi qu'il ne faut pas baser sa sécurité sur les magic_quote. Même si on peut les activer en php5, ils disparaitront totalement dès php6 (c'est déjà fait dans les versions de développement de php) et de toute manière, c'est des fonctions qui ne protégeaient que partiellement le système.

Reply

Marsh Posté le 06-11-2007 à 17:33:46    

Merci pour ces précisions !
Et surement à bientot... (-;
(°-°)

Reply

Marsh Posté le 06-11-2007 à 20:36:30    

Tout à fait personnellement, je ne cache ni les messages d'erreur, ni les warnings.
 
Pourquoi ?
 
Parce que si ils existent c'est qu'il y a une raison, une utilité !
En masquant ces messages tu ignoreras que ton site comporte des failles / est buggé, ce qui à mon sens est encore plus grave.
 
La politique de l'autruche, très peu pour moi.
A toi de voir si tu préfères te voiler la face et dissimuler tes faiblesses au lieu de chercher à t'améliorer.
 
:D


Message édité par CyberDenix le 06-11-2007 à 20:36:52

---------------
Directeur Technique (CTO)
Reply

Marsh Posté le 06-11-2007 à 21:10:41    

:jap:


---------------
Directeur Technique (CTO)
Reply

Marsh Posté le 06-11-2007 à 22:26:22    

Je compte bien débugger mon site au mieux ! Et le fichier log est une très bonne idée. Cool NazzTazz.
Le truc c'est de ne pas gêner l'utilisateur et pas de se voiler la face. Mon but est de faire un site qui fonctionne au mieux mais si ces erreurs peuvent, en plus de gêner l'utilsateur, fournir des erreurs qui peuvent être gênante, c'est peut-être bien de ne pas les afficher.
(°-°)

Reply

Marsh Posté le 07-11-2007 à 17:34:43    

Citation :


Mon but est de faire un site qui fonctionne au mieux mais si ces erreurs peuvent, en plus de gêner l'utilsateur, fournir des erreurs qui peuvent être gênante, c'est peut-être bien de ne pas les afficher.


 
Je voulais bien sûr dire "fournir des informations gênantes" !
 
(°-°)

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed