jcaron

T'as loupé un épisode. session.cookie_domain=.monsite.fr (pas de *), et ça devrait le faire tout seul, pas la peine de se prendre la tête plus que ça. Je me trompe? Jacques.

Une bonne solution consiste à ajouter des espaces sécables de largeur nulle (ZWSP, U+200B, cf http://www.fileformat.info/info/unicode/char/200b/index.htm), au minimum après chaque /, ? ou & (pour le cas des URLs). Ca permet au navigateur de "couper" ton URL en renvoyant à la ligne quand c'est nécessaire, sans pour autant affecter le formatage ailleurs. Sinon tu peux "reconnaître" les URLs et les remplacer par un lien vers l'URL en question et un texte bidon genre "link" ou "url" à la place. Jacques.

Tu es sûr que c'est disponible pour la France? Si c'est le cas c'est récent, la dernière fois que j'avais regardé ce type de fonctionnalité n'était disponible que pour les US et UK je crois... Sinon il y a des exemples de code PHP ici: https://www.paypal-france.fr/webscr/fr_FR/h...Pal/ic_nvp.html (pour nvp) et là: https://www.paypal-france.fr/webscr/fr_FR/h...k-resource.html (pour soap) Je ne les ai pas regardés, ceci dit. Et surtout: - respecte les règles en termes de ce que tu conserves ou pas (par exemple il est interdit de conserver le CVC2/CVV2) - à partir du moment où tu traites toi-même des données CB du devrais normalement obtenir une certification PCI DSS niveau 1 (voir par exemple http://www.mcafeesecure.com/us/pci-intro.jsp) Jacques.

src="[^"]*" [^"] signifie 'n'importe quel caractère sauf "'. J'ajoute que pour du HTML, l'utilisation de regexps est toujours risqué, le HTML étant souvent mal formé (et souvent plus complexe qu'on ne le pense à première vue). Par exemple certains utilisent des ' et pas des " pour les attributs, voire ne mettent pas de guillements du tout... Il ne faut pas oublier non plus que l'ordre des attributs peut être variable (img src=xxx ou img class=xxx src=xxx par exemple), que src=xxx est un attribut d'autres éléments (iframe...), etc. Un "vrai" parser HTML est recommandé (mais je ne sais pas s'il y en a un en PHP? En perl il y a HTML::Parser et ses dérivés). Jacques. edit: minor edit

Plus que la taille de l'écran, c'est sa résolution qui compte. Moi je travaille sur un "simple" 15.4" (celui de mon portable), mais il est en 1920x1200, c'est quand même autre chose que les résolutions "classiques" genre 1280x960 ou 1440xjesaispascombien. Après évidemment suivant ton acuité visuelle ça peut être plus ou moins utile... Jacques.

Ben il y a probablement un CNAME, qui est une sorte d'alias, qui pointe vers un autre nom de domaine. Si ce dernier nom de domaine est modifié pour pointer sur la nouvelle adresse, il n'y a effectivement pas besoin de changer le premier. Jacques.

J'ai pas tout suivi, mais si tu veux que ce soit le browser de l'utilisateur qui fasse ce POST, la seule soution c'est une page HTML qui contient le formulaire avec toutes les données et un bout de JS pour faire un mon_formulaire.submit(); Si ça n'a pas d'importance que ce soit toi ou l'utilisateur qui fasse ce POST, tu peux le faire depuis ton serveur via curl ou fsockopen. Jacques.

select * from table where colonne regexp '[[:<:]]mot[[:>:]]' http://dev.mysql.com/doc/refman/5.1/en/regexp.html vers la fin Jacques.

Moi et le php ça fait deux, mais je dirais pgrep_replace("/\*\*\* (\w)+ \*\*\*/e","\$tableau_assoc['\\1']",$text); non? Voir http://www.php.net/manual/fr/function.preg-replace.php pour les détails. L'option "e" à la fin de la chaîne à remplacer indique que la chaîne de remplacement sera interprétée comme du code PHP. Sinon ça doit être possible en séparant ton tableau associatif en deux tableaux, l'un avec les clefs (avec les *** autour), l'autre avec les valeurs, et passer les deux tables à pgrep_replace qui va remplacer chaque chaîne qui est dans le premier tableau par la chaîne au même index dans le tableau de destination. Jacques.

Oui, mais c'est l'AG (i.e. toi) qui les approuve. L'avocat (ou plus généralement l'expert-comptable) ne fait que préparer les documents nécessaires à cette AG. De façon générale, c'est normalement ton expert-comptable qui te fournit tout ça (à partir d'un modèle, c'est assez standard), et ça devrait être inclus dans ce que tu lui paies. Vérifie la lettre de mission qui a été convenue au départ, il doit y indiquer ce qu'il fait ou pas. Comme déjà dit par d'autres, tu peux très bien tout faire tout seul: il faut juste des statuts (modèle téléchargeable sur le site de l'APCE par exemple, comme l'essentiel consiste en la répétition de ce qui est fixé en dur par la loi, à part le nom, l'objet, le capital, les associés et leurs apports et parts je ne crois pas qu'il y ait grand chose à modifier), faire une annonce légale, et remplir quelques formulaires à déposer au CFE (avec le justificatif de domiciliation et de dépôt des fonds). En tout ça coûte quelques centaines d'euros. Le recours à un avocat ou un EC te permet de te décharger de tout ça (ce qui n'est pas forcément une mauvaise idée: ils ont plus l'habitude de le faire donc ça peut être plus efficace que de se documenter soi-même, trouver les formulaires, les démarches à faire, etc.), mais ce n'est absolument pas obligatoire. Ceci dit ça ne vaut pas la création d'une sociéte en UK: tu peux le faire en ligne pour £30! :-) Jacques.

Ben justement si, je pense que tu peux utiliser une carte à puce pour stocker un certificat non copiable, le tout utilisable dans (au moins) IE. Jamais essayé, mais c'est prévu pour. Il y a un peu de doc dans IE (Options -> Internet -> Contenu -> Certificats -> En savoir plus sur les certificats), sinon je pense qu'il faut aller voir sur MSDN pour avoir plus de détails. Jacques.

umask? Ou faire en sorte que le dossier appartienne à celui qui va créer des fichiers/dossiers dedans... Jacques.

http://www.fileformat.info/info/unicode/char/2011/index.htm Jacques.

Je dirais que ton CVS essaie de convertir les fichiers texte entre Unix et Windows en remplaçant les LF par des CRLF (et vice-versa). Il faudrait lui dire de ne pas le faire, au moins pour ces fichiers (en lui disant que ce sont des fichiers binaires), sinon pour tout le monde (mais suivant l'éditeur que tu utilises côté Windows tu risques d'avoir des soucis avec les fichiers texte). Moi j'utilise le cvs "classique" en ligne de commande fourni avec Cygwin et je n'ai pas le souvenir d'avoir jamais eu ce genre de soucis, mais il faut dire qu'après j'utilise vi donc ça ne me gêne pas :-) Jacques.

Je pense que ton copier-coller a perdu non seulement les tabs mais aussi certains retours-chariots, donc difficile de trouver la ligne 235 à coup sûr, mais j'ai tendance à penser que c'est là: open(FILE, "uuencode $out_file[$i] $n_file|" ) or die; Bref, il ne doit pas trouver uuencode. Tu peux remplacer le die par die "pas pu lancer uuencode: $!" qui te donnera un message d'erreur plus explicite. Ceci dit c'est un peu vielliot uuencode, MIME serait quand même nettement plus adapté. Jacques.

C'est justement le but d'une connexion ssh que d'être "sûre" quel que soit le réseau par lequel on passe. Mais de quoi cherches-tu à te protéger, en fait? Jacques.

Il s'agit de l'entrée en vigueur du "liability shift" lié à 3D-Secure (Verified by Visa / Mastercard Securecode) pour les transactions nationales en France le 1er octobre 2008 (3D-Secure existe depuis longtemps, mais n'était pas applicable pour les transactions passant par le réseau "CB" français, par opposition à ce qui passe par les réseaux Visa ou Mastercard). A partir du moment où le commerçant (ou son prestataire technique) tente de faire une vérification 3D-Secure pour une transaction, la responsabilité incombera à la banque (du porteur), même si la banque (du porteur) n'a pas implémenté 3D-Secure. Ce qui devrait les pousser à le faire très vite. Si le commerçant, sa passerelle ou sa banque n'ont pas implémenté 3D-Secure (dans certains cas ça va être une option payante), on reste sur le même principe qu'avant. Quatre cas de figure: - le commerçant ne fait pas de vérification 3D-Secure: comme avant, il est responsable en cas de répudiation - le commerçant tente une vérification 3D-Secure, mais la banque (du porteur) dit "je ne sais pas faire": elle est responsable (à condition que la transaction soit autorisée, bien entendu) - le commerçant tente une vérification 3D-Secure, elle se fait (entre le client et la banque directement) et est validée: la banque est responsable (toujours à condition que la transaction soit autorisée) - le commerçant tente une vérification 3D-Secure, elle se fait, mais elle échoue: il vaut mieux ne pas continuer :-) Pas mal d'infos ici: http://oliverblog.wordpress.com/2008/07/20...d-secure-enfin/ Mais il est vrai que les banques et les autres acteurs (GIE CB...) ont très peu communiqué sur tout ça (voire pas du tout?), et que beaucoup d'utilisateurs risquent d'être un peu surpris qu'on leur demande un nouveau code (même si beaucoup de banques ont choisi, de façon pour le moins hasardeuse, d'utiliser la date de naissance plutôt que de fournir un nouveau code). Jacques.

Salut, Sauf erreur, HTTP request too long ça veut normalement dire que l'URL est trop longue (mais ça devrait être un erreur 414, pas 500). Tu ne dois la voir que dans ce cas que parce qu'il doit y avoir un proxy transparent qui a un réglage d'URL max plus petit que ton serveur. Si c'est effectivement ça, en général ça vient de l'utilisation d'un form avec trop de variables ou des variables trop longues (par exemple un textarea...). Dans ce cas il convient d'utiliser un POST plutôt qu'un GET (qui sera de toutes façons probablement plus juste sémantiquement). Sinon il faut chercher les URLs un peu longues et les raccourcir d'une façon ou d'une autre. EDIT: par contre je n'ai aucune idée de pourquoi ça marcherait avec les echo en plus ou pas. C'est peut-être le signe que le message d'erreur n'a rien à voir. Il faudrait d'ailleurs déjà déterminer (en regardant les logs) si c'est ton serveur web qui se plaint ou quelque chose sur le chemin (proxy transparent etc.). Jacques.

Il n'y a pas photo, un Quad Core c'est clairement mieux qu'un Dual Core. Mais la vraie question c'est plutôt: en as-tu besoin, et n'y a-t-il pas d'autres choses qui seraient plus importantes? Ou, posé autrement, qu'est-ce-que tu satures à l'heure actuelle? Si tu satures au niveau CPU, alors oui, il vaut mieux avoir le plus grand nombre de cores possible. Si par contre c'est plutôt au niveau des accès disque, il vaut probablement mieux avoir plus de RAM et/ou des disques plus performants ou plus nombreux. Il est temps de regarder un peu ce que dit ta machine actuelle (voir les graphes d'utilisation de CPU et d'accès disque en particulier). Pour certaines applications, un seul core avec 4 Go de RAM sera nettement plus intéressant que 4 cores avec 1 Go, par exemple... Pour d'autres ce sera l'inverse. Et pour d'autres encore il faut les deux, voire plus :-) Jacques.

Je pense que ça reste très minoritaire, et bien entendu il faut laisser le choix à l'utilisateur de pouvoir changer de langue (et stocker ça dans un cookie par exemple). C'est l'un des autres intérêts de le faire en PHP (ou autre language) plutôt que de laisser Apache le faire. Jacques.

En PHP, tu peux tester le contenu de la variable d'environnement HTTP_ACCEPT_LANGUAGE (qui correspond au header Accept-Language envoyé par le browser). Voir RFC2616 pour le détail du contenu du header. Jacques.

Lis un peu la doc qu'on te propose... La distance Levenshtein est le nombre d'opérations qu'il faut effectuer pour passer d'un mot à l'autre. C'est pour ça que 0 = les mots sont identiques (il n'y a aucune opération à effectuer). Dans le pire des cas, je pense que la distance max va être la longueur de la plus grande des deux chaînes (on remplace toutes les lettres de la chaîne la plus courte, et on ajoute toutes les lettres manquantes). Le reste est trivial. D'ailleurs il y a même un exemple dans la page en question qui fait tout ça... Jacques.

http://login:password_AT_site/chemin "_AT_" étant en fait "@", hein. Note que: 1. Le login et le mot de passe seront donc passés en clair et visibles dans le source de la page, l'URL, etc. 2. Certains navigateurs vont faire un avertissement genre "vous allez vous connecter sur une adresse qui contient un login/password, voulez-vous continuer" Tu peux aussi ne passer que le login sans le password. De façon plus générale, je ne suis pas sûr que ce soit la bonne méthode, si tu utilises une authentification formulaire (et cookies, donc, je suppose), il serait légitime de continuer à faire la même chose partout plutôt que de bascuelr sur une authentification par auth HTTP... Jacques.

Dans un header Location l'URL doit être absolue (y compris http://nomdesite/ etc.). Ceci dit, ce n'est probablement pas ça le problème, tu dois avoir quelque part des liens relatifs incorrects (i.e. qui commencent par "quake2/") à mon avis. Jacques.

C'est permanent ou ponctuel? C'est général (y compris pour un fichier statique) ou spécifique aux pages dynamiques avec des requêtes SQL? Pour commencer, tu peux regarder: - du côté de l'utilisation des disques - du côté d'un problème de lookups DNS (surtout si tu as un lookup des reverses activé) - du côté d'une saturation du nombre de connexions simultanées Apache Jacques.