FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Permisos en Firebird ...
Totalmente de acuerdo con Delphius. En mi humilde opinión, Firebird tiene una mejor implementación de manejo de permiso que MySQL (y que algunas otras base de datos). Tratándose por ejemplo de permisos de escritura en una tabla, puedes incluso, dar permisos por campo. Es decir, si una tabla tiene los siguientes campos: Field1, Field2, Field3. Puedes otorgar permiso a un usuario para que solo Field1 y Field2 sean de lectura, y Field3 sea de lectura y escritura.
Otra cosa, puedes incluso otorgar permisos a las disparadores de las tablas para que ejecuten procedimientos almacenados (te ahorra sobre todo trabajo, al no tener que dar específicamente permisos de ejecución sobre dicho procedimiento a cada usuario). Por alguna razón que aun no entiendo, son pocos los programadores que hacen uso extensivo del manejo de permisos y roles en Firebird (créanme que es una herramienta sumamente poderosa y te quita de muchos problemas de encima si se sabe utilizar correctamente). También al que reconocer que esto le agrega un nivel más de complejidad. Finalmente, la solución al problema de Efren2006 se puede solucionar con permisos (como lo plantea Román) o con un disparador (como ya bien lo dijo Casimiro). Lo único que yo le agregaría al disparador que propuso Casimiro Notevi es una condición para checar si el usuario conectado (curren_user) es el administrador o si tiene un rol de administrador. Con esto quito la necesidad de estar habilitando/Deshabilitando el disparador (lo cual no resulta ser muy seguro, por obvias razones). Saludos, Gerardo Suárez Trejo |
#2
|
||||
|
||||
Estoy de cuerdo contigo (y con Delphius), aunque he de decir que MySQL tambien maneja permisos a nivel de campo y lo hace desde hace mucho tiempo. Lo de los triggers no lo creo y de hecho, los procedimientos almacenados de mysql son inusables en la práctica pues tiene un rendimiento muy malo.
// Saludos |
#3
|
|||
|
|||
Aunque pueda estar de acuerdo en los planteamientos de utilizar distintos usuarios y no sysdba, en mi caso me pareció mas practico porque yo tengo varios clientes que utilizan mi sistema y la estructura de la base de datos es igual para todos, entonces cuando le hago modificaciones a la base de datos tengo un programa que sincroniza la base de datos antigua a la nueva, si utilizara usuarios particulares para cada cliente, tendría que rehacer o guardar todos los usuarios, de esa forma me pareció mas cómodo y menos problemático, adicional que la gran mayoría de los clientes soy yo el que administra la BD.. En fin,,,
Gracias todos por sus aportes |
#4
|
||||
|
||||
Cita:
|
#5
|
||||
|
||||
¡Exacto! Pero es un buen ejemplo de porqué es deseable tener varios usuarios
// Saludos |
#6
|
|||
|
|||
Permisos en Firebird ...
Sin embargo, creo que permitir a clientes "normales" conectarse como sysdba estaría abriendo un enorme hueco de seguridad. Tengo por ahí un pequeño sistema que solo lo utilizan un par de personas y de todos modos les he creado su perfil de seguridad. Imagínate lo que pueden hacer un cliente avezado al tener permiso sobre todos los objetos de tu base de datos.
Con lo que respecta a lo que dice Efren2006, a mi parecer, yo crearía perfiles de seguridad a mis usuarios y resolvería el problema tal y como lo ha menciona Casimiro (soy un fanático de utilizar disparadores y procedimientos almacenados). Además de que mi base de datos sería mas robusta en lo que respecta a la seguridad. Por último, Delphius pregunta que si hay restricciones en cuanto al número de usuarios que se puedan dar en una base de datos. Tengo aquí en mi mano, el libro SQL Firebird (escrito por Hellen Borrie), y efectivamente, no existe ningún límite al respecto. Atte: Gerardo Suárez Trejo. Comentario aparte: en Firebird 3 se podrán crear procedimientos almacenas utilizando Java. En palabra de Adriano Dos Santos Fernandes, dicha herramienta estaría mejor implementada de lo que está en Oracle. Espero con ansia dicha mejora, estoy programado actualmente un sistema de reconocimiento facial y creo que esto me sería de mucha ayuda (el reconocimiento lo estoy programado en JavaCV que es un "wrapper" de la biblioteca OpenCV). Voy abrir un nuevo tema para hacer algunas preguntas al respecto (el comentario viene a cuento por lo que dice Román de los disparadores y procedimientos almacenados en MySQL). Última edición por Gallosuarez fecha: 22-09-2012 a las 01:20:47. Razón: Hacer una correción .. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Trigger - evitar borrado de registro | StartKill | MySQL | 1 | 04-03-2008 14:49:24 |
Evitar el agregar registro en una DbCtrlGrid | Manuel | Varios | 4 | 27-11-2006 19:22:45 |
Como Evitar Borrar Registro en dbGrid al Presionar ESCAPE ???? | AGAG4 | Varios | 4 | 07-07-2006 04:30:20 |
Evitar Borrar más filas con DBGRID | User_Baja_2 | Varios | 4 | 12-01-2006 23:59:09 |
Borrar lineas detalle al borrar registro maestro | akinom38 | Conexión con bases de datos | 3 | 11-01-2006 10:38:07 |
|