Comment filtrer mon site pour les autres sites voulant aspirer ses résultats ?

WRInaute accro
Bonjour

Mon site donne des Statistiques et Pronostics sur les Courses de Chevaux.

Il me semble, d'après la page "Paris gagnés sur les deux derniers jours", accessible à partir de la page d'accueil, qui est assez fournie en général, que mes pronostics sont bons la plupart du temps.

Je pense donc, que c'est tout à fait possible, que d'autres sites de Turf, copient mes pronostics de manière dynamique, donc à partir de leur sites, et que j'ai intérêt à filtrer les accès de ces sites à mon site.

Il faudrait que celà soit fait en php, pas avec des fichiers .htaccess, du moins je pense que celà n'est possible qu'en php.

Comment faire pour celà ?

Je peux théoriquement regarder l'adresse ip ou les noms de domaines des adresses ip qui se connectent sur mon site, et filtrer en fonction ( par exemple spécifiquement si ce sont des sites web. ). Mais je risque à ce moment-là, de filtrer aussi les moteurs de recherche, ce que je ne souhaite pas.

Comment faire pratiquement, pour filtrer l'accès à mon site pour tous les sites web, à part mon site partenaire, et les sites des moteurs de recherche ?

Pour ce qui est des moteurs de recherche, faut-il que je dispose des noms de domaines de tous les moteurs de recherche pour celà ?

Merci de m'indiquer de m'indiquer la méthode pratique.

Bien à vous.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
- cherche déjà a connaître / identifier les "aspirateurs" et a identifier leur IP précise. (ping http://www.example.com te donnera l'ip du serveur.)
- pour cela tu peut télécharger tes logs et filtrer sur ta page de pronostic afin d'avoir un aperçu du monde qui y passe.
- pour ce qui est des moteurs, leurs IP sont facilement identifiables avec un whois.
- observe aussi les useragents certains bot affichent bien la couleur ça peut aider a filtrer aussi.
- gethostbyaddr($_SERVER['REMOTE_ADDR']) peut aussi te donner de précieuses informations sur le visiteur.

ensuite en tête de page un truc du genre :
if($_SERVER['REMOTE_ADDR'] == 'aaa.bbb.ccc.ddd'){exit():}

ça serait plus propre avec un htaccess.
 
WRInaute accro
Bonjour

Merci de ta réponse.

Sous l'angle programmation pure php, j'ai donc les éléments clés pour filtrer.

Ce sont :

gethostbyaddr($_SERVER['REMOTE_ADDR']) // Nom d'hôte du client remote.

$_SERVER['REMOTE_ADDR'] // Adresse ip du client remote.


Mais... D'abord, comment identifier les bots de moteurs de recherche, de manière sûre ?

Et puis... Comment différencier les noms d'hôtes provenant de sites web, de ceux de fournisseurs classiques d'accès internet ? Ces derniers noms d'hôtes, ainsi que ceux des moteurs de recherche, je ne dois pas les filtrer... ;)

Dans un premier temps, j'aurais donc besoin d'une méthode sûre pour identifier par leurs noms d'hôtes, les bots des moteurs de recherche.

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
J'ajoute...

Ce ne sont pas les aspirateurs que je veux filtrer ( pas seulement eux ), mais aussi tout site web aspirant, ne serait-ce que une page/jour à la fois, le contenu de mon site.

Bien à vous.

Jean-François Ortolo
 
WRInaute accro
ortolojf a dit:
J'ajoute...

Ce ne sont pas les aspirateurs que je veux filtrer ( pas seulement eux ), mais aussi tout site web aspirant, ne serait-ce que une page/jour à la fois, le contenu de mon site.
Ca c'est une vue de l'esprit ... exemple : je veux aspirer ta page prono chaque jour :

1 - Je le fais peinard avec mon navigateur standard et je stock le contenu de ta page sur un serveur et comme je suis une flemmasse j eme fais une petite routine en local qui va ouvrir ta page et la sniffer chaque matin a une heure variable (j'ai pas d'ip fixe)
2 - un autre site web va automatiquement venir relire cette page, extraire son contenu et le republier

Que veux tu détecter ? que veux tu contrer ?
 
WRInaute impliqué
Ce que tu demandes est théoriquement impossible puisqu'il est possible de simuler n'importe quel navigateur complet par programmation...
Tu peux néanmoins compliquer pas mal la tâche des "copieurs" en affichant tes pronostics par un script javascript ou flash qui change tous les jours.
Mais tu ne pourras pas empêcher quelqu'un de regarder ton site avec ses propres yeux tous les matins et de reporter tes pronostics sur son propre site.
 
WRInaute accro
jeromax a dit:
Ce que tu demandes est théoriquement impossible puisqu'il est possible de simuler n'importe quel navigateur complet par programmation...
Tu peux néanmoins compliquer pas mal la tâche des "copieurs" en affichant tes pronostics par un script javascript ou flash qui change tous les jours.
Mais tu ne pourras pas empêcher quelqu'un de regarder ton site avec ses propres yeux tous les matins et de reporter tes pronostics sur son propre site.


Super ! Merci beaucoup de ta réponse ;)

Effectivement, la plupart des navigateurs réels, supportent le Javascript... ;)

Je suis une triple ( non, une quadruple ) buse, je n'avais pensé à cette solution.

Merci beaucoup de ta réponse.

Je pense que je vais modifier prochainement mon site en intégrant mes pronostics calculés, dans un script Javascript.

Merci encore.

Très amicalement.

Jean-François Ortolo
 
WRInaute accro
jeromax a dit:
Ce que tu demandes est théoriquement impossible puisqu'il est possible de simuler n'importe quel navigateur complet par programmation...
Tu peux néanmoins compliquer pas mal la tâche des "copieurs" en affichant tes pronostics par un script javascript ou flash qui change tous les jours.
Mais tu ne pourras pas empêcher quelqu'un de regarder ton site avec ses propres yeux tous les matins et de reporter tes pronostics sur son propre site.


Bonjour jeromax ;)

J'ai mis tous mes pronostics calculés en mode Javascript. ;)

Cependant, même pour un logiciel n'interprétant pas le Javascript, les données des pronostics sont quand même dans le source. ;(

Comment faire pour masquer des données en Javascript ?

Si des données s'affichent quand Javascript est activé, c'est nécessairement qu'elles sont visibles dans le source même quand il est désactivé, non ?

Sinon, on pourrait envisager un script Javascript dédié externe, qui récupère les données à afficher, et les affiche... Mais à ce moment-là, pareil : Les données seront visibles dans le source, puisqu'il faudra transmettre des paramètres au script.

On peut envisager effectivement de coller les données dans une table MySQL... Mais le script nécéssairement php, montrerait les sources... A moins qu'il ne soit lancé en Ajax... Mais là encore, il serait facile dans le source, de savoir quel script il faut lancer, et avec quels paramètres. ;(

Comment faire pour masquer des données dans le source, quand javascript est désactivé ?

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
Tu peux faire ça en AJAX sinon : les données seraient générées dans le script PHP appelé en Ajax. Et dans ce cas tu peux sécuriser un minimum le truc en interdisant l'appel de ce script depuis un autre referrer que les pages autorisées.
 
WRInaute accro
UsagiYojimbo a dit:
Tu peux faire ça en AJAX sinon : les données seraient générées dans le script PHP appelé en Ajax. Et dans ce cas tu peux sécuriser un minimum le truc en interdisant l'appel de ce script depuis un autre referrer que les pages autorisées.


Merci beaucoup de ta réponse.

Le seul problème qui reste, est le passage des paramètres.

Le problème, est que les pronostics, dépendent pour chaque course, du positionnement des paramètres du Panneau de Configuration.

Pour la même Course, les pronostics peuvent être différents.

Il me suffirait de mémoriser deux ou trois arrays de 12 nombres au maximum par pronostics différents.

Sachant que le paramétrage du Panneau de Configuration peut donenr lieu à une infinité de pronostics différents sur la même course, un par ensemble donné de paramètres de ce Panneau, comment faire ?

Le problème, est que je ne peux que difficilement transmettre uniquement les paramètres du Panneau de Configuration, puis dans le script lancé par Ajax, refaire tous les calculs statistiques menant aux pronostics. Cela induirait un doublement du temps de chargement de la page.

Je pourrais, à la rigueur, mettre quotidiennement, à la fois les pronostics résultants de valeurs précises du Panneau de Configuration dans une table MySQL, et puis transmettre seulement ces paramètres de la course et du Panneau de Configuration au script lancé par Ajax, à charge pour lui de retrouver dans la table MySQL, les pronostics correspondants.

Grrrrmmmmblllhhh... J'y pense... J'y pense... Vais-je le faire ?... ;)

Je ne vois pas d'autre solution.

Merci beaucoup à toi de ta réponse ! ;)

Amicalement !

Jean-François Ortolo


PS J'ai trouvé encore mieux, mais celà dépend des sessions.

Je peux mémoriser un identifiant de session, et l'associer au pronostic venant d'être calculé dans la page principale, et le mémoriser ainsi que le pronostic, dans la table MySQL.

Ainsi, il n'y aura jamais qu'un seul pronostic par visiteur en même temps, et le pronostic pourra changer en fonction du positionnement du Panneau de Configuration.

Mais... Si les cookies sont interdits, je ne peux mémoriser l'identifiant de session, que dans l'url du script lancé par Ajax. ... Je vais étudier celà, pour gérer les sessions dans tous les cas.

Mais... N'y a-t-il pas moyen, avec les sessions, de différencier un visiteur réel, d'un logiciel bidon autre qu'un navigateur ?

Merci beaucoup de vos réponses.

Amicalement.
 
WRInaute accro
ortolojf a dit:
Mais... N'y a-t-il pas moyen, avec les sessions, de différencier un visiteur réel, d'un logiciel bidon autre qu'un navigateur ?
pour des scripts kiddies, oui. Mais après, on arrive à des pompeurs plus évolués qui récupère aussi les cookies et arrivent plus facilement à simuler une "vraie" navigation. Ils envoient même des referers :evil:
 
WRInaute accro
Je pense donc, que c'est tout à fait possible, que d'autres sites de Turf, copient mes pronostics de manière dynamique, donc à partir de leur sites, et que j'ai intérêt à filtrer les accès de ces sites à mon site.

Bloquer un site est simple que ce soit en php ou en Hta, mais tant que tu ne saura pas qui le fait tu ne pourra rien faire.

Sinon générer une image dynamique avec GD est aussi une solution anti copie pour les données.
 
WRInaute impliqué
Les referers et les cookies ne sont pas un problème, regarde la doc de CURL par exemple et tu vas voir que tu peux tout faire.
Par contre créer un interpreteur javascript est beaucoup plus difficile.
Exemple:
Code:
var prono1='tonPronoCodéEnPhpParExemple';
var cle1='uneCleQuiVaTePermettreDeDecoderTonPronostic';
function afficherProno(p1,c1){
//code de la fonction qui décode le pronostic codé
}
document.write(afficherProno(prono1,cle1));
Si tu change dynamiquement le code de afficherProno et la cle, cela va être compliquerd'analyser tout ça. De plus, de cette manière, les pronostics n'apparaissent pas dans le source de ta page.
Après tu peux corser le truc en changeant le nom des variables javascript dynamiquement ainsi que le nom de la méthode.
Mais je le répète, celui qui veut copier tes pronostics aura alors tout intérêt à regarder ta page avec ses yeux et les copier sur son site, ça lui prendra 2min...
 
WRInaute accro
Il pourra meme dans tous les cas "regarder mais pas avec ses yeux" et ca prendra 2 s :

En local il s'ecrit un petit prog dans le langage de son choix, qui va ouvrir ta page web dans un navigateur. La le petit programme va simuler (certains langage le permettent tres bien) :

- un clic pour donner le focus a la fenetre du navigateur,
- un control A puis un control c
- puis va ensuite recupéer et stocker dans une variable le resultat du control C,
- va parser ta page, recupérer ce qu'il veut
- et le poster en dynamique sur le ftp d'un autre site
- qui va lui le publier ... en quasi temps réel ..).

Désolé de te miner le moral mais des qu'un truc est s ur le web, il est potentiellement et assurément pompable (sur un plan technique s'entend).
 
WRInaute accro
Bonsoir

J'ai mis en place l'alimentation des deux tables MySQL avec l'identificateur de session et les données.

Je n'ai plus qu'à programmer le script qui lira les tables, et affichera les pronostics.

Facile...

En principe, avec Ajax je serai protégé, car personne ne peut deviner l'identificateur de session à moins d'être en direct avec un navigateur, en regardant dans le source le paramètre que je transmettrai au script d'affichage.

Et puis... Si l'on disait tous ses petits secrets techniques à tout le monde, où irait-on ? Hein ? Hein ?

Bien à vous, merci de votre aide.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
ortolojf a dit:
En principe, avec Ajax je serai protégé, car personne ne peut deviner l'identificateur de session à moins d'être en direct avec un navigateur, en regardant dans le source le paramètre que je transmettrai au script d'affichage.
ouai, mais Zecat t'a indiqué comment ils pourraient procéder. Juste un copier/coller avec une navigation classique
 
WRInaute accro
Leonick a dit:
ouai, mais Zecat t'a indiqué comment ils pourraient procéder. Juste un copier/coller avec une navigation classique


Bonsoir Leonick ;)

Je sais bien... ;(

A l'impossible nul n'est tenu, hélas...

Je vais tâcher de programmer les deux scripts d'affichage ce soir, et de revoir mes script de chargement dynamique Ajax.

Après, basta...

Merci beaucoup de ta réponse. ;)

Amicalement.

Jean-François Ortolo
 
WRInaute accro
car personne ne peut deviner l'identificateur de session à moins d'être en direct avec un navigateur
Avec curl voici ce que l'on récupère sur une de tes pages :

Date Tue, 27 Jul 2010 19:27:30 GMT
Server Apache
X-Powered-By PHP/5.2.6-1+lenny4
Expires Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma no-cache
Content-Encoding gzip
Vary Accept-Encoding
Keep-Alive timeout=5, max=20
Connection Keep-Alive
Transfer-Encoding chunked
Content-Type text/html
Requêtevoir le code source
Host http://www.pronostics-courses.fr
User-Agent Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.6) Gecko/20100629 Mandriva Linux/1.9.2.6-0.1mdv2010.0 (2010.0) Firefox/3.6.6 GTB7.1
Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding gzip,deflate
Accept-Charset ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive 115
Connection keep-alive
Referer http://www.pronostics-courses.fr/
Cookie SES=07876b359dec058d758b36cd54cc820c; __utma=23006202.1914087427.1280245990.1280245990.1280259240.2; __utmc=23006202; __utmz=23006202.1280259240.2.2.utmcsr=forum.webrankinfo.com|utmccn=(referral)|utmcmd=referral|utmcct=/comment-filtrer-mon-site-pour-les-autres-sites-voulant-aspirer-ses-resultats-t131188-15.html; __utmb=23006202.1.10.1280259240

pense tu vraiment que ce soit si compliqué que ça ? -http://forum.hardware.fr/hfr/Programmation/PHP/curl-ssl-session-sujet_121387_1.htm#t1856648
 
WRInaute accro
Vous allez finir par nousle casser notre orto :mrgreen: Lui sapper pas le moral ... hein quoi c'est moi qui ai commencé ? ah oui c'ets "vré" :roll:

Allez pour être positif : si tu veux un peu plus pourrir la vie du copieur : tu ponds 4 ou 5 versions (au niveau ergonomie, organisaaion du code etc) de ta page (avec des includes c'est vite faits) même si elle affiche in fine les memes infos. et en fonction d'un rand tu affiches l'une ou l'autre alternativement ... du coup meme mon petit programme va falloir que je fasse 6 parsing différents, en espérant que tu en sortes pas un 7 eme une fois que j'ai fini de debugguer :mrgreen:

Regrade Google l'a bien compris qui chnage regulièrement les pages adsenses, mettant d'un seul coup dans les choux tous les outils d'interro automatique :mrgreen:
 
WRInaute accro
zeb a dit:
car personne ne peut deviner l'identificateur de session à moins d'être en direct avec un navigateur
Avec curl voici ce que l'on récupère sur une de tes pages :

Date Tue, 27 Jul 2010 19:27:30 GMT
Server Apache
<...>
Referer http://www.pronostics-courses.fr/
Cookie SES=07876b359dec058d758b36cd54cc820c; __utma=23006202.1914087427.1280245990.1280245990.1280259240.2; __utmc=23006202; __utmz=23006202.1280259240.2.2.utmcsr=forum.webrankinfo.com|utmccn=(referral)|utmcmd=referral|utmcct=/comment-filtrer-mon-site-pour-les-autres-sites-voulant-aspirer-ses-resultats-t131188-15.html; __utmb=23006202.1.10.1280259240

pense tu vraiment que ce soit si compliqué que ça ? -http://forum.hardware.fr/hfr/Programmation/PHP/curl-ssl-session-sujet_121387_1.htm#t1856648


Bonjour Monsieur

Pour réussir à obtenir le Pronostic courant, le hacker serait obligé de faire une première requête avec les headers, par curl, à la page de la Course ( contenant le Tableau des Stats ), puis une deuxième requête juste après, au script d'affichage des Courses...

De toute manière... Le source de la page de la Course, contiendrait le paramètre d'identificateur de session, dans le code Javascript lançant le script d'affichage... ;(

Mais... A mon avis, un Turfiste ayant toutes les connaissances techniques pour hacker, préférera beaucoup utiliser les données du Tableau Statistique de la Course, figurant dans le source de la page initiale.

Et... Je suis bien obligé, pour fournir du contenu à Google ( entre autres ), de laisser libra accès à ces stats sur la page des Courses. ;(

C'est vrai ce que vous avez dit, je note qu'effectivement, avec un peu de connaissance de la technique utilisée, c'est possible de hacker... Mais quand il y a des moyens plus facile d'obtenir quasiment le même résultat...

Merci beaucoup de votre réponse, qui m'a bien montré, malgré ma céticé intellectuello--affective passagère, qu'effectivement ce moyen super-miraculeux, n'était pas si efficace que ça. ;)

Bien à vous.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
ortolojf a dit:
Mais... A mon avis, un Turfiste ayant toutes les connaissances techniques pour hacker, préférera beaucoup utiliser les données du Tableau Statistique de la Course, figurant dans le source de la page initiale.
pourquoi un turfiste ? tu crois que les webmasters qui pompent le contenu de nos sites sont des passionnés ? passionnés soit, mais uniquement par l'argent qu'il vont obtenir grâce au mfa qu'ils feront avec notre contenu :twisted:
Donc, malheureusement, si ton site a des infos intéressantes et qu'il y a un public concerné par ces données, ils peuvent très bien automatiser une reprise de données de ton site vers le(s) leur(s)
 
WRInaute accro
Leonick a dit:
pourquoi un turfiste ? tu crois que les webmasters qui pompent le contenu de nos sites sont des passionnés ? passionnés soit, mais uniquement par l'argent qu'il vont obtenir grâce au mfa qu'ils feront avec notre contenu :twisted:
Donc, malheureusement, si ton site a des infos intéressantes et qu'il y a un public concerné par ces données, ils peuvent très bien automatiser une reprise de données de ton site vers le(s) leur(s)


Bonjour Leonick ;)

Voilà, tout le système est mis en place. ;)

Je te convie à visiter mon site, et voir comment hacker ses pronostics. ;)

Amicalement et affectueusement.

Jean-François Ortolo
 
WRInaute impliqué
bon je viens de faire un test: *http://www.openrdv.com/prono.php?num=0
tu as juste à changer le numéro pour avoir accès aux différentes courses...
(réellement 10min de dev)

PS: le useragent utilisé est "test WRI" si tu veux le repérer dans tes logs
PS2: ne t'inquiète pas, j'enlève cette page dans la journée
 
WRInaute impliqué
Pourquoi ne pas proposer une api pour que les webmasters puissent directement afficher tes pronostiques sur leur site ?

Il n'existe AUCUN moyen de protéger tes données alors autant retourner le problème à ton avantage, l'api affichera un lien vers ton site ce qui t'apportera du trafic et améliorera ton référencement.
 
WRInaute accro
jeromax a dit:
bon je viens de faire un test: *http://www.openrdv.com/prono.php?num=0
tu as juste à changer le numéro pour avoir accès aux différentes courses...
(réellement 10min de dev)

PS: le useragent utilisé est "test WRI" si tu veux le repérer dans tes logs
PS2: ne t'inquiète pas, j'enlève cette page dans la journée


Bonjour jeromax

J'ai vu. ;(

Je suppose que tu as d'abord regardé le source de la page, puis programmé un sniffage en curl, suivi d'une sélection du code d'aspiration des données à afficher, puis de l'aspiration des données, toujours en curl.

Bon, bon... A l'impossible nul n'est tenu. ;(

C'est bon à savoir, que tous les sites sans exception peuvent être copiés, à moins évidemment de ceux soumis à login et mot de passe... ;(

J'espère que tu ne vas pas monnayer cela à des Turfistes. ;)

Merci beaucoup de ta réponse.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
Bonjour

J'ai essayé de filtrer l'accès à ce script, mais maintenant il n'est plus accessible. ;(

J'ai mis celà dans le .htaccess :

<Files affic_pronostics.php>

Order Deny, Allow
Deny from all
Allow from www.pronostics-courses.fr

</Files>

Qu'est-ce qui cloche ?

Normalement l'adresse ip de mon hébergement, est : 93.184.35.226

Que ce soit ça ou www.pronostics-courses.fr , ça foire.

Que faire ? ;(

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
J'ajoute...

Ce script est lancé par mon site en Ajax.

Donc, l'adresse ip source de cette connexion http faite en Ajax, devrait être de mon hébergement ?

Amicalement.

Jean-François Ortolo
 
WRInaute impliqué
ortolojf a dit:
J'espère que tu ne vas pas monnayer cela à des Turfistes. ;)
Je n'y avais pas pensé tien... :)
Je supprime la page.

Par contre, effectivement, je pense que c'est quasi perdu d'avance en ce qui concerne la protection automatique de tes données... :?
 
WRInaute impliqué
ortolojf a dit:
J'ajoute...

Ce script est lancé par mon site en Ajax.

Donc, l'adresse ip source de cette connexion http faite en Ajax, devrait être de mon hébergement ?

Amicalement.

Jean-François Ortolo


Faux, la page chargée par ajax est lancé a partir du poste client via javascript .
Donc l'ip est celle du client, et pas celle de ton serveur ;)

Ne te prend plus la tête avec ce problème, c'est vraiment impossible d'empêcher un tier d'accéder a de l'information, sauf en fermant ton site.

Dis toi que un site légale ne prendra par le risque de repomper ton contenu, et les sites illégaux ne sont pas vraiment une concurrence.

Tu n'as pas réagis a ma suggestion sur l'api, mais c'est a mon sens un moyen adroit de prendre les devants sur le problème. ^_^
 
WRInaute accro
Tu peux par contre vérifier plusieurs choses pour sécuriser davantage ton script, notamment Tester le referrer (via $_SERVER['HTTP_REFERER']). Mais il est clair que tu auras beau sécuriser le truc, il y aura toujours une solution et un petit malin pour passer outre.
 
WRInaute impliqué
Je pense que la solution la plus pénible pour les copieurs, c'est la génération du flash à la volée contenant tes pronostics mais pas en passage de paramètres hein... :wink: il faut que les pronostics soient inclus dans le flash et crypté. De cette manière ils ne seront pas lisibles directement dans le source du flash. Ton swf décode les pronostics et les affiche au client.
Ensuite il faut protéger ce flash grâce à une vérification du referer pour empêcher que les copieurs ne l'utilisent directement sur leur site.
La petite astuce bonus, c'est même de laisser les copieurs afficher les pronostics 1 ou 2 jours sur leur propre site: ils vont penser que ton script n'est pas sécurisé, dépenser de l'énergie à tout mettre en place en pensant que c'est ok, puis tu mets un lien vers ton site au bout de 2 jours à la place des pronostics dans ton swf => le copieur pense que c'est bon et ne va pas forcément vérifier que ça fonctionne toujours quelques jours après.
J'ai utilisé cette technique sur des photos: les types affichaient les photos directement sur leur site. Au lieu de leur balancer un message comme quoi c'était interdit, j'autorisai l'affichage pendant 2 jours, ensuite l'image changeait automatiquement pour inciter les internautes à aller voir le site original. Les posteurs ne s'en aperçoivent généralement jamais et ça te fais de la pub gratos qui traine sur les sites pendant des années :wink:
 
WRInaute accro
Bonjour jeromax

Je ne connais pas le flash.

Par contre, je pourrais générer une image graphique facilement...

Les Historiques Graphiques en haut de l'écran ( déactivés par défaut, mais activables par le visiteur ), ont été programmés par mes soins.

C'est faiseble, effectivement...

J'aurais du y penser plus tôt.

Ou bien, tout simplement... Utiliser ce que j'ai déjà fait, qui me permet de passer les paramètres de manière opaque, et transformer l'affichage de texte en affichage d'image jpg.

Faisable, tout à fait faisable...

Merci beaucoup de ta suggestion pour le flash.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
UsagiYojimbo a dit:
Tu peux faire ça en AJAX sinon : les données seraient générées dans le script PHP appelé en Ajax. Et dans ce cas tu peux sécuriser un minimum le truc en interdisant l'appel de ce script depuis un autre referrer que les pages autorisées.


Bonjour UsagiYojimbo ;)

J'ai mis en place la solution en Ajax que tu préconisais.

Haroeris me dit que l'adresse ip source du lancement par Ajax du script d'affichage, est l'adresse ip cliente.

C'est vrai que le referer est l'url de la page à partir de laquelle est fait ce chargement Ajax ?

A ce moment-là, ce devrait être un jeu d'enfant de filtrer suivant ce referer...

Mais, celà n'empêchera pas les petits malins de fausser leurs referers.

Mais... N'y aurait-il pas moyen, que j'agisse sur le referer apparent, de manière à ce qu'il soit codé de manière impossible à deviner, car complexe ?

En curl, je crois que c'est possible... Et ce ne serait que des instructions php, qui ne seraient pas visibles dans le source. ;)

Là, je crois que je tiens le bon bout. ;)

Merci beaucoup de ta réponse.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
ortolojf a dit:
Mais... N'y aurait-il pas moyen, que j'agisse sur le referer apparent, de manière à ce qu'il soit codé de manière impossible à deviner, car complexe ?

En curl, je crois que c'est possible... Et ce ne serait que des instructions php, qui ne seraient pas visibles dans le source. ;)

Là, je crois que je tiens le bon bout. ;)

Merci beaucoup de ta réponse.

Amicalement.

Jean-François Ortolo



Grmmmbbblllhhh... ;(

Je suis con comme une balayette à pédales. ;(

Si j'utilise curl, les pronostics seront dans le source...

Il ne me reste plus que de générer une image à la volée, apparemment.

De préférence, le script des pronos faisant cette image, peut être lancé de la même manière que mes historiques graphiques, simplement avec un lien.

Après tout, peut importent les dimensions relatives des pronos par rappport à la largeur de l'écran, il y a de la marge, je peux mettre des dimensions fixes.

Je pourrais même ne pas avoir de Javascript, là.

Par contre, les paramètres seront invisibles, car l'identificateur de session sert de clé d'accès.

Merci beaucoup de vos réponses.

Jean-François Ortolo
 
WRInaute impliqué
Une suggestion même si je ne sais pas du tout comment sont présentés tes résultats, tu peux générer ton tableau de pronostique grâce a une image GD.

Le résultat est une image, donc avec cette méthode tu paralyse 99,99% des possibilité de scan tout en gardant quelque chose de beau.
Tu peut même générer des graphiques battons et camemberts .


Bien sur quelqu'un pourrait développer un script de reconnaissance de caractère mais la c'est pas a portée de tout le monde surtout si ton infographie est un peut poussée.


edit : ah je viens de lire que tu avais déjà pensé a cette possibilités ^^
 
WRInaute accro
Bonjour

Le problème essentiel à la programmation de cette image GD, est que je disposerais que d'une seule police et taille de caractères.

En effet, je crois qu'à moins d'installer un package spécifique sur l'hébergement, il n'y a aucune possibilité en GD, de choisir sa police de caractères... ;(

Pour l'instant, j'ai mis un filtrage par referer, vous pouvez tester de nouveau ( jeromax, si tu veux ;) ).

Merci beaucoup de vos réponses.

Jean-François Ortolo
 
WRInaute impliqué
Arff... j'ai supprimé la page et je n'ai pas de copie
=> par contre ton filtrage par referrer ne sert à rien, la page que j'avais faite prenais déjà en compte le referrer...
 
WRInaute accro
jeromax a dit:
j'ai refais une page, je t'envoie l'url en mp, tu pourras faire tes tests


Bonjour jeromax ;)

Je t'ai envoyé ma petite réponse. ;(

Merci beaucoup, c'est par ses manques qu'on apprend. ;)

Je vais me pencher sur la programmation GD de nouveau, pour voir si c'est possible de choisir la police de caractères pour la fonction qui affiche des caractères.

Je crains fort, que l'apparence graphique, fasse moins belle que celle actuelle.

Merci encore.

Amicalement.

Jean-François Ortolo
 
WRInaute impliqué
une page quelque part sur internet a dit:
Il est possible de changer la police de caractères par défaut, avec une police du type TTF(.ttf).

La fonction permettant de changer la police de caractères.

imagettftext($image, $font_size, $angle, $x, $y, $couleur, $font_filename, $text);

Attention ! Cette fonction nécessite que GD soit compilé avec le support de FreeType 2.x, donc GD2.

:mrgreen:
 
WRInaute impliqué
je crois qu'avant de te lancer dans ton développement GD, tu dois te poser des questions:
- Que veux-je faire exactement? => empêcher d'autres sites d'utiliser mes pronostics de manière automatique
- Comment puis-je faire? => Je vais créer une image
- Pourront-ils utiliser mon image directement? => non car je vais la protéger par une vérification du referrer
- Pourront-ils utiliser mon image indirectement? => oui... exactement de la même manière qu'avec le script javascript...

Pour moi, la seule différence par rapport au script, si je ne veux pas me prendre la tête avec la reconnaissance d'écriture, c'est que je ne pourrais pas modifier complètement son apparence. Par contre je vais pouvoir modifier ton image par couleur (je vais remplacer le noir par du rouge et le bleu par du jaune par exemple), elle pourra alors se fondre complètement dans ma charte graphique.
Cette solution est-elle satisfaisante? à toi de répondre... :wink:
 
WRInaute accro
jeromax a dit:
je crois qu'avant de te lancer dans ton développement GD, tu dois te poser des questions:
- Que veux-je faire exactement? => empêcher d'autres sites d'utiliser mes pronostics de manière automatique
- Comment puis-je faire? => Je vais créer une image
- Pourront-ils utiliser mon image directement? => non car je vais la protéger par une vérification du referrer
- Pourront-ils utiliser mon image indirectement? => oui... exactement de la même manière qu'avec le script javascript...

Pour moi, la seule différence par rapport au script, si je ne veux pas me prendre la tête avec la reconnaissance d'écriture, c'est que je ne pourrais pas modifier complètement son apparence. Par contre je vais pouvoir modifier ton image par couleur (je vais remplacer le noir par du rouge et le bleu par du jaune par exemple), elle pourra alors se fondre complètement dans ma charte graphique.
Cette solution est-elle satisfaisante? à toi de répondre... :wink:


Bonjour jeromax

J'ai pensé à ça.

Je pense ne plus passer par un appel Ajax au script d'affichage ( = rendant le header de l'image ), mais par un simple lien lien <img src=\"url_script\"> qui appellera le script d'affichage à partir de l'adresse ip de l'hébergement.

Donc... Je pourrai faire un filtrage par l'adresse ip, et les copieurs seront obligés d'être sur la même machine que la mienne, ce qui n'est pas strictement évident, même si je suis en hébergement mutualisé...

Après tout, les copieurs n'iront pas migrer leurs hébergements, simplement pour avoir mes pronostics ?

Et en plus... On ne pourrait pas copier les copieurs.

Merci beaucoup de ta réponse.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
Bonjour

Voilà, j'ai récupéré le code existant, je n'ai plus qu'à convertir l'affichage texte en affichage d'image.

Mon hébergement a GD 2 ( au moins 2.0 ), et FreeType 2.

J'ai l'intention de mettre dans le répertoire courant du script, un ou plusieurs fichiers de fontes ( suffixes *.ttf ), et j'ai remarqué sur mon Linux Fedora 13 64 bits, différentes fontes TrueType qui pourraient convenir. Mais est-ce que j'ai le droit d'utiliser ces fontes pour mon site ?

Pour l'instant, j'ai deux types de fontes : Les fontes Dejavu, et les fontes Liberation.

Sinon, j'ai aussi des fontes du logiciel vlc, mais je préférerais ne pas m'en servir.

Merci beaucoup de m'indiquer si les fontes Dejavu ou Liberation, sont soumises à copyright. ;)

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo
 
WRInaute impliqué
ortolojf a dit:
Je pense ne plus passer par un appel Ajax au script d'affichage ( = rendant le header de l'image ), mais par un simple lien lien <img src=\"url_script\"> qui appellera le script d'affichage à partir de l'adresse ip de l'hébergement.

Donc... Je pourrai faire un filtrage par l'adresse ip, et les copieurs seront obligés d'être sur la même machine que la mienne, ce qui n'est pas strictement évident, même si je suis en hébergement mutualisé...

Après tout, les copieurs n'iront pas migrer leurs hébergements, simplement pour avoir mes pronostics ?
ouh la la non ça ne marchera pas...
il suffira d'appeler "url_script" (de n'importe quel site et de n'importe quelle ip) pour avoir ton image et tes pronostics...
Si ce que je dis ne fonctionne pas alors ça ne fonctionnera pas non plus sur ton site.
 
WRInaute accro
la question à te poser avant de t'embarquer dans de tels développements, qui plus est, qui sont anti ergonomiques au possible, c'est de savoir combien de site(s) ont déjà aspiré tes données. Sont-ce de gros sites ? si oui, tu peux leur faire comprendre qu'en vertu du droit d'auteur (en fait là ça sera celui des bases de données) ils n'ont pas le droit de l'utiliser, sinon voir avec gg pour qu'ils soient grillés au niveau adsense.
Et enfin, intenter une action en référé contre eux, voir plus s'ils sont mal comprenant.
En sachant que pour des personnes ayant réellement envie de récupérer des informations accessibles publiquement sur internet, ils peuvent toujours le faire. Quitte à en faire une partie à la main.
Sous forme d'image ? il suffit d'utiliser un bon OCR
 
WRInaute accro
Merci beaucoup de vos réponses.

Compte tenu du fait qu'en dernier ressort je ne peux pas cacher l'identificateur d'accès envoyé comme paramètre au script d'affichage, je pense que je vais laisser tomber, et ne plus changer mes pronostics en Javascript. ;(

Si quelqu'un sait, comment cacher le paramètre que je suis obligé d'envoyer au script d'affichage, ce serait gentil de me le dire... ;)

Cependant, comme c'est obligatoirement ( dans le cas d'une image ), par la balise <img src="script.php?param=value"> , que je dois appeler le script d'affichage script.php , donc en GET et jamais en POST, je ne vois pas comment je pourrais masquer cet identificateur param=value ... ;(

Même en supposant un procédé de cryptage évolué façon Kerberos, l'adresse ip source de l'appel, serait la même que celle utilisée ensuite par l'autre site pour réappeler le script d'affichage, et la clé publique ( l'identificateur ) serait la même, donc rien de secret.

Merci beaucoup de vos réponses.

Jean-François Ortolo
 
WRInaute accro
Leonick a dit:
la question à te poser avant de t'embarquer dans de tels développements, qui plus est, qui sont anti ergonomiques au possible, c'est de savoir combien de site(s) ont déjà aspiré tes données. Sont-ce de gros sites ? si oui, tu peux leur faire comprendre qu'en vertu du droit d'auteur (en fait là ça sera celui des bases de données) ils n'ont pas le droit de l'utiliser, sinon voir avec gg pour qu'ils soient grillés au niveau adsense.
Et enfin, intenter une action en référé contre eux, voir plus s'ils sont mal comprenant.
En sachant que pour des personnes ayant réellement envie de récupérer des informations accessibles publiquement sur internet, ils peuvent toujours le faire. Quitte à en faire une partie à la main.
Sous forme d'image ? il suffit d'utiliser un bon OCR


Bonjour Leonick

Je n'ai aucun moyen de savoir si des sites copient réellement mes pronostics.

C'est simplement par mesure de précaution.

Merci beaucoup de ta réponse.

Jean-François Ortolo
 
WRInaute accro
ortolojf a dit:
zeb a dit:
pense tu vraiment que ce soit si compliqué que ça ? -http://forum.hardware.fr/hfr/Programmation/PHP/curl-ssl-session-sujet_121387_1.htm#t1856648
Bonjour Monsieur
Ne l'appel pas monsieur, tu va me faire peur :wink:
Bon faut être réaliste, quand on ne peut pas contrer un problème, il faut le tourner en avantage.

Propose aux webmasters un webservices pour afficher tes pronostiques qui est généré par un script avec un lien retour vers ton site.
1/ tu n'aura plus de copieurs puisque ce sera disponible gratuitement.
2/ tu fera monter ta popularité ce qui ne peut faire que du bien a ton site.

Ensuite si tu est capable de proposer ce service avec personnalisation de la forme et des couleurs tu aura tout gagné.
 
WRInaute accro
zeb a dit:
Ne l'appel pas monsieur, tu va me faire peur :wink:

Propose aux webmasters un webservices pour afficher tes pronostiques qui est généré par un script avec un lien retour vers ton site.
1/ tu n'aura plus de copieurs puisque ce sera disponible gratuitement.
2/ tu fera monter ta popularité ce qui ne peut faire que du bien a ton site.

Ensuite si tu est capable de proposer ce service avec personnalisation de la forme et des couleurs tu aura tout gagné.


Bonjour zeb ;)

D'une part, j'ai la flemme...

D'autre part, celà nécessiterait de lancer tout la page des stats, pour générer le pronostic, ce qui serait assez lourd.

Et enfin, j'ai la flemme...

Si je comprend bien, vous me conseillez de virer le Javascript, et de remettre les données texte en clair ?

Après tout, c'est si peu de chose, ces pronostics, par rapport aux moteurs de recherche ( qui ne peuvent pas lire Javascript ). Je peux bien laisser le Javascript, non ?

Merci beaucoup de vos réponses.

Jean-François Ortolo
 
WRInaute accro
Et puis...

D'ici quelques années, je pense rendre mon site payant. A ce moment-là il n'y aura plus de problèmes à priori, si ce n'est que les théoriques copieurs, seront obligés de s'abonner... ;)

Amicalement.

Jean-François Ortolo
 
WRInaute accro
ortolojf a dit:
Je n'ai aucun moyen de savoir si des sites copient réellement mes pronostics.
les sites de pronostics équestres doivent être un petit domaine, ça ne doit pas être dur de faire le tour des sites pour voir si des données sont reprises.

Après, je pense que l'idée de Zeb est à creuser et l'énergie que tu va mettres pour rendre ton site moins ergonomique et bien plus lent avec du ajax et des images, il suffit de la mettre dans la création d'un service pour les autres sites, histoire d'asseoir ta notoriété. Une fois super connu, là tu pourras faire payer sans problème
 
WRInaute accro
Leonick a dit:
les sites de pronostics équestres doivent être un petit domaine, ça ne doit pas être dur de faire le tour des sites pour voir si des données sont reprises.

Après, je pense que l'idée de Zeb est à creuser et l'énergie que tu va mettres pour rendre ton site moins ergonomique et bien plus lent avec du ajax et des images, il suffit de la mettre dans la création d'un service pour les autres sites, histoire d'asseoir ta notoriété. Une fois super connu, là tu pourras faire payer sans problème


Bonsoir Leonick

Mais... Rien ne ressemble plus à un pronostic qu'un autre pronostic.

Même le nombre de Chevaux peut être différent, alors que le pronostic peut être copié. Il suffit d'enlever quelques chevaux.

Et puis, il y a maintenant un très grand nombre de sites de turf, dont ceux payants, pour ceux-là pas moyen de prendre connaissance de leurs pronostics à moins de payer.

Tu m'imagines payer un grand nombre de fois pour savoir si mes pronostics sont copiés ? C'est perdre beaucoup d'argent et chercher une aiguille dans une botte de foin... ;( Sans compter le temps perdu.

Et puis... Si j'obtiens ne serait-ce que quelques sites copiants, certains sites peuvent très bien se copier entre eux, sans me copier moi, alors qu'un seul m'aura copié au total. Contre qui se tourner ? Dans quel but ?

Actuellement, je pense laisser tout tel quel, et ne pas mettre d'images. Il me semble que le chargement se fait aussi rapidement qu'avant, ce qui se comprend, puisque Ajax est asynchrone, et le navigateur met quelques fractions de seconde pour afficher la page, une fois qu'il l'a reçue.

Le service web qu'évoque zeb, est certainement la solution idéale à laquelle je n'avais pas pensé.

Mon côté "pachyderme" et paresseux m'empêche pour l'instant d'y penser sérieusement, mais c'est possible que j'y donne suite à terme... Mais que va devenir ce service web, si mon site devient payant ?

Merci beaucoup de ta réponse.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
ortolojf a dit:
Mais que va devenir ce service web, si mon site devient payant ?
tu n'as qu'à faire comme google map, ils se donnent un délais de 3 mois à partir de l'annonce de changements de conditions (passage au payant) pour que les webmasters aient le temps de se retourner. Tu peux donc faire pareil
 
WRInaute accro
Finalement...

Je pensais qu'il était impossible d'afficher une image autrement qu'avec la balise <img src=... /> , donc en montrant l'identificateur aléatoire paramètre du script.

Je viens de prendre conscience, que je peux utiiser la fonction imagejpg($img) pour celà.

Tout étant en php, je n'ai plus qu'à appeler le script d'affichage par curl, et le script d'affichage se chargera d'afficher pleinement le pronostic, sans que l'identificateur ne soit visible dans le source.

L'identificateur n'étant pas devinable du tout, mes pronostics ne seront pas du tout copiables.

J'ai tout bon ?

Hein, hein, Leonick ? ;)

Bien à vous.

Amicalement.

Jean-François Ortolo
 
WRInaute impliqué
je n'ai pas compris la partie où tu explique l'appel via Curl?
Tu vas bien avoir une image dans ta page non? Comment vas-tu pouvoir empêcher l'appel à cette image depuis un autre site que le tien?
 
WRInaute accro
jeromax a dit:
je n'ai pas compris la partie où tu explique l'appel via Curl?
Tu vas bien avoir une image dans ta page non? Comment vas-tu pouvoir empêcher l'appel à cette image depuis un autre site que le tien?

Bonjour jeromax ;)

Cette image est affichée avec imagejpeg($img) par le script d'affichage ( je pourrais mettre le code php dans le script principal, mais un peu de programmation structurée ne mange pas de pain ;) ).

Je dois donc appeler le script d'affichage dans le script initial qui donne les stats, et affiche le pronostic.

Il me suffit théoriquement de faire un simple include avec le paramètre aléatoire au script d'affichage, c'est vrai que je n'ai pas besoin de curl. ;( L'include étant une instruction php, n'est pas visible dans le source, et donc le paramètre non plus.

Cette image, ne correspondra à aucun code source dans le script initial ( ou le script d'affichage ), vu que tout est en php. L'image est envoyée vers le navigateur par imagejpeg($img);

D'autre part, l'include étant instantané, je peux supprimer de ma bdd l'enregistrement du pronostic, immédiatement après l'include, donc dans tous les cas, il sera impossible de relancer le script d'affichage avec le paramètre, même si celui-ci est connu ( or il ne l'est pas, puisqu'il n'apparaît pas dans le source, et qu'il est aléatoire ).

Reste la possibilité de lancer la page initiale de manière automatique ( Il n'y a plus de Javascript, mais c'est un détail ). Mais... L'image ne correspond plus à aucun code html, elle est simplement affichée avec imagejpeg($img) ... Donc, comment sélectionner cette image pratiquement, pour la reproduire et/ou la mémoriser, et ceci, de manière automatique, à partir de la page téléchargée ?

That is the question... ;)

Merci beaucoup de ta réponse.

Amicalement.

Jean-François Ortolo


PS Je n'ai pas encore mis en place ce nouveau procédé, mes pronostics sont encore textuels.
 
WRInaute impliqué
mais ca signifie que ta page ne contiens qu'une image, rien d'autre, pas de code html, car l'image renvoyée par imagejpeg($img); nécessite que tu change également le header de la page.

Je n'aurais certes aucun paramètre dans l'url de l'image mais rien n'empêche quelqu'un de l'utiliser quand même, ta solution me parait bancale, donne un cas concret et je prouverais qu'aucune solution n'existe :wink:
 
WRInaute accro
jeromax a dit:
je n'ai pas compris la partie où tu explique l'appel via Curl?
non, curl ça sera juste les aspirateurs qui l'utiliseront
jeromax a dit:
Tu vas bien avoir une image dans ta page non? Comment vas-tu pouvoir empêcher l'appel à cette image depuis un autre site que le tien?
oui, il y aura une image, mais il suffit, par exemple, d'enregistrer le contenu dans une variable de session et ensuite, quand l'image sera appelée, d'afficher le contenu correspondant à la session.
Les internautes provenant de sites tiers n'auront pas d'id de session pour son site n'auront donc pas d'affichage
Après, il suffit qu'on aspire le site, qu'on enregistre l'image et qu'on la renvoie (si aspiration effectuée en local) sur le ftp de l'aspirant et le tour est joué :?
 
WRInaute impliqué
de toutes façons, à partir du moment où les infos sont sur le poste du client (et elles le sont obligatoirement si il les voit) alors il est possible de les récupérer, image ou script ou n'importe quoi d'autre.
ok pour mettre l'image en session mais tu vas bien être obligé de l'appeler à partir de ta page html pour l'afficher au milieu de cette même page. Tu vas donc avoir une url visible dans le source qu'il sera possible d'appeler de n'importe où.
Comme le dit Haroeris, met un exemple et on montrera que ça ne marche pas...
 
WRInaute impliqué
@ortolojf: rien à voir mais je trouve bizarre de mettre des photos qui ne sont pas celles de chevaux de courses sur la page d'accueil de ton site: celui du bas est à la limite du Percheron, comme cheval de course on fait plus rapide :lol:
 
WRInaute accro
jeromax a dit:
ok pour mettre l'image en session mais tu vas bien être obligé de l'appeler à partir de ta page html pour l'afficher au milieu de cette même page. Tu vas donc avoir une url visible dans le source qu'il sera possible d'appeler de n'importe où.
non, car si tu ne fais appel qu'aux variables de session, ton appel à image pourrait être <img src="/afficher_stats" ...> et après, ton script afficher_stats.php ira chercher le contenu de la variable de session. Si la variable n'existe pas, il renverra "données inaccessibles, veuillez vous rendre sur le site www.exemple.com (le sien quoi !)
Mais il restera toujours la possibilité de récupérer l'image de la passer à l'ocr et de récupérer les infos pour ajouter à une bdd. Si pas possible de façon automatique, ça sera fait en manuel sur un poste local et pas le serveur
Pas évident de se protéger des voleurs sur le web :evil:
 
WRInaute impliqué
Leonick a dit:
jeromax a dit:
ok pour mettre l'image en session mais tu vas bien être obligé de l'appeler à partir de ta page html pour l'afficher au milieu de cette même page. Tu vas donc avoir une url visible dans le source qu'il sera possible d'appeler de n'importe où.
non, car si tu ne fais appel qu'aux variables de session, ton appel à image pourrait être <img src="/afficher_stats" ...> et après, ton script afficher_stats.php ira chercher le contenu de la variable de session. Si la variable n'existe pas, il renverra "données inaccessibles, veuillez vous rendre sur le site http://www.exemple.com (le sien quoi !)
Mais il restera toujours la possibilité de récupérer l'image de la passer à l'ocr et de récupérer les infos pour ajouter à une bdd. Si pas possible de façon automatique, ça sera fait en manuel sur un poste local et pas le serveur
Pas évident de se protéger des voleurs sur le web :evil:
Si tu appelles la page parente, la variable session sera créée et il suffira ensuite d'appeler afficher_stats.php avec Curl et puis c'est tout. Cela revient au même que ce qu'il a actuellement sur son site avec son script.
 
WRInaute accro
jeromax a dit:
Si tu appelles la page parente, la variable session sera créée et il suffira ensuite d'appeler afficher_stats.php avec Curl et puis c'est tout. Cela revient au même que ce qu'il a actuellement sur son site avec son script.
oui, c'est ce que je disais : contre un script kiddie il arrivera à se protéger, mais après, aucune protection n'existera vraiment et, en plus, ça va détériorer l'usabilité de son site.
 
WRInaute accro
Bonjour

J'ai fait une erreur

Mon propos de tout à l'heure ( mon dernier message ) était que je pouvais afficher l'image par imagejpeg($img) , sans balise <img src=" " />

A la rigueur, on pourrait envisager de simuler le protocole http de génération des headers image/jpeg , Content-Length: etc.... suivi des données de l'image en binaire. Mais çe serait quand même copiable.

Il suffirait que le sniffeur aspire les headers de l'image et le contenu binaire, et intègre le contenu binaire pour reproduire l'image. Donc ça ne marche pas.

L'autre option, avec <img src ... />, suppose que le navigateur client récupère l'image à distance. Celà suppose une connexion http supplémentaire qui prend du temps ( impossible à évaluer combien de temps ). Il suffit que le sniffeur, immédiatement après avoir sélectionné le code <img src ... /> dans le source, appelle l'url du src, pour qu'il ait l'image, avant qu'il ne soit possible de supprimer l'enregistrement du pronostic dans la bdd.

Même en procédant avec un timing calculé au plus près, rien n'indique qui, du navigateur ou du sniffeur, sera le plus rapide à charger l'image... ;(

Quant au Javascript... J'ai pensé à transmettre les données au script d'affichage ( dans un include avec paramètre, donc non visible dans le source ), puis le script d'affichage serait censé afficher les données en Javascript.

Le blème, c'est que les données seraient reçues par le script d'affichage dans une variable php obligatoirement, et devraient être mises dans une variable Javascript ensuite... Et là, lors de cette affectation, les données seraient visibles dans le source du script d'affichage, donc dans le source global.

Si les données étaient cryptées au départ, il faudrait pouvoir les décrypter avec une fonction Javascript, pour qu'au moment du décryptage les données visibles soient celles cryptées... Le blème, c'est que la fonction de décryptage serait visible dans le source, et donc reproductible de manière automatique par un copieur, dans son site récepteur... ;(

Problème : Trouver un système fiable de cryptage/décryptage, valable en php *et* en javascript, et ne permettant ce cryptage/décryptage, qu'une seule fois, même en ayant tous les éléments dans le source.

C'est le seul problème à résoudre.

Le seul moyen de résoudre le problème.

Si vous avez la réponse à cette question... ;)

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
Sinon...

Ce que je pourrais faire...

Simuler dans le script d'affichage lancé par Javascript, le header image/jpeg , puis le header Content-Length : , puis les données binaires envoyées directement au navigateur.

Mais... A ce moment-là effectivement, si les moteurs de recherche n'interprètent pas le Javascript, le contenu du site resterait indexable.... Mais si un ou des moteurs de recherche se mettent à interpréter le Javascript, à ce moment-là le contenu ne serait plus indexable, car brouillé avec du binaire, et là bonsoir...

Ma question : Comment envoyer le contenu binaire de l'image au navigateur, et est-ce que ce serait possible de simuler le protocole http pour enviyer cette image, sans passer par une balise <img src="... " /> ?

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
au lieu de te prendre la tête pour une aléatoire protection mais une vraie gène pour les internautes, ça te serais plus profitable de développer un service web à proposer à certains autres sites, histoire de te faire connaitre
 
WRInaute impliqué
oui ou attendre que quelqu'un te pique des pronostics pour y réfléchir à ce moment là, mais tu ne pourras rien faire contre quelqu'un de déterminer de toutes façons.
L'avantage que je vois à chercher une solution, c'est que tu vas monter en compétences techniques... :D
 
WRInaute impliqué
Leonick a dit:
au lieu de te prendre la tête pour une aléatoire protection mais une vraie gène pour les internautes, ça te serais plus profitable de développer un service web à proposer à certains autres sites, histoire de te faire connaitre

Oui c'est ce que je disais, avoir la stratégie inverse et prendre les devant : proposer une api qui génère un liens vers son site, ainsi il y gagnera.
 
WRInaute accro
jeromax a dit:
oui ou attendre que quelqu'un te pique des pronostics pour y réfléchir à ce moment là, mais tu ne pourras rien faire contre quelqu'un de déterminer de toutes façons.
L'avantage que je vois à chercher une solution, c'est que tu vas monter en compétences techniques... :D


Bonjour jeromax ;)

Déjà, j'ai reçu du code du newsgroup fr.comp.lang.php pour envoyer des images *.jpeg sous forme binaire en base64 aux navigateurs.

Le blème, c'est que le contenu binaire des images, ne peut qu'être visible dans le code html, et donc reproductible. Je suis en train de me renseigner si ce ne serait pas possible de crypter/décrypter le contenu binaire, pour qu'il ne soit plus interprétable.

En tout cas, ce procédé me permettrait de faire du code synchrone, et donc de supprimer l'enregistrement du pronostic immédiatement après son affichage. Mais le code source pourrait quand même être copié...

Sinon, un mix du Javascript et d'une image binaire conviendrait, mais le Javascript serait nécessairement asynchrone ( par le poste client ), et le Javascript parsable, donc simulable, donc le problème demeure entier. ;(

Merci beaucoup de vos réponses.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
Haroeris a dit:
Oui c'est ce que je disais, avoir la stratégie inverse et prendre les devant : proposer une api qui génère un liens vers son site, ainsi il y gagnera.


Bonjour Haroeris ;)

Une telle api , je n'ai rien contre, si ce n'est que je devrais avoir une pleine confiance envers ceux à qui je lui donnerais accès.

Après, si le login/password et l'url passent de mains en mains, bonsoir...

A ce compte-là, tous les turfistes auront accès à mes pronostics sans passer par mon site, il leur suffira de mettre l'url dans leur navigateur, et puis bonsoir. ;(

Merci beaucoup de vos réponses. ;)

Amicalement.

Jean-François Ortolo
 
WRInaute accro
ortolojf a dit:
A ce compte-là, tous les turfistes auront accès à mes pronostics sans passer par mon site, il leur suffira de mettre l'url dans leur navigateur, et puis bonsoir. ;(
pour l'instant, qu'est ce que ça te rapporte que les turfistes passent par ton site, à part bouffer de la bande passante ? rien !
Donc étape 1 : faire connaitre ton site. L'api est un excellent moyen (sous réserve que tu fasses afficher ton logo et un lien pour arriver directement sur ton site). Genre API gratuite pendant 3 ou 6 mois.
Une fois la reconnaissance de la qualité des infos en provenance de ton site, tu devrais voir ton nombre de visiteurs (surtout réguliers) augmenter et là, tu pourras proposer (aussi) une version payante avec des prestations auxquelles les simples visiteurs ne pourront accéder.
 
WRInaute accro
Et puis... Si j'obtiens ne serait-ce que quelques sites copiants, certains sites peuvent très bien se copier entre eux, sans me copier moi, alors qu'un seul m'aura copié au total. Contre qui se tourner ? Dans quel but ?

Il faut croire que tu n'a jamais lu un "acces_log" ou alors tu patine dans la semoule. Pister un site qui te pompe un truc n'a rien de difficile. tout d'abord quand c'est un serveur qui te pompe un truc, il n'a pas une connections genre Free ou Nanadoo donc ça laisse des traces visibles au niveau des IP (et tu dois pas faire 10 000 VU jour donc c'est pas la mer a boire) ensuite il est rare que le referer soit propre et logique donc autre axe de recherche, ensuite son useragent est souvent différent donc là encore tu peut avoir des infos.

Pour le cas ou les logs soit pas ta tasse de thé, met donc une info bidon dans ton contenu (genre un mot qui n'éxiste pas (suite de caractère aléatoire et fixe)) qui affiché en vert sur vert par exemple, ne va pas plomber ton ref mais en tous cas qui va constituer un marqueur valide pour une recherche google de copie.
exemple : imagine que dans ta page il y ai le mot MangoustineScatophage (c'est le nom d'un itinéraire d'escalade dans le canyon du verdon dont je me servais pour faire des test SEO) tu sera le seul a voir ce mot dans tes pages et une simple recherche google te permettra d'identifier les sites qui te copies en aveugle.

Ensuite t'aura plu qu'a les blacklister sur le serveur en hta ou php

Bref ... trivial

ensuite ton histoire de crypto et de header c'est bidon intégral car tu ne peut pas avoir deux header dans ta page donc envoyer un entête image dans la page avec ton include ça fonctionne pas.
Mais au de la de cela dit toi bien que si un utilisateur légitime voie ton contenu un bot peutle voir et cela tu n'y peu rien session ou pas.
Je trainais fut un temps sur un site de jeu qui protégeait ses pages avec les sessions, il m'a fallu une journée pour écrire un bot qui se connectait récupérait un ID de session valide et faisait la basse besogne a ma place.

Le seul truc dans cet ordre d'idée qui pourrait être valable serait de surclasser le navigateur du visiteur en imposant un visualisateur dédié a tes pronostiques (bref faire fuire tes visiteurs)

Je pense que tu est a la charnière avec ton site, il faut que tu arrête de pense "gagne petit" (le prend pas mal c'est imagé surtout) et que tu passe a l'age adulte en développant du code vraiment utile tout en appelant a la rescousse un designer pour arranger le truc.
A ta place je penserai API et webservices, toolbar turfiste pour firefox, services gratuit et payant, monétisation des pages, forum turfistes, annuaire turf, ... bref je passerai a l'ère industrielle, beaucoup plus sympa que le bidouillage online.
 
WRInaute accro
zeb a dit:
Il faut croire que tu n'a jamais lu un "acces_log" ou alors tu patine dans la semoule. Pister un site qui te pompe un truc n'a rien de difficile. tout d'abord quand c'est un serveur qui te pompe un truc, il n'a pas une connections genre Free ou Nanadoo donc ça laisse des traces visibles au niveau des IP (et tu dois pas faire 10 000 VU jour donc c'est pas la mer a boire) ensuite il est rare que le referer soit propre et logique donc autre axe de recherche, ensuite son useragent est souvent différent donc là encore tu peut avoir des infos.

Pour le cas ou les logs soit pas ta tasse de thé, met donc une info bidon dans ton contenu (genre un mot qui n'éxiste pas (suite de caractère aléatoire et fixe)) qui affiché en vert sur vert par exemple, ne va pas plomber ton ref mais en tous cas qui va constituer un marqueur valide pour une recherche google de copie.
exemple : imagine que dans ta page il y ai le mot MangoustineScatophage (c'est le nom d'un itinéraire d'escalade dans le canyon du verdon dont je me servais pour faire des test SEO) tu sera le seul a voir ce mot dans tes pages et une simple recherche google te permettra d'identifier les sites qui te copies en aveugle.

Ensuite t'aura plu qu'a les blacklister sur le serveur en hta ou php

Bref ... trivial

ensuite ton histoire de crypto et de header c'est bidon intégral car tu ne peut pas avoir deux header dans ta page donc envoyer un entête image dans la page avec ton include ça fonctionne pas.
Mais au de la de cela dit toi bien que si un utilisateur légitime voie ton contenu un bot peutle voir et cela tu n'y peu rien session ou pas.
Je trainais fut un temps sur un site de jeu qui protégeait ses pages avec les sessions, il m'a fallu une journée pour écrire un bot qui se connectait récupérait un ID de session valide et faisait la basse besogne a ma place.

Le seul truc dans cet ordre d'idée qui pourrait être valable serait de surclasser le navigateur du visiteur en imposant un visualisateur dédié a tes pronostiques (bref faire fuire tes visiteurs)

Je pense que tu est a la charnière avec ton site, il faut que tu arrête de pense "gagne petit" (le prend pas mal c'est imagé surtout) et que tu passe a l'age adulte en développant du code vraiment utile tout en appelant a la rescousse un designer pour arranger le truc.
A ta place je penserai API et webservices, toolbar turfiste pour firefox, services gratuit et payant, monétisation des pages, forum turfistes, annuaire turf, ... bref je passerai a l'ère industrielle, beaucoup plus sympa que le bidouillage online.


Bonjour zeb ;)

J'ai regardé les logs d'aujourd'hui, et fait des egrep -v.

Le seul site susceptible de copiage, est un site situé sur le réseau oleane de Orange. Probablement le pmu lui-même.

Dans un premier temps, il a adopté un nom de navigateur facile à repérer, puis il a adopté le nom "AppleWebKit" sous la même adresse ip, tout en réussissant à lire les données.

Je n'ai rien à cacher au pmu, il veut simplement savoir si je n'utilise pas des marques déposées, ce qui n'est pas du tout le cas.

Pour le mot-clé en vert sur vert, je peux effectivement le mettre en affichage désactivé, mais pas simplement en vert sur vert, sinon le mot-clé va occuper de l'espace sur les données... ;( Je vais me pencher sur la question prochainement, c'est une piste à creuser sérieusement. ;)

En ce qui concerne l'image par header, c'est possible, il suffit de mettre au début du script : ob_start(); et à la fin du script : ob_flush(); , pour que toute la page soit envoyée en même temps.

Mais... Je ne sais pas comment faire en sorte que le script d'affichage "sache" la clé d'accès au pronostic, sans avoir à lui transmettre cette clé en Javascript dans le source... C'est le seul problème.

Sinon, je sais comment générer une image avec du binaire encodé en base64, ça ne mange pas de pain. ;)

Pour le reste de ta contribution, que j'apprécie beaucoup pour son professionnalisme, je ne peux pas gagner de l'argent pour l'instant, tant que je n'ai pas diminué les frais fixe en achetant un logement à moi, ce qui sera possible à terme, pour raison d'héritage.

En effet, qui dit revenus dit entreprise, donc plus d'allocation A.A.H. ou A.P.L. ni allocation d'autonomie, donc 1050 euros en moins par mois, sans compter les surloyers à prévoir de mon logement conventionné...

Je remet le passage de mon site au mode payant, après cet achat de logement... A ce moment-là, je testerai la mise en payant pendant un an de janvier à Décembre, pour voir si je peux en vivre, tout en vivant durant l'année sur l'alloc que j'aurai encore, et l'année suivante je vivrai sur les revenus économisés, jusqu'au retour de l'alloc l'année d'après si ça ne marche pas.

Je sais que les revenus sont exonérés si l'on est inscrit à l'ANPE, mais je pense que si je m'inscris à l'ANPE, je suis sûr d'être viré, compte tenu de la politique de cette boîte, qui a tendance à virer facilement dès que l'on refuse une formation.

Pour les API et webservices, ce ne seraient que des moyens de ne pas utiliser mon site, ou de trouver le moyen de passer à travers les paiements du service. Je pense celà, car je n'ai pas confiance dans mes capacités à sécuriser pleinement les accès à ces prestations.

Quant au forum, effectivement je pourrais, même dès maintenant, celà pourrait être productif en fidélisant beaucoup les clients... Mais je pense que moi-même, je ne suis pas très communicant, et je ne me sens pas capable de séduire par mes apports à ce forum.

Ma position à ce sujet peut changer, puisqu'un forum par nature, reçoit les contributions de tous ses participants, mais cela représenterait un travail constant et très prenant. Il est vrai que celà en vaut la chandelle, mais en matière de productivité, je pense qu'il y a mieux.

Quant à un designer, franchement j'ai un peu peur de confier le design de mon site au premier venu.

Surtout, que je ne vois pas très bien quoi changer, à part les couleurs, qui me paraissent très bien, car reposantes et attirantes... Peut-être un peu plus de variété ne gênerait pas.

Merci beaucoup beaucoup de ton avis, je tiendrai certainement compte de plusieurs de ses éléments, dans un avenir que j'espère proche. ;)

Amicalement.

Jean-François Ortolo
 
WRInaute accro
ortolojf a dit:
Quant à un designer, franchement j'ai un peu peur de confier le design de mon site au premier venu.

Surtout, que je ne vois pas très bien quoi changer, à part les couleurs, qui me paraissent très bien, car reposantes et attirantes...
Peur de quoi ?

Ça peut difficilement être pire qu'actuellement. Et si tu ne vois pas de problème, accorde un peu de confiance à ceux qui te conseillent.

zeb n'est pas le premier à te dire qu'il y a un os à propos du design :?
 
WRInaute accro
Bonjour

J'ai trouvé un truc pour attraper les copieurs.

A partir de maintenant, je loggue les adresses ip de toutes les aspirations suspectes.

J'irai à la pêche des ip demain matin... ;)

Amicalement.

Jean-François Ortolo
 
WRInaute accro
ortolojf a dit:
Pour le mot-clé en vert sur vert, je peux effectivement le mettre en affichage désactivé, mais pas simplement en vert sur vert, sinon le mot-clé va occuper de l'espace sur les données... ;( Je vais me pencher sur la question prochainement, c'est une piste à creuser sérieusement. ;)

Bof...

Les pronostics ne sont pas dans le source, et les moteurs de recherche n'interprètent pas le Javascript.

Donc, je ne peux pas mettre des mots-clé spécifiques dans les pronostics.

Bien à vous.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
Zecat a dit:
y s'rai pa sun peu parano notre orto :roll: :mrgreen:


Bonjour Zecat

Effectivement...

Si ça se trouve, mon psychiatre a déjà pensé à ça. ;)

Y peut toujours me dire que je suis dépressif, il dirait la même chose en cas de parano, alors...

;)

Bien à vous.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
Leonick a dit:
pour l'instant, qu'est ce que ça te rapporte que les turfistes passent par ton site, à part bouffer de la bande passante ? rien !
Donc étape 1 : faire connaitre ton site. L'api est un excellent moyen (sous réserve que tu fasses afficher ton logo et un lien pour arriver directement sur ton site). Genre API gratuite pendant 3 ou 6 mois.
Une fois la reconnaissance de la qualité des infos en provenance de ton site, tu devrais voir ton nombre de visiteurs (surtout réguliers) augmenter et là, tu pourras proposer (aussi) une version payante avec des prestations auxquelles les simples visiteurs ne pourront accéder.


Bonsoir Leonick

Je vois bien ce genre d'API: Un simple script php prenant en paramètre un code : $today_tomorrow = 0 pour courses du lendemain/après-midi, ou 1 pour les courses du soir ou de la veille, ainsi que le numéro de réunion, et le numéro de course, et qui rende quand il est appelé avec 0, -1 et -1, une array à deux indices donnant le nombre total de courses, plus les numéros des réunions et des courses associées, en indices 0 et 1.

ainsi, si $tmp est l'array globale reçue dans ce cas, on aura :

$ind_max = $tmp[0][0] = nombre total de courses sur l'ensemble des réunions.

$tmp[1][0] = numéro de la réunion de la 1ère course de la 1ère réunion.
$tmp[1][1] = numéro de la 1ère course de la 1ère réunion.

A charge pour le webmaster utilisant cette api, de parcourir toute l'array $tmp de $tmp[1][0] et $tmp[1]1] à $tmp[$ind_max][0] et $tmp[$ind_max][1] pour en faire ses choux gras. ;)

Ensuite, pour avoir les pronostics d'une réunion et d'une course, il suffira d'appeler le script contenant l'API, avec les paramètres $today_tomorrow ( 0 ou 1 ), $num_reunion et $num_course, sachant que des valeurs hors normes rendraient null en retour.

Ajoutons un petit login et password pour faire bonne mesure ( plusieurs logins et passwords possibles de préférence ).

Les paramètres devront obligatoirement être envoyé en mode post. Pour la sécurité, j'aurais besoin de vos avis éclairés. ;)

Le script appelle tout simplement un équivalent de la page de stats, qui alimente le pronostic, rendu sous forme d'une array cette fois-ci à un seul indice :

$ind_max = $tmp[0] = nombre maximum de chevaux du pronostics, d'indices 1 à $ind_max

$num_partant = $tmp[$i] pour $i dans [1, $ind_max] , $tmp[$i] est le numéro de partant prévu du cheval de rang $i.

Je n'ai plus qu'à me plonger dans la programmation.

J'envisage celà comme quelque chose ne devant pas déboucher sur une application réelle, mais sait-on jamais...

Merci beaucoup, Leonick, pour ton avis.

Je sais que les Wrinautes sont très compétents et très gentils.

Merci beaucoup.

Jean-François Ortolo
 
WRInaute passionné
Hello

je pense que tout ceci est un faux problème qui te coûte du temps et de l'attention au lieu de développer ton site.
Je ne vais pas redire ce qu'ont dit Zed par exemple, mais franchement, c'est difficile de différencier un (bon) robot d'un internaute qui clique beaucoup.
Par exemple sur WRI, j'ouvre minimum une 10aine d'URLs en 1 seconde, et je les lis une par une par la suite. Vais-je être identifié comme un robot par ton script ?

Bref, avance sur ton site plutôt que de regarder derrière ton épaule. Tu peux intégrer des astuces pour contrer le copiage simple, mais il ne faut pas trop se creuser la tête ... tu pourrais perdre un % d'internautes qui ne rentrent pas dans les clous de ton algorithme. Dommage ?

lolo
 
WRInaute accro
il ne faut pas que le site distant puisse récupérer et mettre en cache les données. Le but du "jeu" étant qu'à chaque visiteur, ils fassent un appel à ton api, comme cela tu pourras connaitre le nombre de visiteurs de chacun des sites distants et ainsi avoir une estimation du volume de personnes qui pourraient être intéressées par tes services
 
WRInaute accro
Leonick a dit:
il ne faut pas que le site distant puisse récupérer et mettre en cache les données. Le but du "jeu" étant qu'à chaque visiteur, ils fassent un appel à ton api, comme cela tu pourras connaitre le nombre de visiteurs de chacun des sites distants et ainsi avoir une estimation du volume de personnes qui pourraient être intéressées par tes services


Bonjour Leonick

Cela veut dire, que l'affichage ne peut être fait qu'en Javascript comme actuellement, pour que les données ne soient pas "sniffables".

C'est le même problème qu'auparavant, si ce n'est qu'avec l'api, les webmasters disposeront de manière viable du moyen pour afficher les données sur leurs sites. Et si les webmasters n'ont pas leur login/password, de toute manière ils n'auront pas accès à l'api.

J'ai pondu un premier jet, affichant les numéros des Réunions et Courses, ou le nom du script appelé.

L'url est la suivante :

-http://www.pronostics-courses.fr/php/courses_nouvelles/tmp_new_api.php

Prochainement, le script indiqué sera vraiment lancé, et les données seront accessibles.

Bien à vous.

Amicalement.

Jean-François Ortolo
 
WRInaute accro
Bonjour

Voilà, les données sont accessibles à qui veut en Javascript.

L'url est : -http://www.pronostics-courses.fr/php/courses_nouvelles/api_courses.php

Sans paramètre, le mode d'emploi s'affiche.

Avec indic_date=0 et reunion=0 et/ou course=0 ( les deux doivent être alimentées ), vous avez les correspondances entre les réunions et les courses, pour les courses du lendemain.

Avec indic_date=1, ce sont les courses du soir.

Vous pouvez choisir la reunion et la course.

Il n'y a pas de restrictions d'accès pour l'instant.

Bien à vous.

Amicalement.

Jean-François Ortolo
 
WRInaute passionné
Tu peux simplement, bannir sur le port 25 tous les serveurs "OVH" 91.121.*.* 188.165.*.*
ça limitera déjà un paquet de potentiel sites français, ça ne bloquera pas les moteurs de recherche (peu de français hébergés chez OVH).

Après tu peux frauder, leurs parsers repèrent des chaines dans ta page et les parses. Tu peux mettre des fonctions "aléatoire" pour changer un peu ton code là où c'est intéressant.
Si le gars doit mettre son parseur à jour toutes les 10 minutes, ça va vite lui casser les bonbon.

Autre solution tu peux vérifier la présence du javascript sur le navigateur, si pas présent, tu n'affiches pas. C'est ce que fait par exemple facebook :
Code:
curl -v https://www.facebook.com
< HTTP/1.1 302 Found
< Location: https://www.facebook.com/common/browser.php
 
WRInaute accro
Julia41 a dit:
Autre solution tu peux vérifier la présence du javascript sur le navigateur, si pas présent, tu n'affiches pas. C'est ce que fait par exemple facebook :
Code:
curl -v https://www.facebook.com
< HTTP/1.1 302 Found
< Location: https://www.facebook.com/common/browser.php


Bonsoir Julia41

Mais... Comment détecter si le Javascript est activé ou non ?

C'est sûr que je peux utiliser la balise <noscript> </noscript> , mais c'est sur le poste client que ça se passe, pas sur le serveur.

Un fois que le code source est sur le poste client, pas moyen de le changer...

Merci beaucoup de ta réponse.

Amicalmeent.

Jean-François Ortolo
 
WRInaute accro
ortolojf a dit:
Cela veut dire, que l'affichage ne peut être fait qu'en Javascript comme actuellement, pour que les données ne soient pas "sniffables".
non, il suffit que tu le mettes dans tes CGU pour les webmasters. L'api serait appelée via un iframe. Pour utiliser moins de ressources de ton serveur, il te suffit de mettre les réponses en cache, mais comme cela tu sauras combien de visiteurs voient tes infos depuis chacun des sites autorisés.
 
WRInaute accro
Leonick a dit:
ortolojf a dit:
Cela veut dire, que l'affichage ne peut être fait qu'en Javascript comme actuellement, pour que les données ne soient pas "sniffables".
non, il suffit que tu le mettes dans tes CGU pour les webmasters. L'api serait appelée via un iframe. Pour utiliser moins de ressources de ton serveur, il te suffit de mettre les réponses en cache, mais comme cela tu sauras combien de visiteurs voient tes infos depuis chacun des sites autorisés.


Bonsoir Leonick

C'est la même chose... ;(

Si le code d'appel du pronostic figure dans l'iframe, l'url avec le paramètre est dans le code source, et il suffit de le relancer directement à distance après avoir parsé le code source... Immédiatement après chargement de la page initiale...

Effectivement, dans ce cas, l'affichage ne se voit pas dans le code source lors du premier appel de la page initiale, mais l'url, si.

Et... Comme l'iframe, par définition, c'est sur le poste client que ça se passe, il n'y aucun moyen de supprimer l'enregistrement du pronostic en amont, vu que le pronostic doit être chargé par le code source sur le poste client, après que le script initial soit terminé.

Même problème que pour le Javascript d'ailleurs, où le code source est visible.

Histoire de rire, que pensez-vous de l'apparence de mes pronostics avec l'api ? ;)

Amicalement.

Jean-François Ortolo
 
WRInaute accro
pour l'instant tu ne sais pas si quelqu'un tente d'aspirer ton site. Donc laisse tomber la protection. Vérifie les stats des connexions sur ton api pour voir s'il y a un intérêt à tenter de bloquer l'utilisation.
Le but initial est d'élargir ta base utilisateurs, qu'ils soient de ton site ou d'autres.
Avantage de l'iframe : ça te fait des BL supplémentaires
Moi je partirais du principe de ne rien bloquer du tout, au début, histoire d'avoir des données sur les utilisateurs.
Ensuite, tu vérifies les "utilisateurs" récurrents : combien de fois par jour se connectent-ils sur ton api, est-ce une ip de serveur, etc...
A ce moment là, tu pourras chercher des méthodes de protection
 
WRInaute accro
Leonick a dit:
Avantage de l'iframe : ça te fait des BL supplémentaires
Moi je partirais du principe de ne rien bloquer du tout, au début, histoire d'avoir des données sur les utilisateurs.
Ensuite, tu vérifies les "utilisateurs" récurrents : combien de fois par jour se connectent-ils sur ton api, est-ce une ip de serveur, etc...
A ce moment là, tu pourras chercher des méthodes de protection



Bonsoir Leonick

A propos des BL...

il me semble, que le lien sur mon pronostic api, n'est pas dans le source.

Se pourrait-il, que les moteurs de recherche chargent les iframes quand même ?

Si c'est le cas, effecftivement c'est un plus très intéressant d'utiliser un iframe... ;)

J'ai converti mon api en iframe.

Je vais tout de suite convertir mon site en iframe aussi, puisque c'est comme ça...

Et plus besoin de Javascript... ;)

Merci beaucoup beaucoup de ton aide.

Très amicalement.

Jean-François Ortolo
 
WRInaute passionné
JF,

une petite question, tout ceci, ça ne va pas à l'encontre de ton référencement ?
je veux dire : est-ce que tes pages sont indexables, y compris le contenu que tu veux protéger, si tu veux l'indexer bien sur.

Lolo
 
WRInaute accro
loran750 a dit:
JF,

une petite question, tout ceci, ça ne va pas à l'encontre de ton référencement ?
je veux dire : est-ce que tes pages sont indexables, y compris le contenu que tu veux protéger, si tu veux l'indexer bien sur.

Lolo


Bonsoir loran750

Ben... Leonick dit que les iframes permettent les BL. ;)

Cela suppose que les moteurs de recherche chargent les iframes...

Dans mon cas, c'est possible, théoriquement.

Mais, est-ce le cas réellement, je ne sais pas...

Bien à toi.

Amicalement.

Jean-François Ortolo
 
WRInaute impliqué
Sinon tu peux créer ton api en code serveur (genre php): de cette manière chaque site qui utilise ton api aura un login et password, qu'il passe en paramètre de l'url. Les visiteurs ne sauront même pas que le site utilise ton api.
Me site aura juste à faire un include("http://lelienverstonapiaveclesbonsparametres+login+pwd") dans leur site et c'est tout. Toi tu leur envoie tes pronostics sous forme de tableaux et eux se débrouille pour les mettre en forme. De cette manière ils peuvent vraiment intégrer tes pronostics dans leur page. Par contre il faut qu'ils aient relativement confiance en toi :)
 
Discussions similaires
Haut