protection des téléchargements achetés.

[syl]

Bonjour tout le monde

L'option pour acheter un fichier à télécharger c'est nickel !

Mais n’y aurait il pas un module permettant la protection également ??

Car si l’utilisateur télécharge quelque chose, après il pourait le donner à qui il veut.

Je pense surtout au téléchargement de vidéo et de livre électronique.




Merci pour l'aide

[donaldlloyds]

question tres pertinente qui m interesse aussi ?
comment presta store par exemple lors de la vente d un module s assure que ce dernier ne sera pas donner voir vendu a d autre utilisateur ?

[Seo Organique]

oui bonne question...un dev dans le coin?!;-)

[Pierre-Yves]

Une réponse toute simple... c'est IMPOSSIBLE !

Tout est "piratable", les jeux, les films, les mp3, les modules, etc... etc...

Il y a cependant certains moyens permettant d'augmenter la sécurité des différents médias que l'on vend, mais concernant les vidéos et les livres électroniques, je ne connais pas (les DRM peut etre?).

Concernant les modules du PrestaStore, tu peux sans problème donner le module que tu viens d'acheter à qui tu le souhaite... Mais attention, c'est très FORTEMENT punit par la loi!!! Aussi bien la personne qui donne le module que celle qui le reçoit!

[Damien Metzger]

Il y a les DRM (pour les livres électroniques également, mais en l'occurence celle du kindle s'est fait hacké il y a quelques jours), mais dans un autre il y a aussi les watermarks, un petit tag glissé dans le fichier en question unique à chaque acheteur. Comme ça si un fichier est diffusé ou copié, on connait l'auteur de la fuite.

Pour le store c'est encore une autre technique : je dévore tout cru les contrevenants.

[donaldlloyds]

il ne serait pas possible de limiter un module a une installation et d insérer dans le code un script qui envoi a un manager les url des site ou le module est installé ?
comme cela meme si de bonne foie l utilisateur a foiré son instal il nous recontacte et on vérifie si le module est déjà present sur un site
ouaaaaa je suis intelligent quand je m y met

[jeckyl]

Salut,

encore une grande idée.

Cela fait plus de 30 ans que l'industrie informatique essaye de limiter le piratage donc pensez-vous sérieusement que le monde de l'open source dans sa globalité peut y arriver ?

En plus c'est contraire au concept même de l'open source qui est plus dans l'idée du je te respect en te faisant profiter de plein de trucs alors respect moi en ne détruisant pas mon oeuvre. Et cela fonctionne pas trop mal.

[donaldlloyds]

il y a une différence entre empêcher le piratage et le limiter comme tu la dit toi même, les gens de bonne foie se font de plus en plus rare de nos jours
on ma encore fait tomber la moto sans laisser de mots (en plus le soir de noel) pourtant j habite dans une villa de vieux.
et la on parler de programmes ou de produits informatiques payant voir des service qui ne réponde pas aux meme critère que le programme open source qui les commercialise.
sinon on vivrais dans un monde ou tout estbgratuit et je ne pense pas que cela fonctionne

[syl]

c’est très FORTEMENT punit par la loi!!!

==> en effet la meilleure protection reste celle du copyright et de la loi.

les watermarks, un petit tag glissé dans le fichier en question unique à chaque acheteur. Comme ça si un fichier est diffusé ou copié

Excellent à savoir ça ! simple et efficace (je suppose). merci.
Si tu en sais davantage sur les watermarks (des bonnes adresses etc) hésite pas.
C'est applicable pour les livres électroniques seulement? ou bien pour des vidéos , images ou autres documents aussi?

concept même de l’open source qui est plus dans l’idée du je te respect en te faisant profiter de plein de trucs alors respect moi en ne détruisant pas mon oeuvre.Et cela fonctionne pas trop mal.

en général les communautés open source respecte cette idée il me semble, c plutot positif

[jeckyl]

Salut ce matin,

Les protections existent, il suffit de chercher un peut, mais certaines coût des fortunes e ne sont disponible que pour de grosses compagnies.

Pour protéger la vidéo, le meilleur moins reste le [spam-filter] sur un lecteur propriétaire, donc il faut juste investir dans des gros serveurs de [spam-filter] et 2 ou 3 développeurs pour le lecteur et beaucoup de temps pour le codage des vidéos.

Par exemple, pour les modules le seul moyen serait de coder le module pour qu'il envoie un ping à une adresse sauf, qu'il faut l'autorisation express du client et surtout qu'il n'aille pas modifier le code pour le bloquer.

On arrive à un système tellement onéreux que certains ont fait d'autres choix. Dans le monde de la 3D les logiciel de production 3D professionnels sont maintenant gratuit pour un usage non commercial, ce qui permet d'avoir une communauté de jeunes se formant gratuitement su le logiciel et intégrant des équipes de dév plus tard qui elles payent le logiciel rubis sur l'ongle pour leurs film, par exemple pixar et eux il ne peuvent pas sortir un film avec des version pirate du logiciel et à 40 0000 € la licence unique et plus de 500 graphistes tu fais le calcul, c'est pas donné.

[syl]

les watermarks, un petit tag glissé dans le fichier en question unique à chaque acheteur. Comme ça si un fichier est diffusé ou copié,... il suffit de chercher un peu

Nickel

Mon soucis est que le temps me manque cruellement.

Donc si des âmes généreuses passent par là pour faire partager des liens, des connaissances, des avis, des conseils, des modes d'emplois,...
bref, tout ce qui pourrait servir à la mise en place des watermarks sur des e-books vendus avec presta,

ce pourait être bénéfique à tous et je les en remercie d'avance.

[MaxProd]

Bonjours à tous,

Un sujet toujours très sensible et qui divise. J'ai travaillé dans une entreprise qui développait un logiciel utilisé d'après nos estimations à environ 10/15 millions d'utilisateurs, mais probablement 20 millions. Toutefois, cela n'empêchait pas l'entreprise d'engranger des profits considérables (~2 millions d'euros par ans) malgré un taux de piratage > 99% et qui n'a cessé de croitre.

Toutefois, cela n'est pas donné à tout le monde d'avoir un tel succès, et il faut noter que le piratage y a été pour beaucoup (diffusion, bouche à oreille). A noter que la société à mis plus de 10 ans pour en arriver à ce point là. Mais cet exemple est surtout lié au piratage logiciel, celui-ci ne possédant qu'une très faible protection (simple n° de licence largement diffusable sur Internet).

Concernant les produits électroniques, et je ne parlerais pas des protections audio type DRM, il existe différentes méthodes mais elle ne permettent pas d'endiguer le piratage. Même si on opte pour une méthode ou une autre invariablement elle pourra être contournée.

Dans ce domaine, il y a un adage qui dit : "Tout ce qui peut être protégé, peut être déprotégé".

Maintenant, il est toutefois possible de ralentir le processus de piratage, en mettant en place une protection propriétaire, afin de délayer (anglicisme) la génération du crack, keygen ou astuce pour contourner la protection. La seule question à se poser, c'est le retour sur investissement. Que ce soit en temps, ou en argent. Ce qui revient un peu au même.

Je vais essayer de vous expliquer une méthode. Certes loin d'être la plus simple et la plus infaillible, mais qui a le mérite d'être fonctionnelle :

[A SUIVRE]

[MaxProd]

[sUITE]

1) Le client passe commande, il suit la procédure de paiement, et le paiement est validé.

2) Un email avec le n° de série de l'application est envoyé à celui-ci. Ce n° de série, ainsi qu'une clef publique, peut être généré automatiquement côté serveur grâce à un exécutable (développé par mes soins, dans mon cas en C++ pour des raisons de compatibilité avec les API C++ que j'utilise dans l'application finale) qui permet d'automatiser la procédure. Même si la première faille réside dans le fait qu'un exécutable côté serveur peut toujours être piraté si le serveur est hacké. De fait, une rétro-ingénierie peut être appliquée afin de connaître la méthode de génération de celui-ci. Et cela même s'il est basé sur un algorithme propriétaire. Le n° de série généré est inséré dans l'email de confirmation, ainsi qu'une clef publique RSA, et ça passe par un petit script en PHP.

Liens sur la question :
Cryptographie asymétrique
Algorithme RSA
PHP/PEAR Crypt RSA

<xml>


</xml>

3) Le client reçois dans l'idéal un lien personnalisé pour le téléchargement ainsi que son n° de série personnel. Un lien personnalisé est un sous-répertoire généré à la volée où une copie de l'exécutable, qui se trouve idéalement bien caché dans des sous-répertoires de l'arborescence de votre serveur, est placée. Il existe des méthodes qui permettent à la fois d'automatiser ce processus, de limiter le nombre de téléchargement, de limiter ceux-ci dans le temps (deadline), voir de limiter le téléchargement à l'unique IP de l'utilisateur. Mais là c'est dangereux, surtout si l'utilisateur à une IP dynamique.

4) Le client installe l'application téléchargée, et on lui propose une activation du logiciel. A ce niveau, les plus professionnels optent pour différentes options, en ligne, hors-ligne par téléphone ou autre. Généralement, il est demandé d'activer le logiciel sous 30 jours sous peine de ne plus pouvoir l'utiliser. C'est ici que la méthode devient intéressante.

5) La clef d'activation qui est retournée par l'application se compose généralement ainsi :

- Le n° de série est vérifié, tant dans sa cohérence (structure) que dans sa viabilité. Par exemple, dans le monde du logiciel, à chaque versions diffusées, des blacklists de n° de série identifié comme piraté sont mises à jours.

- Ici, il n'y a pas de méthode particulière. Mais je vais vous expliquer celle que j'utiliserais probablement. Elle consiste en la récupération de l'adresse MAC de l'ordinateur. L'adresse MAC étant le n° de série de la carte réseau ou l'interface réseau de l'ordinateur (Adresse MAC). Ce n° de série est en principe unique et donc différent sur chaque ordinateur.

- Je génère à la volée un fichier XML qui pourrait être celui-ci :

<xml>



     ...
</xml>

- Cette chaîne de caractère (XML) est alors encrypté avec l'algorithme RSA grâce à la clef publique qui a été fourni à l'utilisateur. L'intérêt de cette phase est qu'il est important d'encoder les données qui vont transiter par Internet pour l'activation du produit. Le résultat ressemblerais à une chaine du genre :

87be08dd41fb261e46c58c92add6cbff78d33f6d43ce57c2202e0dcbc02094096894a18df79c1fddd2dfeb6cd5476649b55e124162c4078187d4c351dc372a1e1691079d9e0b00c0692139889ac519b15df9c45fe9982ffdf45dea7ea8320de32bd9ebfe48e86a248401dcc6b8911d91b3dabc647d1e5181ced922d355390afb,cb9d0d4be2f8b92d6a2852dc04c231ff353cdf23e5b583a3304514b1a030de0e1cdef254f36a2fccbc4fe1233feb196e900d1b6214260b424bbf24faca52bf2eeb1bf998f19eadaa7709f7d1e87c3be37acd4a397ddda09228877fa20302fd892cc6c960573ab7a870dfafa0be5674c5e2a08e796349aa0b14f291bb909b0eef

6) A partir de la c'est le serveur qui reprend le relais :

- La chaine de caractère (du XML crypté) est alors transmise à un second exécutable (ou le même avec des arguments différent, tout dépend de la méthode propriétaire) pour être décryptée grâce à la clef privée.

La clef privée qui a servie à la génération de la clef publique, et qui seule permet de décoder le fichier XML précédent. C'est pourquoi je parlais de faille possible de sécurité dans la méthode si faille sur serveur il y a.

La clef privée étant une clef que vous seul connaissez, mais pour des questions d'automatisation est tout de même contenu dans votre exécutable côté serveur. L'avantage tout de même, c'est que dès que génération de Keygen il y a, il est possible de modifier la clef privée et ainsi contrer celui-ci pour quelques temps.

[A SUIVRE]

[MaxProd]

[sUITE]

- Le XML (chaine de caractère) restitué par l'exécutable sert alors à deux choses. La première de mettre à jours la base de données client afin de valider l'activation du produit, voir mettre à jours les données utilisateurs qui pourraient être utile de connaitre. Attention tout de même car il est interdit d'exploiter des informations utilisateurs sans les informer au préalable. Il y a des lois qui punissent cela.

- La seconde chose, est de générer cette fois un numéro d'enregistrement définitif qui activera l'application côté client. Ce numéro définitive va pouvoir être personnalisable grâce à l'adresse MAC que le client à transmis durant l'activation et ainsi permettre la gestion des licences par ordinateur. Par exemple, certains logiciels permettent une activation sur 3 postes différents, donc 3 adresses MAC différentes.

- A partir de la c'est encore la méthode RSA qui doit être utilisée, avec une seconde clef privée qui encodera l'adresse MAC (ou autres informations au besoin) afin de produire le numéro d'enregistrement.

7) L'utilisateur reçois en retour ce numéro d'enregistrement (qui peut être astucieusement formaté afin d'en faire un numéro intelligible). Il le saisie ou le copie dans le champ dédié et l'application (le logiciel) qui intègre la clef publique générique à tous les utilisateurs, décrypte le numéro, valide la cohérence de l'adresse MAC (ou autre, suivant méthode) et active le produit.

A partir de là, c'est une question de technique de protection du logiciel et surtout des méthodes de validation qui doivent être largement distillées dans le code source du logiciel. Pas de méthode du style :

bool validRSAKey(const String& key);

et pas de méthode unique de validation. Certains vont jusqu'à exploiter les méthodes de calculs puissantes des cartes vidéos (GPU) pour des algorithmes complexes de protections.

Il existe pas mal de protection supplémentaires liés aux logiciels comme :

- Les anti-débuggers (crash l'application au démarrage si un débugger comme SoftICE est actif)

- Les checksums (valide le CRC de l'application afin de valider si modification il y a eu, par exemple un crack/patch)

- Les packers trafiqués (encode l'exécutable et décode celui-ci au lancement genre UPX mais avec protection personnelle)

- Et bien d'autres astuces plus ou moins viables.

Mais encore une fois, il n'y a aucune méthode infaillible. Même pas les clef USB de protection qui coûtent de l'argent et qui contraignent l'utilisateur pour rien, car il existe des crack émulateurs de clef USB qui simulent leur présence.

Désolé si j'ai été long, mais j'en reviens à la question de la protection des produits électroniques, comme les eBooks.

Il n'y a foncièrement aucune protection possible contre la diffusion des livres électroniques. Par contre, il peut être intéressant toutefois de protéger ceux-ci un tout petit peu pour les personnaliser avec un code utilisateur à la volée. Je m'explique.

Un PDF contient une large section dédiée au informations sur l'ebook. Tant au niveau informationnel qu'au niveau sécuritaire.

Etant donné qu'un PDF peut être modifié à la volée grâce à de nombreuses API en PHP existantes. Il est tout à fait possible par exemple d'utiliser une méthode similaire que celle expliquée précédemment afin de "refroidir" les utilisateurs qui pourraient avoir tendance à aimer partager ce qu'ils ont.

L'idée serait de générer un code de sécurité généré en RSA à partir d'informations utilisateurs et d'une clef privée que seul le propriétaire connait. Il suffit ensuite de protéger les altérations (modifications) du PDF par un mot de passe complexe difficilement cassable en force brute, genre un mot de passe encodé en MD5 :

mot de passe original : ceci-est-mon-mot-de-passe
MD5 résultant : eb7e1db40441b7996c16a817397cab76

Ainsi le PDF intègre, par exemple dans le champ "Commentaire" un code RSA qui n'est modifiable et supprimable que si l'on connait le mot de passe complexe en MD5.

Sachant qu'un PDF peut être customisable à souhaite en terme de privilège utilisateur, on peut limiter à la visualisation uniquement (impression interdite).



En expliquant aux clients que les documents possèdent un Fingerprint (ou une Signature, une empreinte digitale) personnelle, et qu'il vous est donc possible d'identifier l'origine du document circulant sur Internet. Ca peut aider à calmer certains instincts.

Maintenant, tout dépend de la volonté de chacun et du crédit accordé à la protection de vos produits. Certains trouveront certainement tout cela inutile, mais il faut être cohérent avec sois-même :

La problématique du Piratage ne nous concerne que lorsque nous y sommes confronté !

J'espère ne pas être été trop pénible à lire et que cela aura pu éclairer certains.

Amicalement,
Max

[FIN]

[Yoya]

Direct dans les favoris ton post
Bienvenue dans la communauté!

Cdlt,
Pierre.

[syl]

Nickel MaxProd !

t'apportes réellement de l'info, du concret !

en te remerciant

[donaldlloyds]

oula !!!!!!!!!! ta l air d avoir les reponse mais .... compliqé a mettre en place pour un noobs
en tout ca merci pr ta contribution

[MaxProd]

Hello,

La complexité est directement proportionnelle à la protection qu'on désire D'autant qu'il y a des erreurs et des incohérences dans ce que je raconte là. Mais il semblerait que personne n'ai vu ça

Il n'en reste pas moins que c'est une solution parmi tant d'autres. Je penses que le plus important à retenir dans tout ça c'est l'algorithme RSA et la cryptographie asymétrique en général.

Rivest Shamir Adleman ou RSA est un algorithme asymétrique de cryptographie à clé publique, très utilisé dans le commerce électronique, et plus généralement pour échanger des données confidentielles sur Internet. Cet algorithme a été décrit en 1977 par Ron Rivest, Adi Shamir et Len Adleman, d'où le sigle RSA. RSA a été breveté par le MIT en 1983 aux États-Unis. Le brevet a expiré le 21 septembre 2000.

En 2008, c'est le système à clef publique le plus utilisé (carte bancaire française, de nombreux sites web commerciaux…).

Amicalement,
Max

[MaxProd]

Hello (2),

Concernant la protection des modules, je suis à peut prêt sûr qu'il doit avoir moyen de faire quelque chose.

Il faut partir de plusieurs postulats :

1) Le client qui achète un module n'a soit pas les compétences pour le faire, soit pas le temps car trop compliqué pour lui.
2) Le module n'est en soit que quelques fichiers php, voire quelques css et images.
3) Le module est générique de part son interface objet (constructeur / méthodes install, desinstall, getContent ...)
4) Le module est destiné à tourner sur une boutique, soit une URL en principe.

Partant de là réfléchissons un peu à tout ça. Attention, je ne dis pas que j'ai une solution, mais je penses qu'il doit avoir moyen de limiter la copie.

Le problème dans notre cas, c'est que le code est lisible par tous et donc facilement duplicable, voir récupérable pour exploitation tiers dans des modules alternatifs. Un fichier PHP par essence n'est rien de moins qu'un fichier texte avec une syntaxe particulière liée au langage.

Il existe néanmoins des méthodes d'obfuscation de code afin de rendre celui-ci plus ou moins illisible et incompréhensible. Et même si elles sont réversibles par les développeurs doués, elles ont le mérite de rendre la manoeuvre complexe pour ne pas dire chiante.

Mais vous me direz qu'au final, obfuscé ou pas, un code PHP et en l'occurrence des classes Module pour Prestashop peuvent être installées dans n'importe quel back-office étant donné la généricité des classes. Exact. Sauf, si en plus de l'obfuscation vous implémentez dans la classe install un process de vérification d'authenticité. Je m'explique.

Par exemple, dans la méthode install, la première idée serait d'appeler une méthode du style checkAuthenticity() qui s'occuperait de valider que le domaine (URL) d'installation, correspond bien au domaine de votre client. Celui déterminé lors de l'achat du Module et sur lequel il est sensé vivre.

Mais vous me direz, que c'est pas bien compliqué de "repérer" l'appel d'une méthode propriétaire et de chinter celle-ci. Oui, mais ça devient déjà plus complexe si le code de la méthode "checkAuthenticity()" est directement écrit dans la méthode héritée "install()". C'est là qu'il faut multiplier les astuces et par exemple ne jamais inscrire en clair le domaine en question dans une variable privée de classe genre :

private $_domaine = 'www.monsite.com';

De plus, le nom du domaine ne devrait jamais apparaitre en clair dans le code. Il devrait être masqué par quelques opérations logique "facilement" réversibles quand on connait la méthodologie de masquage. La méthodologie de lecture étant elle même obfuscée dans le code de vos classes, et au mieux éparpillée à droite et à gauche pour ne jamais avoir toute la procédure de check au même endroit dans un même block facilement bypass-able.

Tout cela peut facilement être managé par un module propriétaire qui utiliserais un ensemble de fichiers correspondant à votre module à vendre et qui générerais à la volée une archive à télécharger en ayant au préalable personnalisé les classes (nom de domaine du client, ou autre suivant vos méthodes) et obfuscé celui-ci avec une logique qui vous est propre.

Les méthodes classiques d'obfuscation remplacent toutes le nom de méthodes, nom de variables etc ... par des MD5 (32 octets par très lisibles par le commun des mortels). Ils s'amusent aussi à effacer toute l'indentation rendant le code sous la forme d'une simple ligne sans retour chariot. Jetez un coup d'œil sur les solutions open-source pour vous faire une idée de la question si ce n'est déjà pas le cas. ex: PHP Obfuscator

exemple de code obfuscé :

function FC7321B391B6EF18F0711B835402E91D1($RE91192A00FF990477EE414AD5D708F08)  { global $db_prefix; global $R695CD54D1F9CB31C11C71AF5EF74FDDB; $R9E9F3EDB7A84E99A0567F313F4EAC1BA =  $RE91192A00FF990477EE414AD5D708F08; $R37A721F3B04CA577A7730084048F2BE3 = array_keys($R695CD54D1F9CB31C11C71AF5EF74FDDB);  foreach($R37A721F3B04CA577A7730084048F2BE3 as $R90E8291866BD6CB7ED5089CE7E833D11)  { $R9E9F3EDB7A84E99A0567F313F4EAC1BA =  str_replace($R90E8291866BD6CB7ED5089CE7E833D11, $db_prefix . $R90E8291866BD6CB7ED5089CE7E833D11 , $R9E9F3EDB7A84E99A0567F313F4EAC1BA); } return $R9E9F3EDB7A84E99A0567F313F4EAC1BA;}

Bien entendu le nom des méthodes héritées de la classe de base Module doivent rester en clair sous peine de non fonctionnement.

Conclusion, c'est bien une méthode barbare de protection et qui est loin d'être efficace à 100%. Mais elle a le mérite de pouvoir limiter l'usage des modules à un client en particulier. Pour un module à <50€ par exemple, si la méthodologie de protection et d'obfuscation est bien faite, il est bien plus rentable de l'acheter que de perdre des jours voir des semaines à remonter le code et à faire sauter la protection.

L'idéal étant d'utiliser un process automatique pour générer les sources du Module à la volée et en modifiant automatiquement les méthodes de hashage aléatoirement (MDx, SHAx, RIPEMDx, TIGERx, HAVALx ...) et utiliser un masque variable pour l'encodage des chaines de caractères (pour les opérations logiques de masquage). Ainsi, chaque module se voit greffé une protection personnelle.

Donc voilà l'idée : un Module "Tools" côté vendeur qui permet automatiquement de générer une copie personnalisée d'un Module (un archive est construite à la volée contenant l'arborescence du module, avec des PHP alternatifs). Tout dépend ensuite de vos prestations. Si c'est vous qui l'installez ou pas. Mais en tout cas, l'idée serait d'avoir au moins un appli qui automatise la protection des Modules.

Dites moi ce que vous en pensez ?

Amicalement,
Max

[donaldlloyds]

heuuuuuuu comment dire !! ca a l air bien je te laisse faire peut être q un développeur passera par la pour discuter avec toi car pour moi c est du chinois par contre je te remerci de prendre du temps pour nous expliquer et pourquoi pas developper un module qui permette de proteger nos fichiers

[MaxProd]

:roll: Je n'ai pas l'intention de me lancer dans le développement de module, en tout cas par pour l'instant. Si ce n'est pour mon module propriétaire spécifique à ma boutique.

Tout ce que je dis ici c'est plus pour le partage. Mais effectivement, c'est pas forcément très simple à comprendre, même pas pour moi :gulp:

Amicalement,
Max

[syl]

Cependant MaxProd, si tu réalises ça pour avant la semaine prochaine , sache que je suis prêt à te payer

[donaldlloyds]

hahaha syl a mis la carotte :-)

[MaxProd]

Cependant MaxProd, si tu réalises ça pour avant la semaine prochaine , sache que je suis prêt à te payer

Je t'aurais bien dépanné. Mais à vrai dire, ça fait 3 jours que je me suis mis à PrestaShop. Alors c'est encore prématuré pour me lancer dans de la prestation. Mais déjà de quoi parles-tu exactement quand tu dis "réalises ça" ?

Amicalement,
Max

[MaxProd]

hahaha syl a mis la carotte :-)

Salut,

Sache que je ne marche pas "à la carotte" comme tu dis. Je n'ai pas besoin de ça pour me faire mon blé, ne t'inquiète pas pour moi

Amicalement,
Max

[donaldlloyds]

roooooooo tout de suite vous le prenez mal
je ne m inquiète pas pour vous
V+

[MaxProd]

roooooooo tout de suite vous le prenez mal
je ne m inquiète pas pour vous
V+

Tu peux me tutoyer, t'inquiète pas je mord pas. Seulement, chez moi, l'image de la carotte signifie de faire avancer l'âne sur lequel on se trouve. Tu comprends pourquoi je t'ai répondu ça

Amicalement,
Max

[syl]

de quoi parles-tu exactement quand tu dis “réalises ça” ?

Me suis gouré, jpensais être dans le sujet Fusion compte Joomla / Prestashop.


Mais donc ici, la protection d'ebook

[MaxProd]

Mais donc ici, la protection d'ebook

Salut,

Ok, mais comme je t'ai dis, difficile pour moi de me lancer tout de suite dans de la prestation. Si seulement tu avais le temps

De plus, ça nécessite forcément l'usage d'extensions à PHP. Ne serais-ce que pour la cryptographie ou une librairie tout-en-un comme celle indiquée plus loin. J'ai regardé vite fait la documentation PHP qui gère le PDF (http://php.net/manual/fr/book.pdf.php), il ne semble pas avoir de support des options de sécurité (j'ai peut être mal lu tu me diras). Il te faudrait une API du style : http://www.setasign.de/products/pdf-php-solutions/setapdf-encryptor/encrypt-protect-pdf-files-with-php.html.

Si tu fais un petit cahier des charges précis de ce que tu souhaites, je suis sûr que tu devrais trouver quelqu'un prêt à te coder un module.

Amicalement,
Max

[syl]

aaah benh voilà un bon petit lien ;