jcaron

Je pense que c'est une mauvaise formulation de leur part... Ca marche très bien dans tous les cas, même si c'est probablement "encore plus" utile dans le cas des paiements différés (chèques, virements...). Si tu as besoin de savoir si un paiement a abouti ou pas, que le client revienne sur ton site ou pas, tu dois utiliser IPN, c'est le seul moyen fiable de savoir si un paiement a été traité. Ceci dit, dans un cas comme dans l'autre, tu peux effectivement passer tout un tas d'information complémentaires dans ton formulaire, et elles te seront retransmises par IPN et lors du retour. Pour le retour, voir pages 43-45 et 111 et suivantes de ce document: https://www.paypalobjects.com/WEBSCR-570-20...rationGuide.pdf Pour IPN, voir pages 111 et suivantes, et il y a une doc spécifique ici: https://www.paypalobjects.com/WEBSCR-570-20...rationGuide.pdf L'avantage d'IPN est d'ailleurs bien exposé page 16 de ce document. Jacques.

Beaucoup mieux que le retour (que les utilisateurs ne font pas toujours), utilise IPN. https://www.paypal.com/fr/cgi-bin/webscr?cm...pn-info-outside Tu peux dans le formulaire de ton bouton passer des infos qui te seront renvoyées par IPN, ainsi que l'état du paiement et tout plein d'autres choses. Jacques.

Des régies d'affiliation, il y en a plein: Tradedoubler, Commission Junction, Zanox, Netaffiliation, et j'en passe. Par contre je n'ai aucune idée de leurs conditions commerciales respectives. Jacques.

Le moteur utilisé ne traite qu'une seule langue par page, et ignore donc les balises "lang" autres que celle sur le tag HTML (qui ne sert de toutes façons que de "piste", avec le header HTTP Content-Language, la décision réelle étant faite par une analyse du texte lui-même, l'expérience montrant que ces deux éléments en tous cas ne sont pas particulièrement fiables). Jacques.

Je pense que le site en question est un peu buggé, il se vautre la gueule (au moins) sur les entités HTML (genre é), c'est un peu bizarre. Tu peux déjà essayer avec le validateur W3C pour voir, sinon tu peux essayer http://www.oxado.com/bin/checkpage je garantis le bon fonctionnement :-) Jacques.

Tu as vraiment fait un copier-coller (au domaine près) de ce que tu as tapé, ou tu l'as retapé? Il ne pourrait pas y avoir un truc genre d'un côté tu as mis motclefs et l'autre motcles par exemple? Le var_dump($_GET) devrait te donner une piste... Jacques.

Quelles sont donc ces procédures si particulières? Des factures, des paiements, rien de bien original... Jacques.

Ils se sont un peu mis dedans. Les frais de retour sont à la charge du client (c'est d'ailleurs clairement indiqué dans l'extrait du code de la consommation qu'ils publient quelques lignes plus haut), sauf si tu ne leur envoies pas le produit commandé mais un autre (théoriquement équivalent) à la place. Le plus simple c'est quand même d'aller lire le texte du code de la consommation sur Legifrance, tu auras la version officielle... Jacques.

create table nouveau_nom as select liste_colonnes,colonne_a_dupliquer as nouvelle colonne from ancienne_table; Non? Jacques.

Oui, en général on met un timeout. En plus de ça, suivant l'implémentation choisie, tu peux faire des cookies "de session", qui disparaissent si l'utilisateur ferme son navigateur. Jacques.

Tu veux le savoir pendant que tu affiches une page, ou tu veux sauvegarder l'information? Quoi qu'il arrive, ça va tourner autour de session_start(), du stockage de l'heure de début de la connexion sans un variable $_SESSION[quelquechose] (i.e. tu stockes l'heure courante si la variable est vide, sinon ça veut dire que la session est déjà en cours). Dans le deuxième cas, il faudra aussi stocker l'information dans une base en plus. Evidemment il faut correctement régler les paramètres de timeout de session. Alternativement tu peux utiliser des cookies directement (ce que session_start et $_SESSION font pour toi, en fait). Jacques.

Le code APE choisi par je ne sais pas très bien qui, c'est un peu le loto... Ceci dit, à part pour des stats à la fiabilité toute relative, je ne sais pas très bien à quoi ça sert, et je n'ai pas l'impression que ça ait la moindre influence sur quoi que ce soit. Je me trompe? Jacques.

A priori ce n'est pas un problème DNS, une vérification exhaustive ne relève pas de problème. Et je pense que le message d'erreur doit être plus complet que ça, IE peut dire ça pour tout un tas d'erreurs différentes à ma connaissance, y compris avec certains problèmes de JS qui font des choses qu'IE n'aime pas. Ce serait aussi utile d'avoir la version exacte d'IE. Je suppose qu'au même moment le serveur est parfaitement joignable par d'autres personnes? Dans ce cas ça peut être un problème de connectivité intermittent (ping donne bien l'adresse, mais indique-t-il que les paquets passent?). Sinon essaie d'avoir l'adresse IP de l'utilisateur, et vérifie les logs de connexion (httpd-access.log) pour voir si la connexion est arrivée jusqu'au serveur ou pas. Suivant le cas c'est alors soit un problème de connectivité (ou de firewall éventuellement), soit un problème avec le contenu de la page qui ne plait pas à IE. Jacques.

A tous les niveaux, il y a deux problèmes qui peuvent se poser: - le temps que les mises à jour de l'enregistrement soient répercutées sur l'ensemble des serveurs pour la zone concernée - le temps que les informations restent en cache à divers endroits (dans les serveurs DNS utilisés par les utilisateurs, dans les clients DNS, les browsers...). Pour le premier cas, il fut un temps les serveurs secondaires ne récupéraient la zone auprès du primaire qu'à intervalles réguliers (cf valeurs dans SOA), généralement de l'ordre de quelques heures. Maintenant il y a des mécanismes qui permettent au primaire de prévenir les secondaires qu'il y a eu une mise à jour, donc si c'est correctement configuré ça va très vite. Pour le deuxième problème, c'est basé sur le TTL de l'enregistrement concerné (même si, comme je l'ai déjà dit, ils ne sont pas forcément honorés par tout le monde). Si tu veux changer un enregistrement dans ta zone (genre www.monsite.com) alors tu as le contrôle du TTL et ça peut aller vite. Si tu veux changer de serveurs de noms par exemple, c'est plus problématique, parce que les enregistrements correspondants sont les NS dans la zone supérieure (genre com pour monsite.com). Et ces enregistrements sont contrôlés par le registry pour ce TLD, qu imposent des TTL assez élevés. Donc dans ce cas ça peut effectivement prendre un certain temps (voire un temps certain). Les serveurs DNS de ton hébergeur sont informés que le primaire c'est ta machine? Si c'est le cas pas de souci, si tu fais un changement il sera pris en compte. Tu peux faire un test en ajoutant un enregistrement genre toto.monsite.com et en regardant s'il est pris en compte. Si le test ci-dessus fonctionne, pas de souci (n'oublie pas d'incrémenter le serial dans le SOA pour les secondaires voient qu'il y a eu un changement). Avec dig ou nslookup tu peux voir ce que chaque serveur répond. Par exemple: dig toto.monsite.com. _AT_monserveurdns dig toto.monsite.com. _AT_serveurdnssecondaire Tu verras ainsi (ou en regardant l'évolution du serial du SOA) à quelle vitesse l'update est pris en compte (i.e. immédiat si tout est bien configuré ou plus lent sinon). Il va évidemment falloir que tu créés tes zones sur ton nouveau serveur. Et il va falloir que tu indiques à ton hébergeur quel serveur est le primaire pour la zone. Non, URL ne "matche" que la partie après le nom de domaine. Il faut utiliser: HeadRequire "^Host:.*www.domaine.fr" Il ne peut pas "laisser passer", il n'y a pas d'endroit où envoyer quoi que ce soit (il faut évidemment que tu aies déplacé le serveur http existant sur un autre port ou une autre adresse, sinon tu ne pourras pas lancer pound). Il faut lui mettre un autre service sans Headrequire qui prendra tout le reste et l'enverra au serveur d'origine. Sinon ça doit être possible aussi directement avec Apache, mais je n'ai jamais essayé. Jacques.

La première chose à faire, c'est, plusieurs jours avant la migration (en fait la durée actuelle du TTL), réduire le TTL sur l'enregistrement DNS concerné. Habituellement je le baisse à 1 heure quelques jours avant, puis quelques heures avant la migration je descends à 300 secondes. Tu peux ensuite le remonter une fois la migration faite. Ca ne garantit pas que tout le monde bascule en 300 secondes (tout le monde n'honore pas les TTL), mais ça permet déjà de traiter l'essentiel. Ensuite suivant les cas de figure exacts il y a pas mal de méthodes (pour une simple migration de machine sans changement de contenu, il suffit généralement de basculer les accès de base de données de l'ancien serveur vers le nouveau - à condition que tout ce qui est dynamique soit en base bien sûr, i.e. pas de fichiers temporaires, d'uploads dans des fichiers, etc. Mais ça n'a pas l'air d'être ton cas). Dans ton cas, un petit proxy genre pound est effectivement la solution la plus efficace pour que les connexions qui restent sur l'ancien serveur soient rebasculées sur le nouveau de façon transparente. Attention cependant si tu as besoin des adresses IP des clients à bien gérer X-Forwarded-For (avec un module comme mod_extract_forwaded sur le serveur cible ça se fait tout seul).Si tu as du SSL ça peut aussi réclamer un peu de boulot pour s'assurer que tout se passe bien. Jacques.

Je ne comprends pas tout... Le but du jeu c'est juste d'empêcher deux personnes de faire la même chose en même temps? Tu crées le fichier de lock au début du traitement, et tu le supprimes quand tu as fini, ça revient exactement au même que les autres méthodes, et c'est plus simple. Ou j'ai raté un truc? Jacques.

Petit problème dans ton fopen, tu ouvres en "r+", il faut que le fichier existe déjà pour que ça marche. Passe en "w" par exemple pour qu'il soit créé à la demande. Note aussi que comme indiqué dans la doc, flock et NFS ne font pas bon ménage. Ce qui veut dire que chez beaucoup d'hébergeurs, en mutualisé et autres solutions ou le disque dur n'est pas local, ça ne marchera pas. Ce qui d'ailleurs me fait penser qu'il y a encore plus simple: fais juste un fopen en "x" et teste la valeur de retour. Si le fichier n'existe pas, il sera créé, et tout va bien. Si le fichier existe déjà, tu auras une erreur. Evidemment il faut penser à supprimer le fichier une fois que tu as fini (avec unlink). $lock_filename='/var/tmp/antibrute_'+$pseudo; $lock_fh=fopen($lock_filename,'x'); if ($lock_fh) { // tout va bien, faire traitement fclose($lock_fh); unlink($lock_filename); } else { // lock déjà pris } Inconvénient avec cette méthode: s'il y a un problème en cours de route et que le fichier reste, le pseudo en question sera bloqué jusqu'à suppression manuelle du fichier. Au passage, le nom de fichier qui utilise directement un $_POST['whatever'] c'est très très très dangereux... Si le gars il met des "/" et des ".." il peut casser toutes sortes de choses. Donc bien vérifier/nettoyer avant d'utiliser. Jacques. EDIT: ajout incompatibilité avec NFS.

function cmp_field($f,$a,$b) { return $b[$f]-$a[$f]; // ah ben oui c'est plus court comme ça aussi :-) } function sort_array_field($array,$field) { usort($array,create_function("$a,$b","return cmp_field('"+$t+"',$a,$b)")); } sort_array_field($tableau,"prix"); Pas testé... Jacques.

En perl, <=> est un opérateur binaire de comparaison numérique qui renvoie -1, 0 ou 1 suivant que la première valeur est plus petite, égale, ou plus grande que la deuxième. Tout juste ce qu'il faut pour usort, quoi. C'est le pendant numérique de cmp (strcmp en php ou en C) pour les chaînes de caractères. Ca veut dire qu'en perl, la même chose que si dessus s'écrit sort {$a->{prix} <=> $b->{prix}} _AT_tableau. Jacques.

http://us2.php.net/manual/en/function.usort.php En gros: function cmp($a,$b) { if ($a['prix'] == $b['prix']) { return 0; } if ($a['prix'] < $b['prix']) { return -1; } return 1; } usort($tableau,"cmp"); Dommage qu'il n'y ait pas d'opérateur <=> en php comme en perl, ce serait nettement plus court. Jacques. EDIT: oublié le "u" de usort.

Tu n'as pas bien lu la doc... Pour que ça ne bloque pas, il faut passer LOCK_NB en deuxième argument (en plus du LOCK_EX, donc LOCK_EX | LOCK_NB). Le troisième argument doit être une référence à une variable qui indiquera si le lock aurait bloqué en l'absence de LOCK_NB, ce qui est redondant avec la valeur de retour de flock et errno a priori... Voir http://us3.php.net/manual/en/function.flock.php#90547 pour un exemple. Jacques.

Dans le monde hotelier, il y a à ma connaissance deux schémas: - le site débite le client de la totalité à la réservation, et paie sa part à l'hotel - le site ne fait qu'enregistrer un numéro de CB pour l'hotel, et celui-ci ne s'en sert que pour débiter la première nuit en cas de no-show. Le premier cas est généralement utilisé pour des tarifs fortement démarqués, avec obligation de réservation pas mal à l'avance, pas de possibilité d'annulation, etc. Le deuxième cas est généralement plus cher mais plus souple, le client ayant la possibilité d'annuler jusqu'à la dernière minute (en plein tarif ce sera généralement jusqu'au jour d'arrivée à 16 ou 18h suivant les hotels, sur des tarifs un peu plus intéressants ce sera 1 à 3 jours à l'avance). Dans le premier cas tu es parti pour une solution de paiement CB complète qui ne concerne que toi, et dont tu as intérêt à ce qu'elle soit la plus sûre possible évidemment. Dans le deuxième cas, c'est a priori à l'hotel de se débrouiller. La plupart le font déjà pour les réservations par téléphone par exemple, et devraient avoir le contrat qui va bien (de la même façon qu'ils sont généralement équipés pour faire une demande d'autorisation = montant du séjour + provision pour extras à l'arrivée, puis un débit du montant réel au départ). La seule chose que tu peux faire c'est demander les infos, vérifier la validité de la carte, ça n'ira pas beaucoup plus loin (tu ne peux pas faire une demande d'autorisation pour le montant du séjour parce qu'elle ne durera pas assez longtemps, et tu n'as pas le droit de stocker le CVC2/CVV2). Si tu veux vraiment en faire plus, tu peux toujours faire une demande d'autorisation pour quelques centimes, avec tout le tintouin (3D secure etc.), mais en expliquant bien au gars qu'il ne sera pas débité (bon courage pour qu'il comprenne). Note qu'en France il n'y a (à ma connaissance) aucun moyen de valider que le nom donné correspond à celui du porteur (pareil pour l'adresse), contrairement à ce qui peut se passer à l'étranger. Jacques.

Quand tu dis que "la vidéo ne s'envoie pas", il se passe quoi exactement? Une vidéo est généralement nettement plus grosse qu'une image, donc ça peut prendre un certain temps (voire un temps certain). Note aussi qu'il y a des paramètres php qui peuvent poser problème (taille limite de l'upload, durée maximale de la requête...). Jacques.

deny group n'existe pas, le site que tu montres correspond à la syntaxe d'un autre soft, inspirée des .htaccess d'Apache, mais qui n'a rien à voir. Il n'y a pas à ma connaissance de méthode pour faire ça en standard dans Apache. Mais tu peux mettre tes utilisateurs dans plusieurs groupes. Donc pour tous les utilisateurs dans les groupes autorisés tu les mets aussi dans un nouveau groupe pour ça, et pas les autres, et hop. Alternativement, tu peux générer des fichiers .htpasswd et/ou .htgroup différents suivants les contextes (à partir d'une liste "complète"). Note que comme indiqué dans la doc, si tu as beaucoup d'utilisateurs et/ou de groupes, ça risque d'être très peu efficace et tu as intérêt à utiliser un fichier DBM ou une base de données. D'ailleurs avec une base de données, soit en utilisant une vue, soit en utilisant Auth_PG_pwd_whereclause (pour pgsql, mais il doit y avoir la même chose pour mysql), tu peux restreindre les choses comme tu veux. Jacques.

Un point qui risque de te jouer des tours à un moment ou un autre... a AND b OR c, c'est mieux avec des parenthèses. Parce que (a AND OR c et a AND (b OR c), ce n'est pas la même chose. A mon avis tu veux le deuxième, or sans les parenthèses c'est le premier qui est évalué il me semble... Jacques.