Ganf

à rappeler tout de même qu'en général les frais engager pour faire appliquer le droit sont imputables à celui qui est en tort (donc ne comptes pas dans la balance si on est sûr de son coup et si le juge trouve qu'il n'y a pas abus en déposant la plainte). C'est important parce que sinon ça revient à autoriser toutes les arnaques à faible montant (vu que faire respecter le droit couterait plus cher)

Non il n'est en droit de rien du tout. Maintenant il me parait normal que quelqu'un qui offre un tel service ne casse pas tout à la première demande tierce. Maintenant ils ne peuvent pas se cacher derrière une procédure automatique si ce qu'ils font est illégal. Non seulement ils n'ont rien à exiger mais en plus ça serait à eux d'obtenir confirmation d'identité avant d'établir la redirection. Ce que je te propose c'est effectivement de leur envoyer un fax signé, avec ton nom et tes coordonnées, leur demandant de faire cesser la redirection et leur signalant que tu n'acceptera aucune autre procédure supplémentaire avant le dépot de plainte si la redirection n'est pas retirée sous une semaine. Tu as tout intérêt à jouer le jeu tant qu'ils se montrent de bonne volonté (même s'ils s'abusent) : un conflit ne profite jamais à personne. Tu peux aussi rajouter que la vérification d'identité aurait du être faite à la création de la redirection et pas à la destruction, que l'existance d'une procédure complexe de destruction ne les dégage pas de leurs obligations et responsabilités légales, notament face au droit d'auteur pour les représentations de l'oeuvre.

J'ai un 404 sur les deux liens Support-EAM.

Je vais aussi parler du cas français (mais il y a des chances que le droit blege n'en soit pas loin) : - Tu ne peux pas faire ceder une marque à quelqu'un qui a l'antériorité de l'utilisation, même s'il ne l'avait pas enregistrée. Bref, si tu utilises ce site depuis avant qu'ils aient enregistré leur marque, tu n'as rien à craindre. - Une fois la marque enregistrée elle est défendable tant qu'elle est défendue. Ce que je veux dire c'est que s'ils s'abstiennent de défendre leur nom pendant une période, ils perdent leur droit à le faire par la suite. - Si ton site dure depuis trois ans, qu'il n'a pas changé d'importance depuis ce temps là (tu n'es pas passé d'un petit site perso à un gros site avec des millions de visiteurs), ils ont à mon avis perdu depuis longtemps le droit de le faire - Les marques peuvent contenir ou être composées de mots courants mais tu ne peux pas obtenir l'exclusivité de mots ou d'expressions courantes dans le domaine concerné. Tu ne peux logiquement pas réserver "tour du monde" dans le domaine des agences de voyage. (note: je parle là de conflits non voulus, si tu as réutilisé l'expression parce que leur boite s'appelle ainsi c'est une tout autre histoire). Ce d'autant plus que tu ne risques pas de faire confusion et que tu es implanté depuis longtemps. Je ne suis pas juriste (donc tout ce que je dis dois être vérifié) mais ça ressemble à de l'intimidation. Ca aurait pu presque se retourner contre eux si ils insistaient à mon avis.

Tu peux le faire sans retenue je crois. D'autant qu'en plus du contenu je trouve le graphisme et l'ergonomie très réussis

En ce moment il y a aussi atelierphp5 qui propose deux ou trois notes sympa suivant les semaines : http://www.atelierphp5.com/

Ne prenez pas ça comme des attaques, je cherche à comprendre : - Vous n'avez pas moyen de stopper l'acceptation d'une adresse mail individuelle par vous même ? Je parle là de demander à votre SMTP entrant de refuser les mails sur l'adresse qui pose problème (ou mieux, sur une empreinte du mail envoyé en X exemplaires). Au pire filtrer directement le SMTP source temporairement (mais vraiment à défaut d'autre chose) - Pourquoi avez vous besoin de stopper complètement le service email pour tous les clients ? Je ne sais pas comment le dire autrement mais merci de ne pas le prendre comme un reproche : Je suis étonné que vous n'ayiez aucune protection classique contre le flood/spam ni aucune mesure de filtre pour palier ces éventualités, au point que vous en veniez à couper l'accès mail à l'ensemble des abonnés. Sur un mutualisé j'ai toujours considéré que la maintenance du système, les mesures de protection et les aléas réseau étaient du ressort de l'hébergeur. Je suis étonné qu'on facture au client un problème réseau ou système dont il n'est pas la source (il est concerné mais il est plus destination que source ici). Tout au plus ça motiverait un arrêt du service floodé *pour l'utilisateur en question* afin de ne pas perturber les autres, ou une rupture du contrat si la charge impliquée est disproportionnée par rapport au service offert.

Les impots directement non, mais un concurrent qui porte plainte c'est plus crédible déjà. Et "prouver" en justice c'est parfois assez léger. Il suffit que le juge trouve l'option réelle comme absolument irréaliste pour que ça ne tienne plus, ou alors que le juge considère qu'il y a échange de bons procédés (donc paiement en nature) .. bref, moi je ne suis jamais trop optimiste pour ces choses là

Tu m'as mis un doute Annakin, alors je viens de vérifier. C'est bien une syntaxe qui vient de SGML, c'est donc bel est bien possible en HTML (qui marche sur du SGML). Pour confirmation pour ceux qui doutent j'en ai mis quelques uns dans un code HTML et il a tout à fait passé le validateur. Le SGML est bien plus complet et complexe que ce qu'il n'y parait avec le HTML. Pour faire un résumé : le XML est une simplification du SGML, presque tout ce qui y existe existait déjà en SGML (souvent de manière plus complète). La seule exception importante que je vois c'est le mécanisme d'espace de nom.

Poursuivre un stagiaire parce qu'il ne va pas assez vite ? le jour où ça arrive il sera temps de faire la révolution tout de même, parce qu'il y aura un gros problème dans notre système.

tant qu'il y a un lien pour suivre les discussions, moi vous pouvez bien me placer où vous voulez (en restant dans des limites décentes )

Tiens, d'ailleurs pour couper court à tout doute, je cite le lien que tu m'as donné (l'emphase est de moi): Je rajoute aussi que c'est applicable pour les logiciels, et qu'un site Web propose une grosse partie graphique et créative qui n'est pas concernée du tout même si c'est rattaché au logiciel (c'est aussi explicitement marqué dans le texte que tu as lié) :

Justement, Pitchoune nous a dit qu'elle était stagiaire rémunérée. Un stagiaire n'est pas un salarié, il n'a pas les mêmes droits et les mêmes devoir qu'un salarié. Ce qu'il perçoit est une indemnité et pas un salaire, il n'y a pas les mêmes charges ni les mêmes implications au niveau du paiement. Dans ta citation le mot clé c'est "par un salarié", et ... un stagiaire n'est pas considéré comme un salarié (c'est assez étrange d'ailleurs car légalement un stagaire qui travaille 6 mois dans une entreprise n'a aucun jour de vacance ou de RTT, alors qu'il est généralement tenu aux mêmes horaires). D'un point de vue légal c'est un étudiant en apprentissage dans l'entreprise. L'essentiel de ce que contient le code du travail ne s'applique pas à lui. Le stagiaire c'est un peu l'esclave moderne, la seule chose qu'il a pour lui c'est justement le fait que ses créations lui appartiennent. Quand c'est un "travail basique" ce n'est pas gênant, mais si c'est facile de l'appeler une "création", alors c'est beaucoup plus risqué pour l'entreprise. Or un site Web tombe très facilement dans cette seconde catégorie pour monsieur tout le monde (donc un juge aussi).

Bof Pitchoune, franchement c'est pas fait pour te remonter le moral. Je te conseille fortement d'aller trouver ton patron pour lui dire "non, ça ne peut pas aller comme ça", et obtenir soit qu'il te paye les licences soit que tu utilises des logiciels gratuits. D'ailleurs on voit bien qu'il n'est pas très au fait de la législation ton patron, parce que faire faire un site par un stagiaire c'est un peu suicidaire. Je rappelle que quand on est salarié c'est l'entreprise qui a les droits sur la création, quand on est stagiaire c'est le stagiaire qui détient les droits d'auteurs. Faire faire un site par le stagiaire c'est faire en sorte que le stagiaire puisse réclamer des sous à *chaque* changement d'un détail du site ou d'une réutilisation de la charte ailleurs que dans le site (courrier, mail ...).

À vérifier mais je crois bien que c'est le contraire. Tout ce qui est fait dans le cadre du travail pour l'entreprise est sous la responsabilité de l'entreprise. Un salarié qui installe un logiciel sans licence sur son poste, même si personne n'est au courant, c'est la société qui est responsable devant la loi puisque l'employé "est" l'entreprise pendant son travail (l'employé n'étant responsable que devant l'entreprise). Le fait que l'employé utilise son propre matériel n'est à mon avis pas une possibilité pour l'employeur de se déresponsabiliser. (ceci dit si l'employé utilise aussi ses logiciels pour lui, il est aussi condamnable de son coté) J'aurai même tendance à croire le contraire : même si l'employé a une licence, c'est le particulier qui l'a, pas l'entreprise, donc en travaillant pour l'entreprise avec il y a bien contrefaçon (une licence est utilisée pour deux personnes : le particulier et l'entreprise, ça fait une de trop). J'irai même encore plus loin car un employeur qui fait ramener son propre matériel par l'employé risque probablement de tomber sur des points litigieux dans le droit du travail.

Reste que ça pose problème. Un don est en France très fortement taxé (c'est quelque chose comme 60%). Il risque donc de voir débarquer les impôts, pour une évaluation du prix théorique du site (ça peut être évalué à cher si on considère que c'est un outil professionnel) et de se retrouver redevable de 60% de cette somme pour les impôts. À méditer À mon avis le plus simple est que au contraire tu lui facture pas cher le produit fini (quitte à ce qu'il ne te paye pas), et que tu déclares le montant sur tes impots. Ceci dit ... amha c'est quelqu'un qui cherche à te faire peur et tu peux ignorer ce genre de menaces

Je sais que c'est à la mode mais .. en quoi cacher serait mieux ? surtout que ça ne cache pas vraiment, ça masque on devrait dire. Celui qui veut lire les informations peut les avoir, celui qui veut modifier les informations peut le faire. À l'origine il y a pas mal de méthodes en HTTP : GET / POST / DELETE / PUT et quelques trucs du genre. * GET est pour aller chercher une ressource, éventuellement avec quelques paramètres. C'est le cas dans google : tu vas chercher la liste des pages qui correspondent à un mot clé précis. * POST c'est pour envoyer des informations à une ressources. Classiquement c'est ce que tu fais ici en remplissant un message, tu ajoutes un commentaires à la ressource du forum. Les gens utilisent tout n'importe comment et ça fait longtemps que plus grand monde ne fait attention aux sens réels mais il y a une réelle raison et une philosophie réelle. Cette philosophie a d'autres impacts. L'impact le plus important c'est la gestion du cache : * quand tu vas chercher une requête (GET), tu passes à la page suivante, rien ne t'empêche de revenir sur tes pas et revenir chercher la même information que précédement. Il est même possible que ton navigateur l'ai retenue et n'ai pas à aller la rechercher * quand tu envoies une information (POST), tu modifies la ressource. Ton navigateur a donc un problème, il ne peut pas te renvoyer la même ressource à partir du cache (elle ne sera pas à jour) et ne peut pas rejouer la requête (sinon il va modifier deux fois la ressource) ... il ne s'en sort pas et te demandera (via une popup) ce qu'il doit faire.

Ce qui n'est nullement interdit. Pourquoi déloyale ? parce que tu n'es pas dans leur société ? Je remarque juste qu'ils attaquent sur la contrefaçon de droit d'auteur (code de la propriété intellectuelle) et qu'ils reprochent une concurrence déloyale (code du commerce), ce qui n'a rien à voir. S'ils ne citent rien qui parle de concurence déloyale c'est que ce que tu fais est tout à fait légal (à priori). Rien ne t'interdit en tant que personne de parler et de communiquer autour d'une maladie. Ils n'ont en rien le monopole sur ce genre d'information. Concernant ton premier site : oublies. Ce n'est certainement pas pour ça qu'on te recontacte aujourd'hui. Tu as tout à perdre à remettre l'histoire sur le tapis. Ils ne la connaissent probablement même pas mais n'hésiteront pas à s'en servir pour te faire peur si tu les informes. Quoi que tu aies pu faire avant, si ton site a du contenu légal actuellement, il ne peuvent t'obliger à rien du tout. Tant que ton contenu est à toi (un contenu "à toi" ça peut aussi être une synthèse de tes lectures ou une vulgarisation, ça n'est pas forcément une invention) tu n'as rien à te reprocher. Ne cèdes pas (même si je sais que c'est plus facile à dire quand ce sont les autres qui sont dans cette situation). C'est d'autant plus important pour des informations "nobles" comme sur les maladies. Il est hors de question moralement d'accepter qu'une société puisse avoir le monopole d'information sur ce genre de choses. Tant qu'ils ne te reprochent pas quelque chose qui est effectivement illégal, ne te laisse pas faire. Là ils essayent de t'embrouiller en citant des droits d'auteurs alors qu'ils te reprochent de la concurrence déloyale. Malheureusement visiblement ça marche puisque tu ressors une vieille histoire qui ne pouvait probablement pas t'être vraiment reprochée vu la façon dont tu as corrigé le tir. Oublie le passé, et parles uniquement tu présent. Tu n'as rien à gagner à enlever tout le contenu présent à cause d'une erreur passée qui a été corrigée en toute bonne foi (et n'a probablement rien à voir avec l'histoire).

Si tu bosses bénévolement pour fournirun service à un professionnel, ne t'étonnes pas que tout le monde croit que tu n'as en fait pas été bénévole et que tu as été payé au black. Vrai ou pas tu risques effectivement que les impots ne te croient pas. De toutes façons c'est à la limite légal du coté de l'entreprise (vu que ça veut dire qu'ils t'ont payé moins que le smic sur ce travail et qu'ils ne t'ont même pas déclarés). Ceci dit, toi je vois mal ce que tu risques si *réellement* tu n'as pas touché d'argent (le tout c'est que ça va être difficile à faire croire, vrai ou pas). Ce qui est sûr c'est que personne n'a le droit de vérifier quoi que ce soit chez toi si tu ne dis pas oui. Seul un officier de la police judiciaire a le droit de fouiller chez toi, et encore : il te présentera un joli papier pour ça et il aura l'obligation d'avoir une très bonne raison pour le faire. Si quelqu'un dit vouloir vérifier tes licences fermes lui la porte au nez. Je ne cautionne pas le piratage de logiciel mais il ne faut pas pour autant tout autoriser. Même les gens de BSA qui sont assermentés n'ont pas le droit de venir chez toi si tu le nes invite pas.

Je me permet de corriger une chose : Sauf erreur de ma part, théoriquement, le commentaire est faux en HTML 4 / SGML aussi (pas que en XML). Oui c'est valide, mais ça revient tout simplement à ignorer tout le contenu, donc normalement le script js n'est pas interprêté. De manière plus concrête ça interdit aussi d'avoir une suite de deux tirets consécutifs dans le code (donc pas de décrémentation). Le CDATA est lui bien valide en HTML comme en XML, avec les // il ne posera problème sur aucun navigateur, même les plus sensibles. De toutes façons je crois m'accorder avec ceux qui veulent mettre le js en externe. Pas pour une quelconque séparation (que ce soit dans le même fichier ou pas ne m'empêche nullement d'avoir une séparation des couches au niveau logique) mais plus parce que c'est tout de même bien pratique et plus agréable.

Les lois sont disponnibles sur http://legifrance.gouv.fr/ Cliquer ensuite sur "Codes", sélectionner celui de la PI, puis taper le numéro sous la forme L125-5 Certes pour les interprétations il faut mieux connaitre le sujet mais les textes ne sont pas innaccessibles contrairement à ce qu'on veut nous faire croire. Pour ce qu'on te demande : Si tu ne fais qu'un lien mais aucune reproduction de contenu cet article est totalement hors sujet. Je doute aussi que tu puisses être qualifiée de producteur ou d'éditeur sur leur contenu. Sauf si tu te place en tant que diffuseur de leur contenu (au même titre qu'un éditeur, qu'une chaine de TV, qu'une troupe de théatre), je vois mal comment ça pourrait avoir à faire avec ton site. Le Article L131-3 quant à lui se contente de dire que si accord il y a, il doit être par écrit et explicite. Mais bon, comme tu ne tombe pas sous les deux premiers, il n'y a pas d'accord à avoir donc cet article est hors sujet aussi. Donc grosso modo, si tu n'utilise aucun de leur contenu (aucun de leur logo non plus), les articles cités sont totalement hors sujet. Si tu cites un peu de leur contenu ET que tu met un lien vers le texte complet, tu tombes probablement sous le droit de citation (Article L122-5) qui dit clairement : Ce qui est encore plus certain c'est que même si tu avais du contenu à eux qui dépasse la citation à caractère informationnel ou critique, en l'enlevant ils ne peuvent pas exiger que tu te déréférences des annuaire ou retires tes pages. Surtout sur des sujets de ce type, ne recules pas. Si tu veux éviter le conflit tu peux leur renvoyer un mail avec : - le fait que de manière temporaire et en attendant éclaircissement tu as retiré les contenus - la déclaration en quoi tu n'es pas concernée par les articles de lois cités et tu demandes plus d'information sur ce qui t'es reproché (le cas échéant tu peux aussi citer le L122-5 si tu penses qu'il s'applique à ton cas) - une demande informelle pour savoir ce qui les gêne plus exactement dans ton contenu et tes liens, et pourquoi - une demande d'autorisation pour publier les échanges suivants sur une ressource de conseil juridique (histoire de leur montrer que tu sauras te faire conseiller et que donc qu'ils ne pourront pas t'abuser, si tu cherches une telle ressources tu as fr.misc.droit.internet sur usenet) - le fait que sans réponse de leur part sous un délai raisonnable tu considèrera qu'il s'agit bien d'une erreur d'apréciation de leur part et que tu remettra en ligne tes contenus (oui, c'est un peu hypocrite de dire que tu crois à une erreur, mais c'est un peu plus diplomatique ) Et ... tu met en copie non cachée (et en l'annoncant dans le corps du mail) une ou deux personne "de bonne foi" de ta connaissance histoire de renforcer la trace que peux avoir ton mail (le fait qu'ils pourront plus difficilement faire semblant de ne pas avoir reçu le mail). Sans réponse sous un mois je te propose de remettre ton contenu en ligne. S'ils répondent je suis intéressé par la suite mais je te propose de demander conseil sur fr.misc.droits.internet

Je confirme Dan. Pour simplifier la vie de l'utilisateur (sic), PHP repère les entêtes "Location" et passe tout seul le code de retour HTTP à 302. Pour mettre un 301 il faut le définir après. Sinon je déconseille très fortement l'utilisation des "status:". Suivant qu'on est en CGI ou en module ça marchera ou ne marchera pas. Pour ceux qui sont sous PHP 4.3.0 et supérieur je conseille plutot ce qui suit : header("Moved blabla", true, 301); Le moteur utilisera tout seul la bonne méthode pour renvoyer le code HTTP suivant la manière dont il fonctionne.

Je te propose ce que j'ai pu faire sur C² et D4N comme articles. Ca devrait te donner toutes les bases pour faire des popup et résoudre ton problème : http://blog.dreams4net.com/PopupEtPolemiques http://cybercodeur.net/weblog/articles/art_20041030.php Aucune difficulté, c'est un lien classique, il peut mener à n'importe quel type de page, avec ou sans paramètres.

Je crois que les 80% révèlent toujours le même problème qu'il faut bien toujours penser. Si on peut dire que 80% des gens ont Windows, que 80% des gens acceptent les cookies, que 80% des gens lisent correctement des polices à 12px, que 80% des gens ont une bonne vision du contraste (je pense à ton site commmit), que 80% des gens ont les polices courantes, que 80% ont un écran de taille 15" au moins ... On ne peut par contre pas dire que 80% des gens ont Windows ET acceptent les cookies ET lisent correctement les polices à 12px ET ont une bonne vision du contraste ET ont les polices courantes ET ont un écran de 15" au moins. La vérité c'est que personne ne ressemble à "monsieur tout le monde". Chacun a sa propre spécificité qui ne correspond pas à monsieur tout le monde. Ce qui fait que si on exclu tous les gens qui ne sont pas dans les 80% on en revient à exclure la bonne majorité des gens (qui tomberont dans une ou une autre des exclusions). Viser les 80% c'est se baser sur un très mauvais calcul statistique. Reste aussi le second problème de la logique 80%. Avant-hier 80% des gens étaient sous Netscape, on faisait des sites propriétaires NS4, en excluant IE. Sauf que ça a changé, hier on a fait le contraire, on a exclu NS et fait du propriétaire IE parce que 80% sont sous IE, il a fallu tout refaire et se retrouver avec des sites obsolètes. Aujourd'hui on a une percée de Firefox à plus de 10%, voilà que ce qui était vrai hier pour IE est en passe de devenir faux et il faudra encore tout refaire. Qu'en sera t-il demain ? est-il vraiment pertinent de se baser sur nos 80% ? Combien d'entreprises sont emm* parce que leur intranet et leurs applis sont IE-only et que ça les empêche de virer IE actuellement ? Là je parle de navigateurs mais on peut parler de noms de police, de taille d'écran, de qualité d'écran pour la lecture à l'écran, ou de capacité moyenne de lecture pour les gens (lunettes de plus en plus nécessaires), d'age moyen des lecteurs (baisse de vision) ... ça donne à penser, non ? Quand au concept de cible, j'ai trop vu de sites se planter en ayant une cible qui ne correspond pas du tout à leurs visiteurs réels pour penser que ça n'est pas un bon critère. Et même si la cible est bien étudiée, est-ce une bonne justification pour jeter ceux qui ne sont pas dans la cible prévu et qui sont intéressés ? La cible c'est fait pour centrer les choix (quel contenu ? quelle présentation ?), pas pour s'autoriser une quelconque contrainte d'accessibilité. Il faut certes faire des choix. L'accessibilité est un but à atteindre donc il restera toujours des problèmes. Des fois on peut dire "non, ca coute trop cher" (en argent, en temps ou en renoncements sur le cahier des charges), mais il ne faut surtout pas le die trop vite. C'est d'autant plus vrai sur les sujets où l'accessibilité est primordiale : le nombre de gens lisant mal à l'écran ou ayant un écran petit / de mauvaise qualité est très important.

Pour prendre les choses depuis le début (parce que des fois avoir le contexte peut aider à comprendre) : 1. Quand on fait une requête SQL, les délimiteurs de chaînes de caractères sont des apostrophes. Pour utiliser une chaîne qui contient une apostrophe dans une requête SQL il faut l'échapper. L'échapper c'est à dire la mettre sous une forme reconnue par le serveur de base de données. C'est généralement soit en la précédant d'un backslash (\') soit en la doublant (''). Cet échappement est "mangé" par le serveur de base de données, il n'est donc pas nécessaire de l'enlever quand on récupère la donnée qu'on y avait inséré. Si on l'oublie toutes les chaînes qui contiennent des apostrophes feront des requêtes SQL qui posent problème (soit qui échouent, soit qui font un problème de sécurité) Sous PHP la fonction qui permet de rajouter des backslash est addslashes(). Il existe une fonction qui fait l'opération inverse nommée stripslashes(). 2. Au début de PHP les développeurs de PHP ont pensé qu'il serait une bonne idée de faciliter la vie de l'utilisateur en faisant automatiquement ces addslashes, comme ça il ne risque pas d'oublier. Il y a donc une directive de configuration dans le php.ini qui s'appelle "magic_quotes_gpc". Quand elle est activé (ce qui était le cas par défaut et chez quasiment tous les hébergeurs) PHP fait un addslashes sur tout ce qu'il récupère venant de l'utilisateur (formulaires, cookies, valeurs dans l'URL). Ce que tu vois c'est simplement cette directive en action. - Tu rentres : l'exemple. PHP réceptionne et ajoute les slash, ton script reçoit : l\'exemple. - Ton script affiche ce qu'il a reçu : l\'exemple. Tu valides donc tu renvoies cette chaîne. PHP la reçoit a nouveau, il va rajouter un slash devant chaque slash et chaque apostrophe. Ton script va donc recevoir l\\\'exemple et te l'afficher. 3. Le problème arrive donc comme c'est que les deux postulats fait au (2) est faux. - Toutes les données ne sont pas destinées à passer en SGBD. La plupart sont même faites pour être réaffichées directement pour confirmation validation, ou traitées par code avant insertion. Au lieu d'oublier de faire des addslashes on oublie de faire des stripslashes là où le addslashes fait par défaut était inutile/mauvais. - Toutes les données ne viennent pas de l'utilisateur. C'est le plus gros problème de ce fonctionnement. On va devoir savoir si une chaîne vient de formulaire, de fichier, de base ou d'ailleurs pour savoir comment la traiter (savoir si elle a déjà eu un addslashes ou pas). Au lieu de simplifier on complexifie grandement. Du coup maintenant la politique c'est de désactiver le magic_quotes_gpc dans la configuration. C'est ce qui est fait dans la config par défaut des dernières versions de PHP. Le problème qui survient est que du coup on ne sait pas toujours dans quelle configuration on est. Il y a donc la fonction get_magic_quotes_gpc() qui retourne true ou false suivant qu'elle est activée ou pas. Je vous propose donc 2x3 solutions au choix (par ordre de préférence) : ** En prenant pour base le fait de ne pas faire un addslashes automatique (conseillé) A- Tu changes la configuration de ton serveur pour mettre magic_quotes à Off (c'est la valeur conseillée et par défaut sur toutes les versions récentes de PHP) et tu n'oublies pas de faire un addslashes() ou un mysql_real_escape_string() à chaque fois que tu met une chaîne de caractère dans une requête SQL. B- Tu n'as pas la main sur la configuration ou tu veux un script portable. Tu fais donc comme au A mais tu exécutes le code suivant à chaque début de page pour "corriger" PHP si jamais la directive de configuration était activée : function recursiveStripSlashes($a) { if (is_array($a)) { foreach($a as $name => $value) { $a[$name] = recursiveStripSlashes($value); } } else { $a = stripslashes($a); } return $a; } if (get_magic_quotes_gpc()) { $_REQUEST = recursiveStripSlashes($_REQUEST); $_GET = $HTTP_GET_VARS = recursiveStripSlashes($_GET); $_COOKIE = $HTTP_COOKIE_VARS = recursiveStripSlashes($_COOKIE); $_POST = $HTTP_POST_VARS = recursiveStripSlashes($_POST); } C- Tu fais comme A mais à chaque fois que tu utilises une donnée de REQUEST/POST/GET/COOKIE tu la fais passer à la main dans la fonction correctStripSlashes() suivante : function correctStripSlashes($a) { if (get_magic_quotes_gpc()) $a = recursiveStripSlashes($a); return $a; } function recursiveStripSlashes($a) { if (is_array($a)) { foreach($a as $name => $value) { $a[$name] = recursiveStripSlashes($value); } } else { $a = stripslashes($a); } return $a; } *** Les mêmes dans le sens inverse (déconseillé) : A- Tu changes la configuration de ton serveur pour mettre magic_quotes à On (c'est la valeur conseillée et par défaut sur toutes les versions récentes de PHP) et tu n'oublies pas de faire un stripslashes() à chaque fois que tu met une chaîne de caractère qui vient de l'utilisateur ailleurs que dans une requête SQL. B- Tu n'as pas la main sur la configuration ou tu veux un script portable. Tu fais donc comme au A mais tu exécutes le code suivant à chaque début de page pour "corriger" PHP si jamais la directive de configuration était activée : function recursiveAddSlashes($a) { if (is_array($a)) { foreach($a as $name => $value) { $a[$name] = recursiveAddSlashes($value); } } else { $a = addslashes($a); } return $a; } if (!get_magic_quotes_gpc()) { $_REQUEST = recursiveAddSlashes($_REQUEST); $_GET = $HTTP_GET_VARS = recursiveAddSlashes($_GET); $_COOKIE = $HTTP_COOKIE_VARS = recursiveAddSlashes($_COOKIE); $_POST = $HTTP_POST_VARS = recursiveAddSlashes($_POST); } C- Tu fais comme A mais à chaque fois que tu utilises une donnée de REQUEST/POST/GET/COOKIE tu la fais passer à la main dans la fonction correctAddSlashes() suivante : function correctAddSlashes($a) { if (!get_magic_quotes_gpc()) $a = recursiveAddSlashes($a); return $a; } function recursiveAddSlashes($a) { if (is_array($a)) { foreach($a as $name => $value) { $a[$name] = recursiveStripSlashes($value); } } else { $a = stripslashes($a); } return $a; }