jcaron

Il y a eu une discussion sur le sujet il n'y a pas très longtemps il me semble. En gros: - commencer par réduire le TTL des enregistrements DNS à quelques minutes un jour ou deux avant Ensuite: - soit copier tout le site, y compris la bdd, et faire pointer les deux sites sur la nouvelle BDD (si elle accepte les connexions distantes, évidemment), puis modifier les DNS - soit utiliser un reverse proxy (mod_proxy de Apache, pound, ou autre) pour renvoyer toutes les connexions de l'ancien site vers le nouveau, puis modifier les DNS - soit empêcher au moins les écritures pendant la migration, et modifier les DNS Il y a probablement d'autres solutions, y compris des solutions garanties sans perte de données et sans coupure, mais elles peuvent dépendent beaucoup de ce qui est possible de part et d'autre. Jacques.

Tu peux aussi utiliser rtrim: http://us2.php.net/manual/en/function.rtrim.php Jacques.

Je pense que si tu te débrouilles pour ne pas entrer dans le cadre de ces articles-là, tu tomberas dans le cadre d'un autre. Le CMF est assez long, et vérouille de façon assez explicite tout un tas de cas de figure très très large. Je serais assez étonné qu'il y ait des "trous"... Pour revenir sur tes questions précédentes, les établissements de crédit demandent quand même un minimum d'informations (revenus, charges, crédits en cours...), qu'ils vérifient avec plus ou moins d'insistance suivant le montant du prêt. Ils ont aussi accès aux fichiers d'interdits bancaire etc. Et ils sont mieux équipés qu'un particulier pour aller chasser le mauvais payeur (et/ou l'empêcher de nuire par la suite en l'inscrivant dans ces fichiers, justement, ce qui est une menace assez efficace pour la plupart des gens...). Et pour finir, si jamais il y a de temps en temps un gars qui ne rembourse pas une banque, ce n'est pas très grave (en proportion) par rapport à un prêt entre particuliers. Ceci étant dit, le risque pris justifie pour partie les taux élevés sur les crédits à la consommation, qui à son tour fait qu'ils ont une marge de manoeuvre suffisante pour ne pas chercher la petite bête (tout en ayant l'obligation de maintenir des ratios d'actifs par rapport aux sommes prêtées, on en a assez entendu parler ces derniers mois...). Et faire intervenir un notaire risque de changer considérablement le coût du prêt (sans parler d'alourdir le processus), ce qui rend la formule moins intéressante (et plus lourde et longue à mettre en place), sans pour autant apporter grand chose comme garanties. Bref, bien tenté, mais il va falloir trouver quelques millions d'euros et ouvrir ta propre banque :-) Jacques.

Je te conseille de commencer par une bonne lecture du code monétaire et financier: http://www.legifrance.gouv.fr/affichCode.d...eTexte=20090702 et de poursuivre par la consultation d'un avocat spécialisé qui pourra te dire si oui ou non tu risques d'entrer directement ou indirectement dans le champ du CMF et des activités réservées aux établissement de crédit (i.e. les banques), ou qui doivent être visées par l'AMF, ou des courtiers. Même si rien ne passe par toi (ni argent, ni contrat), tu peux probablement au minimum être considéré comme un courtier, ou alors de complicité avec les emprunteurs, qui même s'ils ne l'exercent pas de façon habituelle, risquent d'être considérés comme faisant un appel public à l'épargne, voire les prêteurs. Tu peux alternativement être considéré comme une plate-forme de négociation de titres financiers (c'est réglementé là aussi). Evidemment, tu pourrais de demander pourquoi on veut t'empêcher de rendre ce service, pourquoi les banques et autres institutions financières ont un monopole, etc. La raison est simple: dans ton système, qu-est-ce-qui empêche l'emprunteur de partir avec les sous (ou plus simplement, de ne pas rembourser ou de pas respecter les échéances)? Je ne te parle même pas des problématiques de surendettement, etc. Le risque est trop gros pour que ce soit autorisé sans contrôle... Jacques.

Chaque navigateur contient une liste de certificats "racine" qu'il considère comme étant autorisés à signer d'autre certificats. Certains certificats SSL ne sont pas signés directement par l'une de ces autorités, mais par un intermédiaire. Il faut alors inclure le certificat de cet intermédiaire (quelquefois plusieurs) dans ta configuration. L'autorité de certification qui t'a fourni ce certificat devrait t'avoir donné les instructions pour ça (en général il y a juste leur certificat à rajouter à la suite du tien dans le même fichier). Au passage, un certificat n'est valable (sauf cas particuliers) que pour un seul et unique nom de domaine complet (FQDN). Ici ton certificat est pour www.viaterra.net, donc si tu envoies de gens sur viaterra.net (sans le www.) tu auras des avertissements aussi. Jacques.

Et profitons-en pour rappeler que le <Limit GET POST> vient d'un exemple mal choisi de la doc Apache, il convient de les éviter, ils signifient que les directives dans ce bloc ne s'appliquent qu'aux requête GET ou POST (et donc pas au HEAD par exemple). Jacques.

http://fr.wikipedia.org/wiki/Multipurpose_...ts_encod.C3.A9s Jacques.

Le Content-Type ne s'applique qu'au "contenu" du mail, pas aux headers. Ceux-ci doivent d'ailleurs normalement être en 7 bits (i.e. ASCII pur). Pour mettre des accents dans le sujet, il faut que celui-ci soit encodé (il y a le choix entre du base-64 et du quoted-printable, éventuellement partiel) et que le charset y soit précisé. En gros, le header doit commencer par =? suivi du charset, suivi de ?Q? et du texte en quoted-printable ou ?B? et du texte en base-64, et fini par ?=. Le quoted printable revient à remplacer les caractères > 128 par =XX où XX est la valeur hexa correspondante (un peu comme quand on encode une URL et que les caractères en question sont représentés par %XX). Voir la RFC 2047 pour les détails. Note que je ne sais pas s'il y a en PHP des choses qui font tout ça plus ou moins automatiquement... Jacques.

L'info est disponible (au moins) dans le téléchargement d'historique. Jacques.

Une redirection est valable pour n'importe quel type de fichier servi en http, que ce soit une image ou une page web... Jacques.

Ca dépend beaucoup de ta définition de résolution: parles-tu de la définition en termes de pixels par pouce (ou centimètres), i.e. la "finesse" des pixels, ou de la résolution en termes de nombre de pixels en largeur/hauteur de l'écran? Dans le premier cas, il suffit de donner des tailles CSS en "pt" plutôt que "px", et elles feront toujours la même taille (en pouces/centimères), si le PC de l'utilisateur est correctement configuré (mais ça donne des effets de pixellisation pas terribles). Dans le deuxième cas, il faut probablement donner des tailles en %, mais ça suppose que l'ensemble des styles soient construits de cette façon... Et évidemment il y aura aussi une pixellisation pas très jolie... Evidemment, tu peux toujours limiter les effets de pixellisation en utilisant des images dans des formats vectoriels, du flash par exemple. Jacques.

<div style="position: fixed"> http://www.w3.org/TR/CSS/visuren.html#propdef-position Jacques.

En France, dans de nombreux cas (mais pas tous il me semble), les délais courrent à partir de la notification du courrier recommandé, donc le fait que le destinataire ne l'a pas cherché n'a pas forcément d'importance. Je ne sais pas comment ça se passe en Suisse, mais je suppose que c'est pareil. Maintenant, tout dépend de ce que tu lui racontes dans ce courrier et pourquoi il est important pour toi qu'il le reçoive. S'il s'agit d'une mise en demeure ou quelque chose de ce genre, en France tu peux toujours envoyer un huissier, je suppose qu'il y a un équivalent en Suisse. Et si tout ça n'a aucun effet, ben l'étape suivante c'est évidemment de le poursuivre en justice... (dans certains cas il peut aussi y avoir des organisations professionnelles et autres autorités de régulation qui peuvent intervenir). Jacques.

Ca ne répond pas directement à ta question, et ce n'est pas basé sur l'expérience (je n'ai jamais essayé), mais mon petit doigt me dit que "le" truc du moment ce sont les commentaires. Ca fait plein de contenu supplémentaire gratos, avec en plus des mots/expressions/ortographes différentes des tiennes/bonnes, mais avec un rapport avec la choucroute... Evidemment il faut empêcher le spam et modérer tout ça, mais bon... Jacques.

La première chose à faire, c'est chercher où il a trouvé ces liens (il ne les a pas inventés...). Sinon pour résoudre le problème, il faut que l'URL que le navigateur considère comme courante soit correcte. Deux solutions: soit tu fais un redirect et pas juste un rewrite "interne", soit tu ajoutes un base href dans ton HTML qui donne la "bonne" URL (sans le /, donc). Jacques.

Eeeuuuuhhhh... Le fait que tu utilises DOCUMENT_ROOT implique que tu travailles en local (i.e. la machine sur laquelle s'exécute le script est la machine sur laquelle tu veux créer le dossier)... Pourquoi ne pas faire un bête mkdir plutôt que de passer par ftp? Evidemment il peut y avoir un problème de droits, mais passer par FTP pour le résoudre me paraît bien tordu. Et si tu ne travailles pas en local, évidemment absolument de faire référence à un chemin local sur un serveur distant! Et pour info, oui: /xxx/yyy (un chemin qui commence par /) indique un chemin à partir de la racine (du système), on appelle ça un chemin absolu. xxx/yyy (ou ./xxx/yyy, c'est la même chose) indique un chemin à partir du répertoire courant (qui pour une session ftp est par défaut le répertoire de l'utilisateur correspondant, généralement un /home/nomdelutilisateur ou un truc du genre. Donc xxx/yyy == /home/nomdelutilisateur/xxx/yyy par exemple. On appelle ça un chemin relatif. Jacques.

Je réponds sans trop réfléchir là, mais... qu'est-ce-qui t'empêche de mettre les deux balises ou fichiers? Et puis si ton domaine.tld est redirigé vers ton www.domaine.tld, le bon réglage c'est "www.domaine.tld" uniquement, assez logiquement... Me gourre-je? Jacques.

Je pense qu'il s'agit du fichier de destination qui pose problème: il faut que tu donnes le chemin complet du fichier (nom du fichier compris), pas juste le répertoire dans lequel tu veux le mettre. Non? Jacques.

Page 1: formulaire avec option paiement CB + checkbox acceptation CGV. Post vers page 2. Page 2: vérification checkbox CGV. Si pas bon retour page 1. Si bon, afficher page HTML avec juste le formulaire de renvoi vers banque (qui ne contient que des input type=hidden), mettre un id=cequetuveux dans le form et ajouter juste après un petit bout de JS avec document.getElementById('idduformulaire').submit; Autre possibilité (mais je ne suis pas sûr que ça marche, à tester): Page 1: formulaire avec tous les champs hidden pour le POST vers la banque mais action=page 2 chez toi + checkbox. Page 2: vérification checkbox + bête redirect 302 vers l'URL de la banque. Si tout va bien le browser va de nouveau poster tout le formulaire (il me semble que c'est effectivement le cas, mais à vérifier). Jacques.

Ben ils ont les stats des sites qui affichent des Adsense ou du Doubleclick, des sites qui utilisent Analytics, la toolbar, les clics sur les pubs et les liens dans Google (et tous les dérivés)... Autant dire qu'ils savent tout :-) Jacques.

Je pense qu'il a été dit mille fois que ce n'est pas une bonne idée: le referer est souvent masqué (par des outils de "protection de la vie privée", qui sont souvent intégrés par défaut dans des anti-virus et autres firewalls), donc il y a des gens qui devraient avoir accès à ces fichiers pour qui ça ne fonctionnera pas. Et évidemment ce n'est pas absolu puisqu'il est parfaitement falsifiable avec les bons outils. A part ça, tes regexp sont beaucoup trop "larges": une page http://sitealacon.com/webmaster-hub.html passera. Si tu veux limiter les gens qui ont accès à ces fichiers, soit tu mets en place une authentification explicite (à base de .htaccess, de cookies...), soit tu mets un cookie (avec éventuellement une durée de vie limitée) qui est positionné par la page d'accès et vérifié par la page accédée, soit tu utilises des URLs "dynamiques" vérifiées elles-aussi (par exemple gnagna.com/fichier?t=$time&k=$clef où $clef est un md5 d'une clef secrète et de $time, et où la destination vérifie que $time est "récent"). Il y a probablement encore beaucoup d'autres solutions, le choix de la solution exacte dépend de ce que tu cherches à faire exactement... Jacques.

Bien sûr que si... La mise en demeure peut servir à faire retirer des éléments du site, mais ça ne préjuge pas de la possibilité pour la personne qui se sentirait lésée d'attaquer pour obtenir des dommages et intérêts par exemple. Evidemment dans ce cas le fait d'avoir réagi promptement à la mise en demeure sera probablement prise comme une circonstance atténuante (même si certains pourraient imaginer au contraire que c'est une reconnaissance de culpabilité). Maintenant dans la plupart des cas, si la personne qui fait l'objet de la mise en demeure s'exécute rapidement, ça s'arrête généralement là. D'ailleurs c'est souvent indiqué plus ou moins explicitement dans la mise en demeure (genre "si vous ne vous exécutez pas, on vous attaque" -- notez bien que ça ne veut pas dire "si vous vous exécutez on ne vous attaque pas", même si beaucoup le prennent comme ça). Il faut noter que dans le cas particulier des hébergeurs (au contraire des éditeurs), le fait de s'exécuter rapidement les éxonère, eux, de poursuites. Jacques. EDIT: ah ben Arlette est passée par là entretemps, c'est un peu redondant ce que je dis...

Quand tu dis que le ping fonctionne, tu le fais avec le nom du site ou avec l'adresse IP? Si ça fonctionne avec l'IP mais pas avec le nom ce serait logiquement un problème DNS. Si dans les deux cas c'est avec le nom, ça peut être beaucoup de choses: ton serveur, ton PC (anti-virus, firewall...). Ca aiderait probablement avec l'adresse du site... Jacques.

Il faut que tu fasses un session_start au début de chaque requête qui va utiliser les variables de session. Ca ne créé pas systématiquement une nouvelle session, ça récupère la session existante s'il y en a déjà une. Pas besoin de tester session_id d'ailleurs. Jacques.

D'abord, il s'agit d'optimiser ta base SQL: - utilise un entier (unsigned int) et pas un champ texte pour l'adresse IP (conversion avec ip2long) - évidemment il doit y avoir un index sur cette adresse IP - autant que possible pas ou peu d'autres données dans la table Je ne suis pas un expert de mysql (je suis plutôt postgresql), mais a priori pour ce genre de chose assure-toi que ta table est en MyISAM, et utilise éventuellement myisamchk --sort-index. Je ne sais pas s'il y a l'équivalent d'un "VACUUM FULL" ou d'un "CLUSTER" (qui permettent de faire l'équivalent d'une défragmentation de disque en récupérant tout l'espace libéré par les lignes effacées/modifiées, donc de réduire la taille de la table sur disque, donc d'augmenter les hits en cache et de limiter les seeks)? Ensuite, tu peux au choix: - utiliser un cache mémoire (par exemple memcache, mais je pense que c'est un peu overkill, mais il doit y avoir d'autres options) - utiliser un fichier DBM (voir les fonctions dba_* en php), ça évite un peu d'overhead réseau, parsing, etc. - ne vérifier que la première fois qu'un utilisateur se connecte avec une IP donnée, puis mettre un cookie (ou une variable de session) qui contient son IP (et probablement une clef calculée sur cette IP) - si le nombre d'IPs autorisées et actives est sensiblement inférieur au nombre d'IPs non autorisées (et le nombre d'accès par les IPs autorisées supérieur au nombre d'accès par les IPs non autorisées), un cache "positif" (sous la forme d'une table mysql, d'un cache type memcache, d'un fichier DBM, voire d'une arbo de fichiers) peut se révéler suffisant (par rapport à un cache "global"). Je pense que les autres solutions évoquées auront un effet négatif sur les perfs. Jacques.