Anonymus

Mais on aura le nom du serveur, qui n'est pas forcément le nom de domaine hébergé par le serveur.

C'est possible, c'est la solution choisie pour tout un tas de sites. (moi même, etc.. ) Pour ce qui est du 720 d'OVH, par contre, je ne connais pas ses limitations, mais je doute un peu..

Non ! Si tu travailles avec les magic quotes désactivés, je te conseille de les activer. Ce que tu peux faire, c'est les activer sur ton serveur local pour avoir une config. identique à un serveur, voire ajouter la 2e fonction donnée par Petit Ourson. Perso, soit je travaille avec les quotes auto. activés, soit je suis obligé d'échapper toute saisie d'utilisateur. Quand c'est automatique, c'est mieux Et quand c'est le serveur qui s'en charge, on risque pas d'en oublier

A priori, l'erreur vient de là : output started at /home.2/www/accueilfi2.php:13 Jettes un oeil à la ligne 13 du fichier accueilfi2.php, et postes nous le début de ce fichier

Tu as peut être un problème de cache, dans 'wordpress'. Essaies de voir s'il n'y a pas un paramètre 'cache', qu'il faudrait désactiver, le temps que tu fasses tes tests, voire 'mettre à jour le cache', que l'on appelle aussi ' calculer le cache'.

L'echappement des guillemets est une mesure préventive. C'est tout simplement pour restreindre les risques de hack de ton serveur. Apprends à t'en servir plutot que de chercher à les désactiver, tu auras tout à y gagner.

Le second problème est bien celui ci. Tu modifies les extensions, mais des erreurs s'affichent. Ces erreurs seront forcément typiques 'php', et identifieront ton site comme un site tournant sous php. Il y a un certain nombre d'erreurs de base à ne pas faire, qui évitent dans un premier temps, le passage des hackers. - Ne pas se servir de programmes tous faits (ou alors des programmes durement éprouvés). - Repérer les failles courantes, que l'on fait en php, et les corriger. Parmi celles ci, citons : - les include, - les formulaires (et tout passage de paramètres), - les mails (et tout système d'envoi de masse), - etc.. - Puis se mettre dans la peau du hacker, en se disant qu'on va essayer de faire 'sauter son site'. 2 Conseils : - Ne pas sous estimer les hackers, - Se dire en permanence : " Si, l'utilisateur le fera !!" (Pour le second conseil, ca tient surtout de la réflexion : " Il ne fera pas ca, tout de meme !? Ben si, il le fera ) Enfin, prendre en considération que : Ce n'est pas parce qu'un hacker n'a aucun intéret à 'le faire', qu'il ne le fera pas. Autrement dit, t'as des cons partout. Sur internet, ils sont organisés. Anonymus.

C'est une technique qui permet de se prémunir d'un certain nombre de risques, ou disons plutot d'un certain degré de 'hacker', mais il suffit de pas grand chose pour connaitre le langage. Par exemple : Jettes un oeil aux outils du Hub, et tu verras un 'analyseur d'entètes'. Celui ci permet de savoir sous quelle plateforme tourne ton site. Si ton site tourne sous 'unix' (linux), inutile de faire croire qu'il tourne en ASP (alors que l'inverse pourrait être vrai). Anonymus.

Alors que les hébergeurs proposent Php5, tu remarqueras que certains programmes tournent toujours avec l'extension php3. Pourtant, cette extension ne devrait plus avoir lieu d'être, puisque le php version 3 est arrêté depuis belle lurette. Il se passera la même chose pour le Php5, sauf que... Le php5 n'est pas (vraiment) près de sortir. Il est assez différent du php4, et c'est pourquoi les hébergeurs proposent les 2 (ils auraient pu passer directement au 5). Ils ne pourront pas passer comme ca, du jour au lendemain, à la version 5, car (vraiment) beaucoup de scripts sont faits pour tourner sous php4, et ne marcheront plus. Pour ce qui est de l'extension, ca ne sera pas un problème non plus. Un coup de rewriting et le tour sera joué. De plus, dû à la compatibilité envers php4, il serait étonnant que l'on passe au php5 en l'appelant '.php', sans que tout le monde se soit mis au php5, et ait du coup oublié les joies du php4. Enfin, même si l'extension passe de php5 à php, il serait étonnant qu'un hébergeur supprime du jour au lendemain les extensions 'php5'. Bref, ne te fais pas de soucis au sujet de l'extension

Bonjour, Sans rien connaitre de ton problème, je peux néammoins t'orienter sur 2 points : - ils prennent en compte la problématique du code secret à partir de 50 environs, - ils commencent à débloquer l'argent à partir de 100. Si tes revenus sont inférieurs à ceci, ne sois pas étonné, sinon, sois patient (achetes des actions google ) Nico.

Bon, alors juste pour infos : <? echo realpath("carte.php"); ?> te renvoie le chemin d'accès au répertoire du fichier 'carte.php' (à condition d'être dans le fichier carte.php) Nico.

Bonjour Maïsse, Pourrais tu nous donner plus d'indications sur les adresses des sites en question ? Je ne crois pas trop au bug de Google, alors qu'il pourrait y avoir d'autres explications, comme 'redirection', 'changement récent de l'un ou l'autre', etc.. Avec les adresses (IP ou ndd) on arriverait à te trouver une explication facile Anonymus.

Tu pourrais aussi lui conseiller le 'portage'. C'est une solution alternative pour les personnes qui ont du travail, mais qui ne veulent pas s'engager dans la création d'une entreprise. C'est un peu 'les avantages sans les inconvénients' : Personnellement, je préfère être indépendant, mais d'autres collegues préfèrent rester en 'portage', et néammoins apparaissent aux yeux de leurs clients comme une société à part entière. Bref, un choix à connaitre.

Le problème de la liste blanche que tu cites, est que s'il suffisait de s'inscrire sur une liste blanche, tout le monde le ferait. La réalité est que bon nombre de 'prestataires' ne savent pas trop comment leur serveur gère les mails. Ce que je veux dire est qu'ils fixent des regles anti-spam, et qu'ils finissent par ne plus vouloir y toucher, de peur de remettre en cause leur système. Ils se crééent des filtres qui ne marchent qu'entre eux. Remettre en cause l'un d'eux remet en cause l'ensemble. De plus, ils ne veulent pas, la plupart du temps, s'emm.. avec un 'petit site', sinon ils seraient obligé d'y employer grand nombre de personnes exclusivement pour ca.

Ne prends surtout pas pour argent comptant les conseils de l'un sur les regles de l'autre, autrement dit : Si tu as besoin de conseils sur les impots, renseignes toi aux impots, et mets en doute ce qui vient d'ailleurs. L'URSSAF est compétente pour son domaine, mais pas forcément pour les autres, quoi qu'ils en disent. D'ailleurs, s'ils veulent bien te renseigner sur tel ou tel point qui ne les concerne pas, ils le feront volontier, mais ils savent également qu'ils n'ont pas d'obligations quant à la réponse, si ce n'est pas leur domaine.

Le problème étant surtout que le PR officiel est officiel. L'autre n'est qu'une supposition Autrement dit, afficher le PR officiel est s'assurer d'avoir un résultat juste, alors qu'afficher un 'chiffre' supposé être le PR live est plus risqué. Ce n'est pas parce que 'quelques sites' affirment que ce chiffre est le PR live qu'il l'est réellement. En changeant légèrement la requète, on peut avoir beaucoup plus de chiffres... plus de PR ? Un site a t il, actuellement, un seul ou plusieurs PR ? QU'en est il des PR par thématique ? etc... Autant de questions qui ne laissent prudent quant à ce PR 'live'. Anonymus.

C'est farfelu. Ca ne sert pas à grand chose : Si la personne est capable de berner le premier site, il est aussi capable de berner le second site intermédiaire. De plus, tu risques de doubler le temps d'execution du programme, de la page. Si le second site est arreté, ou si son accès est 'lent', alors tu ralentis tout le processus. De plus, à sortir de ton serveur, tu multiplies les risques, notamment ceux inhérents au réseau en lui même. Bref, c'est 'capilo-tracté', autrement dit tiré par les cheveux ! Pour en revenir aux formulaires par méthode GET, il faut savoir qu'il est aussi possible d'ouvrir une page sur un serveur distant, en simulant l'ouverture de la page par méthode POST. Autrement dit, même si c'est une précaution élémentaire, elle n'en reste pas moins 'basique' Anonymus.

Non. Tu cherches à prendre le problème à l'envers. Tu dois déterminer le front office avant de chercher un backoffice. On ne sait pas quelles images, quels textes sont à modifier, et c'est cela qu'il nous faut. Sans ca, donc sans le front office, pas de back office. Idem pour la base de données. Modifier le front office n'est pas le plus compliqué, mais ca ne se fait pas à travers un backoffice. Par contre, celui ci comme celui là ne se font pas (non plus) sans avoir déjà la structure de la base de données. Ce ne sont pas des modules que l'on juxtapose les uns à coté des autres. Ce sont des modules interdépendants. Sans l'un, impossible de faire marcher l'autre, qui ne sert à rien sans le premier. Idem avec le 3e.

Tu aurais tout intéret à passer l'ensemble de ta base de données avec le code de Country, histoire d'être débarassé du problème une bonne fois pour toutes, plutot que de garder les antislashes dans la base, et chercher juste à modifier l'affichage.

Et à tout ceci, il ne faut pas non plus oublier qu'une bonne partie des 'pirates' entrent en fait avec un pass autorisé, autrement dit, ce sont des personnes que tu auras validé auparavant. Exemple ? Tu prends un stagiaire, tu lui donnes un mot de passe pour travailler sur ton serveur, puis au bout de quelques jours tu t'embrouilles avec lui. Il part donc, mais tu oublies de désactiver ses droits d'accès. Il a donc un accès valide. Mais à trop être parano, on finit par éteindre son micro, alors..

Quand tu veux faire une requète sql, en général, tu fais ceci : $query = "select champ from table"; mysql_query($query); La variable $query peut être construite au fur et à mesure de ton programme, pas forcément juste avant la fonction mysql_query. Dans ce cas là, elle a un début, et une fin. Le début, c'est justement la première fois où elle apparait, et la fin c'est la dernière fois où elle apparait. Un exemple valant mieux que... exemples de fonctions : addslashes, str_replace, mysql_query, trim, etc.. exemples d'instructions : for, if, else, foreach, switch, etc.. Pour éditer une requète, au lieu de faire : mysql_query("select champs from table"); tu fais : $query = "select champs from table"; echo $query; mysql_query($query); Le niveau de Php est d'environs 1,346 metres Sérieux : Tout ce qui est entre les parenthèses du mysql_query() est considéré comme la requète. C'est ce que tu envoies au serveur de base de données. Voilà

Si tu parles de ce genre de figure : '".addslashes("$cuisine2%")."' C'est possible, mais pas tout à fait comme tu l'expliques. Il faut bien garder en mémoire que php et sql sont totalement différents. Dans le cas de cette requète, on commence par construire la requète. Donc, on est autorisé à inclure autant de fonctions (addslashes est une fonction, non une instruction ) que l'on veut. Les usages sont tellement multiples qu'il est difficile de t'en donner des exemples, mais tu peux multiplier ainsi tous les cas de figure, tant que tu te retrouves, à la fin, avec une requète sql 'normalisée'. Donc, en cas de problèmes, juste avant la fonction mysql_query, tu peux éditer ta requète, pour voir si elle correspond bien à une requète sql. Si elle est valide, c'est bon. Sinon, c'es au niveau php qu'il faut revoir la construction de la requète.

Non, effectivement, ca ne parait pas possible sur un forum. Sarc, très patient, t'as demandé un certain nombre de choses, qui lui sont indispensables pour pouvoir t'aider (voir son dernier topic). Ce n'est pas pour t'em.., c'est bien pour t'aider. Si tu ne réponds pas aux questions, ni lui ni personne (je crains) ne pourra t'aider. Sur un forum comme sur icq/msn/autres. Anonymus.

Le problème auquel tu es confronté est que tu ne sais (a priori) pas combien d'antislashes tu dois enlever. A faire une fonction qui en enlève 'jusqu'à' une dizaine, tu pourrais bien enlever des slashes qui auraient été mis sans vouloir échapper quoique ce soit. Ce genre d'erreur est dû aux formulaires qui ajoutent des slashes. On entre son nom, style : O'Hara, et ca ajoute un slashe : O\'Hara. Si l'on se sert de la fonction 'Retour', ca garde le slashe, et lorsque l'on revalide ca recréé un slashe échappement pour l'apostrophe, mais aussi pour le slashe existant. Ca multiplie ainsi à chaque fois, le nombre de slashes. Le formulaire de contact d'OVH est fait ainsi... Si tu demandes à enlever les slashes, sans savoir s'il y en a 1, 5 ou 10 à enlever, alors les noms du style : \/ictoire (avec un slashe et un antislashe) vont te créer des bugs.. Une des solutions est peut etre justement de les compter : S'il y en a qu'un seul (sans apostrophe derrière), alors il est volontaire. S'il y en a 2, ou s'il y a un apostrophe derrière, c'est qu'il a été ajouté automatiquement. Mais on imagine aussi comme cela que ca peut créer des bugs Une seconde solution pourrait être de les remplacer par des espaces (!?) A voir

osCommerce :