FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
||||
|
||||
Firebird - Obtener Clave única
Hola de nuevo a tod@s !!
Es posible obtener una clave única del ordenador en el que se encuentra instalado Firebird (2.5) ?? Es decir, tengo un proceso de claves de activación que funciona perfectamente basado en el número de serie del ordenador local en el cual se solicita la clave de activación. Pero en este caso, en vez de condicionarlo a cada puesto, quiero condicionarlo a la base de datos activa e instalada, es decir, al ordenador en el que se encuentre corriendo Firebird. Me queda claro cómo obtener el número de puestos actualmente conectados a la base de datos. Eso no es lo que me inquieta ahora, sino lo que quiero es validar una clave de activación para x número de puestos que se pueden conectar a la base de datos, y para ello necesito obtener un código único que identifique al propio ordenador donde se encuentre instalado Firebird, y no quiero tener en dicho ordenador un programa adicional, sino que sea la propia base de datos la que cada vez que se conecte un usuario, sea capaz de devolverme ese valor único, que debe depender del ordenador que ejecuta Firebird. Es posible ? Gracias como siempre por vuestra ayuda. Saludos !
__________________
Piensa siempre en positivo ! |
#2
|
||||
|
||||
Hola.
Yo no sé nada de Firebird pero si lo que quieres es limitar el número de usuarios concurrentes y sabes cuantos usuarios hay conectados a la base de datos ¿para qué necesitas un número de identificación?. Saludos
__________________
Be water my friend. |
#3
|
||||
|
||||
Creo que Firebird no ofrece el tipo de información que necesitas. Para implementarlo tendrías que escribir una función externa.
Por otro lado, recuerdo que una vez investigué algo similar a lo que buscas. Si mal no recuerdo, lo que encontré fue que el campo MON$CREATION_DATE de la tabla MON$DATABASE guarda la fecha y hora de creación del archivo de la base de datos. Ya que ese campo tiene precisión de milisegundos, es una buen dato para identificar la singularidad de la DB. Porque es poco probable que dos DBs vayan a ser creadas en la misma fecha y a la misma hora con precisión de milisegundo. Saludos! |
#4
|
||||
|
||||
Gracias Newtron y gracias Chris :
Ninguna de las dos soluciones me es válida ya que lo que intento evitar es que esa base de datos se pueda copiar a otro ordenador. Newtron : Lo que intento hacer es validar mi programa con una clave de activación. En un puesto local, obtengo el número de serie del disco duro y solicito una clave de activación. Esa clave sólo es válida para ese usuario y ese ordenador. Si formatea de nuevo o copia el programa a otro ordenador, no sirve esa clave de activación. Por lo tanto, no me basta con obtener el número de usuarios concurrentes que accedan a una base de datos. Chris : Me parece en principio buena tu idea, pero yo lo que quiero obtener es una limitación basada en el EQUIPO en el que corre la base de datos, para impedir una copia de la base de datos una vez que se haya activado. Si me basara en la fecha y hora de la creación de la base de datos, si copia esa base de datos a otro equipo, el valor sigue siendo el mismo, o no ??? ... Chris ..., cómo se podría implementar eso en una función externa ??? Al día de hoy, dentro de la aplicación Delphi, utilizo la función GetVolumeInformation. Es posible implementar dicha función dentro de Firebird con una UDF externa ??? Gracias.
__________________
Piensa siempre en positivo ! |
#5
|
||||
|
||||
Cita:
Las UDFs están ahí para todo tipo de asuntos que están fuera del alcance SQL, pero tengo entendido que pronto podrán programarse cosas como éstas directamente en procedimientos almacenados, o algo por el estilo. Saludos. |
#6
|
||||
|
||||
Gracias Al !
Ya estoy lo estoy probando .... a ver si me resuelve el problema.
__________________
Piensa siempre en positivo ! |
#7
|
|||
|
|||
¿Protección?
Gluglu:
Hace ya un tiempo, requirieron de mis servicios para pasar un servidor OPC a otra computadora con mejor hardware. El problema era que si instalabas el Servidor a otra PC, este dejaba de funcionar porque necesitaba de un pequeño programa que al momento de ejecutarse "hacia algo" (validaba una licencia) y aunque permitía instalarse, este dejaba de funcionar (¿me explico?). Para no hacer el cuento largo, el método de validación lo hacía a través de guardar el número de serie de las dos tarjetas de red (previa encriptación en la base de datos). Método sencillo para evitar copias no autorizadas de programas (creo que es lo que tu quieres). Saludos, Gerardo Suárez Trejo P.D. Para aquellos que se estén preguntando si es un método seguro. mmmmmhhhh, la verdad es que no .... Una vez, que supe como era el mecanismo de protección me llevó dos horas implementar la solución: monté un servidor Linux e instalé una Caja Virtual, desde aquí a través de software tu puedes cambiar el número de serie de las tarjetas de red. Otra aclaración, la empresa que montó el OPC pedía $400,000.00 pesos mexicanos (poco menos de $40 mil dolares americanos por hacer esto). Lo que es un verdadero asalto a mano armada ... |
#8
|
|||
|
|||
Nota aclaratoria ...
Gluglu:
Cuando digo número de serie de la tarjeta de red ... en realidad me estoy refiriendo a la MAC de la tarjeta ... Saludos, Gerardo Suárez Trejo |
#9
|
||||
|
||||
Yo iba a proponer algo parecido a lo del colega GalloSuarez. Si el problema es que no quieres que la base de datos funcione en otro servidor podrías anclarla a servidor en el que está bien por algún dato del hardware del servidor y bien puede ser la MAC de la tarjeta de red si consigues leer ese dato desde los clientes.
__________________
Be water my friend. |
#10
|
||||
|
||||
Varias cosas
Un dia de vago, me puse a inventar algo parecido.
Lo que se me ocurrio fue: MAC Serial Disco Duro Palabra clave Luego intercalo las tres cadenas generando una tercera cadena. Finalmente la tercera cadena la paso por una funcion de encriptacion. |
#11
|
||||
|
||||
Gracias todos por vuestras respuestas :
Queda claro que el método para evitar copias se basa en obtener algún número único, llámese MAC de las tarjetas de red o cualquier otro número único del equipo. Eso es precisamente lo que intentaba aclarar en mi post inicial .... que eso ya lo tengo hecho. Mi pregunta se refería en concreto si FIREBIRD es capaz de devolver alguno de esos datos en sí mismo. Por todas las contestaciones anteriores, lo que entiendo es que la única manera es a través de una UDF, no ? Saludos
__________________
Piensa siempre en positivo ! |
#12
|
||||
|
||||
Cita:
a) Posea funciones integradas para obtener este tipo de información. b) Admita llamadas directas a funciones del sistema operativo. Crear una UDF no tiene demasiada ciencia, encontrarás bastante material sobre ello en estos foros. Saludos. |
#13
|
||||
|
||||
Hace algún tiempo intenté algo así y creo recordar que el número de serie del disco duro del servidor se puede leer desde cualquier equipo. Solo hay que solicitarlo indicando una carpeta compartida del mismo. Esto hace que todos los puestos obtengan el mismo serial. A lo mejor te puede servir...
__________________
http://www.gestionportable.com |
#14
|
||||
|
||||
Crear la DLL en Delphi :
... y después en Firebird :
Por último, para pedir los datos del número de serie mediante la consulta SQL :
Saludos a todos y de nuevo gracias por vuestra ayuda !
__________________
Piensa siempre en positivo ! |
#15
|
||||
|
||||
Añado un comentario adicional para responder a los otros compañeros que gratamente han expuesto su solución y punto de vista.
La cuestión principal de todo el planteamiento de este hilo es que debe de ser Firebird el que me devuelva el número de serie del disco duro del ordenador en el que se encuentra instalado. No necesito indicar ninguna otra carpeta o solicitar la información respecto del ordenador en el cual estoy ejecutando la aplicación Delphi directamente. Lo que se trata es que pueda implementar un sistema de claves, que no sólo me valide la instalación para un único ordenador (el servidor Firebird), sino que además después y de manera adicional, ya a partir de esa clave, pueda gestionar el número máximo de puestos, de registros, etc. Hasta ahora lo tenía implementado por cada puesto, y se hacía desde Delphi, pero lo que han pedido algunos clientes que tienen muchos puestos de trabajo, y que además cambian o sustituyen a menudo esos ordenadores de puesto de trabajo, que el control de validación y número de puestos conectados se pudiera hacer directamente en el servidor, y no dependiera de cada disco duro de cada puesto que se conecta, y por eso necesitaba que esa función me la realizara directamente el servidor que ejecuta Firebird. Saludos
__________________
Piensa siempre en positivo ! |
#16
|
||||
|
||||
Me parece una estupenda solución la que aportas. Mi idea, y sobre la que puse el post anterior es basándome en que yo no instalo nada en el cliente, comparto una carpeta en el servidor y allí está el ejecutable y las dll necesarias. Los puestos solo tienen un acceso directo al ejecutable. La primera ejecución de un cliente es la que registra el servidor guardando su valor encriptado en la base de datos. Todos los demás puestos que se conectan contrastan la clave generada con la almacenada y listo. Pero si no hay carpeta compartida en el servidor, lógicamente no sirve.
__________________
http://www.gestionportable.com |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Generar clave única | vivamotos | C++ Builder | 1 | 06-06-2008 13:42:41 |
enviar mensajes de error en campos obligatorios y clave unica | Goyo | Conexión con bases de datos | 0 | 16-05-2007 00:11:07 |
Obtener la clave de una base de datos de FireBird | vzar42 | Firebird e Interbase | 5 | 19-01-2007 23:43:35 |
Problemas al generar una clave unica | Huer | OOP | 6 | 09-06-2004 03:58:57 |
Validar clave unica en Paradox | dchaparro | Tablas planas | 6 | 20-04-2004 02:34:58 |
|