Cómo hacer un límite de prueba de 14 días en mi aplicación Delphi
licensing (10)
Estoy buscando agregar un límite de prueba de 14 días a mi software. El programa ha sido escrito en Delphi 7.
Cualquier ayuda sería muy apreciada.
Es posible que desee leer esta página . Es un poco viejo, pero es información inteligente sobre cómo proteger su programa y cómo.
Hay varios trucos que puede usar, pero ninguno de ellos es el 100% que falla.
- Puede usar algún tipo de mecanismo de licencia.
- Puede almacenar el tiempo de configuración en algún lugar oculto en el registro.
- Puede almacenar el tiempo de configuración en un archivo (posiblemente un archivo ejecutable o dll).
- Puede almacenar la dirección IP en una base de datos central y verificar cada vez que pasen los 14 días (para eso necesita una conexión a Internet).
- Puede crear un archivo (por ejemplo, un dll) dinámicamente en su servidor y hacer que el instalador recupere ese archivo. (Asegúrese de registrar el IP para que no sea posible un segundo intento).
Pero creo que la mejor manera es dar versiones de prueba con funcionalidad limitada. Por ejemplo: no se puede imprimir, no guardar el proyecto o solo se pueden guardar pequeños proyectos.
De esta forma evitará las molestias y los posibles clientes pueden tomarse el tiempo para evaluar su proyecto.
EDITAR: Si construyes un mecanismo para evitar el retroceso del reloj. Asegúrese de agregar un margen, de lo contrario, el programa se bloqueará si viaja de regreso a otra zona horaria. O ponga el reloj nuevamente en invierno. Creo que un margen de 25 horas cubrirá todo. (Y para ahorrar, puede agregar un límite, el usuario puede revertir el tiempo cada día).
Pero la mejor manera de seguir pagando a los clientes es brindando un buen apoyo. Descontinúo los productos si el servicio es malo.
He usado Armadillo, Asprotect y Winlicense. Tanto Armadillo como Asprotect han tenido serios problemas, como ser considerados virus / troyanos por algunos antivirus, problemas de incompatibilidad, etc.
No he usado Winlicense lo suficiente como para tener mucha opinión, pero el soporte es bastante bueno.
Obviamente, ambas son soluciones más completas que las que está pidiendo: incluyen protección, licencias, claves, etc.
Como lo mencionaron otros, a veces la mejor opción es limitar una característica o agregar una marca de agua. Agregué una marca de agua a uno de mis programas (STGThumb) y las ventas aumentaron aproximadamente un 400% ...
Podrías probar Turbopower OnGuard. Esto es ahora código abierto.
Una de las cosas que debe evitar con una aplicación de tiempo limitado es que los usuarios vuelvan a imprimir su calendario para que la aplicación siga funcionando. Una forma de evitar esto es almacenar en su lugar de registro oculto (o donde sea) una marca de tiempo cada vez que se inicie la aplicación. Si la fecha / hora actual es siempre anterior a la última marca de tiempo registrada por su aplicación, eso significa que el usuario ha retrotraído el calendario y debe desactivar la aplicación.
Sin embargo, la limitación de tiempo es un verdadero dolor tanto para el programador como para el usuario. Tampoco es una gran idea de marketing: ¿por qué tomarse la molestia de distribuir material promocional (que es la versión de prueba) que tiene una fecha de vencimiento? Sería como una empresa que envía anuncios publicitarios en papel diseñados para desintegrarse después de dos semanas.
Si su versión de prueba está funcionalmente paralizada en su lugar, aún puede obtener ventas de ella, incluso meses o años más tarde.
Yo recomendaría hacer un número de serie de prueba con marca de tiempo y forzar al usuario a ingresarlo en el software cuando esté instalado. Incluso puede automatizarlo llamando a la página del lado del servidor después de la instalación.
La marca de tiempo en la clave de serie de prueba le permite extender su prueba si es necesario.
Además, puede contar hacia atrás para evitar que el usuario cambie de año cuando instale:
por ejemplo, si tiene 14 días de prueba generados el 15.11.2008 (hora del servidor), puede verificar que la fecha de localización debe ser mayor que 1.11.2008 o menor que el 24.11.2008 siempre que se use o ingrese el número de serie.
algo a tener en cuenta al realizar cualquiera de estos controles. Que la fecha nunca es MAYOR que 14 días a partir de la fecha en que ingresó en cualquier dirección. Un método común para la mayoría de estos tipos de límites es establecer la fecha unos años antes, instalar y ejecutar el software, luego establecer la fecha a la hora actual. Si está codificado para morir 14 días después de la fecha de inicio original, entonces el usuario tiene unos años para probar su software. Verificar la otra dirección también le da al usuario como máximo 28 días.
Creé mi propio generador de claves (programa separado para crear claves). Los valores clave se almacenan en un archivo binario con el mismo nombre que mi programa, solo una extensión diferente. Ejemplo: myprogram.key
Guardo:
Nombre
Email
RegType (REG, TRIAL)
RegDate
FirstRun (0 OR 1)
El programa busca el archivo. Si no está allí, arroja un mensaje al usuario y se cierra. El generador de archivos clave escribe los valores en cadenas cifradas que luego se escriben utilizando las rutinas de flujo integradas.
Creo una clave de prueba que distribuyo con el programa. Si alguien se registra, entonces les creo una clave REG oficial.
Por otra parte, si están ejecutando mi programa, primero busca el archivo de clave. si se encuentra, comprueba el tipo de registro, si es una versión modificada, luego se carga el programa y se muestra la información de registro. También guardo un regdate, que comparo con el día en que se ejecuta el programa y, si el regdate es mayor o igual que la fecha de hoy, el usuario puede volver a registrarse.
Si descubre que el archivo de clave almacena un RegType de TRIAL, la fecha en que lo ejecutaron por primera vez se almacena en el archivo de claves, y la bandera que se ejecuta por primera vez se establece en 1. Luego pueden usarlo durante 14 días. Cada vez que ejecutan el programa, la fecha almacenada se compara con la fecha de ejecución.
Proceso muy simple para escribir ¿Es a prueba de tontos? NO, nada es! He tenido un gran éxito con mi aplicación. No es muy conocido, por lo que no hay hackers buscando para hackearlo.
Puede usar una herramienta profesional como SoftwareShield. Lo uso en nuestras aplicaciones y ofrece varios modelos de licencias, incluida la demo limitada.
Puedes encontrar la pregunta similar aquí .
En general, considero que la restricción de tiempo es mucho más útil que la restricción de funcionalidad. Como expliqué en el comentario a la publicación de Gamecat