Reprise du message précédent :

c'est ce que j'essaie de dire depuis le début mais personne m'écoute

 
coté client, je ne peux opérer qu'en JS, j'ai pas la main sur leur serveur pour mettre du php et eux ne veulent certainement pas que je mette un fichier php sur leur serveur.
 
tout ce qu'il a à faire pour afficher les bannières c'est copier/coller un bout de code sur sa page html où il veut l'afficher
ex: <script language = 'javascript' src="ad.mondomaine.com/showad.php?numeroclient=123"</script>
 
le reste doit être entièrement transparent...
 
ça tourne en rond en effet...

Sans avoir la main sur leur serveur, tu fournis le fichier, il l'installent et ajoutent dans leus pages un <?php affiche_ad(id_client);?> c'est tout.
 
Le javascript ne fonctionne pas sur le serveur du client mais sur la machine du visiteur.
 
Si tu ne peux pas faire cela, la meilleure méthode est donc de simplement leur fournir le lien <img src="ad.mondomaine.com/showad.php?numeroclient=123"> et de te débrouiller avec  
- $_SERVER['HTTP_REFERER']  
- $_SERVER['HTTP_USER_AGENT'] (si ton client cherche à incrémenter son compteur à partir d'un serveur par script, il sera vide)
- de vérifier l'IP qui accède au script (en l'occurence tout sauf l'IP du client)

Tant que tu n'utilises que des technologies clientes comme le Javascript tu n'auras aucune sécurité. Il n'y a pas à débattre la-dessus.
 
Si tu n'as pas la main sur les serveurs de tes clients tu ne pourras pas faire de solution sécurisée.

bon, j'ai fait des derniers tests.
je n'appelle plus coté client qu'un JS de ce type:
 

 
phase1
salt.php génère du JS en sortie: 2 variables,1 fonction,et un appel à la superbe fonction showad.php?, toujours en JS mais en passant en paramètre les 2 variables précédentes:
- 1 variable qui contient une clé aléatoire
- 1 variable qui récupère la page où est affichée le JS en cours (puisqu'elle est définie coté client, on ne peut pas prédire coté serveur sa valeur qu'APRES avoir généré la page)
 
phase2
- la première variable est fixe au niveau du client (mais générée aléatoirement coté serveur), mais il ne peut prédire sa valeur
- la 2e est set-ée par le client: c'est l'url de sa page
- le code JS généré par le salt.php est du type
 
phase3
<script language = "javascript" src ="ad.mydomaine.com/showad.php?var1=VALEURCRYPTEE1&var2=VALEURCRYPTEE2"></script>
 
je rappelle: VALEURCRYPTEE1 et VALEURCRYPTEE2 sont générées à la volée et les fonctions qui la génèrent sont coté serveur.
 
ce dernier script vérifie la cohérence des valeurs passées en paramètre avec l'algorythme de décryptage certes symétrique mais comme elles sont coté serveur, un XOR avec un bon fichier texte en entrée fait l'affaire.
 
 
>>> VALIDATION:
quand je le lance à partir d'un fichier html, ça marche bien (la bannière s'affiche)
 
si je tape ad.mondomaine.com/salt.php&client=123 sur l'url d'ie
> quedale, ça envoie petre.
fichier > afficher source > ça te donne le source javascript généré en php, mais déjà il n'y a pas de retour à la ligne,
mais le passage des variables est tellement imbriqué que même moi qui est foutu le code j'y comprend plus rien!    
 
>après avoir decrypté mon propre code pendant 45 minutes, j'ai enfin le JS propre et on voit comment sont passés les variables
>je recompose donc une URL dans mon browser avec du copier/commer de http://...showad.php?var1=valeurcryptée1&var2=...
 
ce qui devrait marcher en effet...
 
mais non    
 
le timestamp a déjà changé coté serveur, et hop, tu dois repartir sur un calcul qui te prend 10 minutes... et en gros tu ne pourras jamais prédire les valeurs de var1 et var2 donc tu ne pourras jamais recomposer l'url.
 
vous suivez ?
 
je refais un peu le tour et je vous balance l'url pour un test grand public ?    

Lance toujours l'url, on verra bien

Il est tetu quand même

tétu, ou borné

je n'ai pas le choix    je ne peux faire que du JS coté client.
faut pas trop leur prendre la tête...
 
je sais c'est pas 100% secure mais si tu désactives JS ben pas de bannière, c'est pas grave      
 
 
voici le script (toutes les variables ne sont pas encore cryptées)
en tête de page de mon site:

>
 
et voici le résultat:
http://www.tsenagasy.com/forum/portal.html (tout en haut)
 
le but est donc de taper en dur une URL dans IE pour afficher le même résultat.
 
à vos claviers  
 
edit: en plus je vous aide vachement, vous avez déjà le numéro id client: "clid=MTExLTExMQ=="

moi je vois toujours pas l'intérêt...

Il n'y a pas de bandeau de pub  
Edit: c'est mon firewall qui bloque toutes les url qui commencent par ad. donc ton 1er script n'est pas exécuté. Mon passage n'est pas comptabilisé
 
et ce code html :  

 
Un peu fait n'importe comment non  

http://ad.tsenagasy.com/showad.php [...] nagasy.com
 
Pour avoir le bandeau direct

Avec 12 bandeaux en stock
 
Edit : ah l'orthographe ...  

 
   
 
 
attend que je crypte les variables et tu vas voir    
 
>> le code est pas propre, ye sé, yé pas le temps de le nettoyer

J'attends

sinon à part ça, que pensez vous du concept ?
ce n'est ni au CPM, ni au CPC mais au "CPV", j'ai nommé 'cout par visite'
 
vu les tarifs des CPM (pas interessants du tout pour les Editeurs), et le faible rendement des CPC (de toute façon ils prennent de la place même si personne ne clique)
 
> ma régie au CPV comporte un compteur de visites sur la page où sera affichée la bannière. on compte environ 1ct d'€ le visiteur.
coté annonceur, il définit un budget pub qu'il peut créditer à tout moment pour commencer l'affichage de sa bannière sur les sites affiliés.
 
résumé: les sous que misent les annonceurs sont reversés aux éditeurs affiliés et au passage je prend une comm..    
 
---
 
ça n'a rien d'original jusque là mais ça devient interessant quand on rentre dans le vrai concept:
la publicité communautaire.
En gros, c'est pas interessant pour des sites comme HFR, ou des gros sites fourre-tout.
les sites interessés sont les sites qui connaissent déjà une cible particulière:  site de bretons, site de bordelais truc muche,  
 
par exemple chez les chinois du 13e là, il font bien des trucs où il n'y a que des chinois mais personne d'autre n'est au courant    à part connaitre les tuyaux chinois (sites chinois ça doit bien exister et je suis sur qu'ils sont hyperfréquentés... par des chinois bien sur).
 
idem pour nous les malgaches, si on veut faire de la pub pour une manifestation culturelle malgache par exemple > le meilleur endroit du web c'est un site malgache.
et c'est là que ma régie entre en jeu: libérer les webmasters de ces communautés de la gestion de leurs annonces et permettre aux annonceurs d'avoir
- un point d'entrée unique pour la diffusion de leur pub
- un espace de redirection de leur bannière (car annonceur n'est pas forcément webmaster et n'a pas forcément de site donc je leur fourni gratuitement un espace où ils peuvent mettre en page quelques photos et quelques textes à partir d'un bete formulaire)
 
 

bon, on reprend depuis le début    
 
voici un exemple de code php:

 
but:
générer un JS qui récupère l'url courante et la réinjecte dans le script appellant.
 
pourquoi le document.location.href il est pas interprété ?  

est ce que cette partie est affichée chez le client. Sinon, ce ne sera jamais interprété.

oui elle est bien affichée mais ça reste 'doc' et non pas la variable.
 

bon ça y est, ça marche, que pensez vous de cet autre moyen: on crée des tickets aléatoires à usage unique et à acquittement:
 
- coté php, on génère aléatoirement une variable JS qui contient une clée:  
 

 
Puis on écrit cette clée dans une base de donnée (émission du ticket)
 
- coté JS, on récupère l'url du browser avec document.location.href, on le parse pour avoir le nom de domaine:
 

 
- coté JS toujours, on crée une fonction de cryptage et on crypte 'var domaine' avec 'var key':
 

 
puis on appel en JS "showad.php?key=...&Cypher=... (retour du ticket)
 
- coté php (showad.php), avec la clée on decrypte,et on détruit le ticket ecrit dans la base. En ayant pris soin bien entendu que la 'key' existe bien auparavant avant de faire un traitement.
 
----
 
résultat des courses:
- la 'key' est non prédictible, aléatoire, et à usage unique
- la fonction de cryptage est réversible certes, coté JS la lecture donne la fonction de decryptage, mais tu ne connais pas la valeur de la prochaine clée.
- l'émission d'une clée engendre directement sa destruction dans la ligne d'après
- tenter d'appeler directement le showad.php?key=... échoue forcément parce que tu ne connais pas la clée, elle n'a pas encore été générée.
 
 

C'est donc inutile de crypter

oui mais le cryptage c'est juste pour embrouiller davantage...
je crois que c'est bon.
 
pour le cryptage je prend juste par exemple une translation de l'alphabet avec le clée:
 

 
ce qui donne par exemple www.toto.com >> ççç*zàzà*7à;
 
comme la key_chain est aléatoire, le 2e fois que le script s'execute, www.toto.com donnera autre chose.
 
comme je génère la key_chain coté php, finalement je ne transmet plus que le cypher.
 
- la valeur de la key_chain est donc imprévisible
- la valeur chiffrée également.
 
tu en penses quoi ?  

C'est mieux.
Plutôt que t'embéter à crypter, tu génères 2 chaines de caractères aléatoires, tu les enregistres dans 2 tables et pour comptabiliser la visu, tu dois trouver les 2 chaines.
Sinon, pas bien

oui mais j'ai besoin de remonter l'url quand même.
et plutot que de la transmettre en clair, autant la crypter.
 
j'ai fait mieux:
j'ai mis dans un table des fonctions de cryptage/decryptage, et aléatoirement, la fonction de cryptage dans le JS est donc générée elle aussi aléatoirement.
au fur et à mesure, je remplirais la table avec des fonctions différentes à chaque fois, et un random en php ecriras le code JS avec la fonction de cryptage aléatoirisée.
 
> même si tu as le source JS, la fonction est valable une fois et dans CE source, la prochaine fois c'est plus la même
 
   faut le faire pour cracker ça maintenant    

Fait pas trop complique quand même. Si tu dois faire évoluer ton code dans 1 an, tu vas avoir beaucoup de mal...

il est passé où ratibus ?  

J'attends ta nouvelle version pour m'y attaquer

Tiens Ratibus, j'ai rajouté la clée    je te facilite la tache, je n'ai pas crypté la "salt=www.tsenagasy.com"
 
tu peux voir la bannière ici (en haut)
http://www.tsenagasy.com/forum/index.html
 
et les scripts là:
http://ad.tsenagasy.com/salt.php
http://ad.tsenagasy.com/showad.php
http://ad.tsenagasy.com/showad.js
 
le numéro client n'a pas changé:

objectif donc: afficher la bannière en tapant directement une URL en dur dans la barre d'adresse...

Je rentre de WE, la page indiquée ne marche pas (je peux pas tester).

ah, excuse,
c'est http://www.tsenagasy.com/forum/index.php
 

 

Je regarde ça ce soir si j'ai le temps

c'est core prends ton temps

j'ai remodifié le code, j'avais un problème de cache avec le .JS et du coup il ne redemandait jamais les nouvelles clées...
 
je vais voir coté serveur dédié pour empecher le JS de se mettre en cache

http://ad.tsenagasy.com/showad.php [...] 9823768886

Oups, souci

oui, je sais, j'ai volontairement fixé la clée.
 
dès que j'aurais résolu le problème de cache du .JS, ça ne marchera plus de cette façon.
 
> la "key" est générée et supprimée aussitot après l'affichage de le bannière.
 
mes tests en local marchent (puisque faire F5 ne me dérange pas pour générer un nouveau JS)
 

voici le process:    
 
coté web on a ça:
 
<script... salt.php?clid=xxxx></script>
<script... showad.js></script>
 
-la 1ere ligne génère une variable "key" aléatoire coté serveur, la stocke dans une base avec un timeout et la sort coté client (JS)  
- le 2e ligne crypte l'URL de la page actuelle :
 
salt = f(key,(document.location.href) )...
 
puis appelle  
 
showad.php?key=...salt=...
 
revenu coté serveur on a donc la key et la valeur cryptée de l'url d'appel: Salt
 
> on vérifie si la key est présente dans la base, si oui, on continue, sinon, on die()
> on décrypte la salt avec la key pour récupérer l'url d'appel, si ne fait pas partie d'un domaine autorisé, on die()
 
edit: la base "key" coté serveur est donc normalement toujours vide, car une clée générée est aussitot supprimée en retour
 
---
 
> ah, le timeout de la key: je ne te laisse pas le temps de générer la key, de faire tes calculs à la main et de pondre une url, la key a le temps d'expirer: 5 secondes   , le temps d'un aller/retour serveur
 
il y a t'il une faille que j'ai oublié ?
par contre, j'ai beau mettre pragma no cache, expires -1... sur la page html, cet enfoiré de JS se met toujours en cache !
 
suffit que je décommente ce passage dans le showad.php et le tour est joué:
 

Avec ce système ça devient difficile de contourner la protection manuellement mais moi j'ai fais un programme PHP qui automatise les choses (et il mets moins de 5 secondes à s'exécuter ).
 
Concernant le cache, c'est normal que les propriétés de cache que tu mets sur la page HTML n'aient aucune action sur le fichier JS car ce sont 2 ressources (au sens HTTP) différentes.

il faut le faire coté serveur pour le cache.
sinon, j'estime que la sécurité du code est assez 'core' pour l'instant.
 
et le fait de dévoiler les sources au public ne peut que contribuer à colmater les failles je vais faire de l'open source sur ma régie tiens.
 
ouverture demain au public sinon.
 
Je pense que ce concept de pub communautaire est une vraie machine à sous