Limiter l'utilisation d'un logiciel java

Bonjour à tous,

mon patron s'est mis en tête de proposer une version sous forme d'application des services que nous proposons actuellement par internet. Le Java risque bien d'être choisi pour réaliser le logiciel qui ne sera pas très compliqué mais pour lequel on doit limiter le nombre d'utilisation. Facile sur le web, moins hors-ligne (pour moi en tout cas).

Exemple, notre algo qui fait la force du logiciel, ne pourrait être utilisé que 1000 fois avant que le client doivent nous racheter une clef pour continuer d'exploiter le service.

J'imagine que je dois pouvoir tirer partie de composant qui permettraient, par exemple, de faire des versions de démo ou autre.

Connaîtriez-vous des APIs qui permettraient cela ou même des mots-clefs qui pourraient m'aider mes recherches ?

En vous remerciant d'avance !

a partir du moment où ça s'exécute coté client, il devient dur d'empecher le client de "tricher". Il faudra bien stocker cette information quelque part... mais où que t'écrive, l'utilisateur pourra toujours effacer le fichier et recommencer à 0.

Tu aura vraisemblablement plus de chance d'arriver à des résultats probant en faisant ce que la pluspart des éditeurs font sur le marché. Fournir au client une clé limité non pas en nombre d'usages, mais dans le temps.

Citation:

---

Envoyé par tchize_

a partir du moment où ça s'exécute coté client, il devient dur d'empecher le client de "tricher". Il faudra bien stocker cette information quelque part... mais où que t'écrive, l'utilisateur pourra toujours effacer le fichier et recommencer à 0.

---

Le nombre d'utilisateur est extrêmement limité, probablement de l'ordre de la dizaine pour ce type de distribution et pour la plupart ignares pour ce qui est de la chose informatique. Mais en effet, autant partir sur de bonne bases et éviter les solutions bancales.

Citation:

---

Envoyé par tchize_

Tu aura vraisemblablement plus de chance d'arriver à des résultats probant en faisant ce que la pluspart des éditeurs font sur le marché. Fournir au client une clé limité non pas en nombre d'usages, mais dans le temps.

---

Là encore, il reste la possibilité de contourner en dérèglant l'horloge j'imagine. Bon, pas de solution miracle, mais ca fait réfléchir au schmilblick ! Merci.

Si je retiens la solution de l'activation dans le temps et que je mixe avec une activation sur le réseau : peut-être pourrais-je demander l'activation de l'application sur internet pour une durée de x jours. Genre, je vends 10 licences au client et celui-ci peut installer autant de fois qu'il veut le logiciel mais ne pourra activer en même temps (pour la durée de x jours) que 10 machines qui se feront reconnaître par un moyen à définir (adressse MAC, clef générée à partir de diverses infos sur l'ordi, autre).

D'où nouvelle question, existe-t-il une solution (me parlez pas de SOAP :p) qui permette de faire communiquer facilement le logiciel java et mon serveur mutualisé (=pas de java en ligne) ?

Edit : Deux messages en trois ans, belle moyenne :D

si ton serveur est en php, tu peux toujours mettre le code de validation dessus en php, et avoir ton java qui fait des new URL

Première solution, tu cryptes le fichier dans lequel tu stockes tes informations, en l'installant manuellement la première fois. S'il n'existe pas, s'il est modifié, peu importe, paf crac boum, l'utilisateur a touché au fichier.

Deuxième solution, tu enregistres le nombre d'utilisations dans la base de données de ton serveur. Ca serait cool que ceci soit géré depuis l'application-même lors du lancement de l'algorithme ou autre et non depuis la page qui permet d'ouvrir l'application. Ceci, à fin d'éviter qu'un utilisateur n'ouvre la page accidentellement, charge l'application et, paf, perde une possibilité d'utilisation de la page.

Dans tous les cas, si c'est vraiment le coeur de ton métier, obfusque le byte-code. Ca prend moins de place à charger depuis le serveur, ça permet d'avoir une application qui tourne en laissant moins de possibilité au reverse-engineering, même si ce sont des caves.