Hola. Yo no conozco mucho sobre desarrollo de aplicaciones, pero me parece que es un asunto de diseño, mas que de lenguaje.
Me explico. Yo soy el usuario Juan, que voy a ejecutar un programa que tu escribiste, para manipular los datos que está administrando digamos Luis Felipe. El trabajo de tu programa se limita a manipular los datos de la forma como tu lo deseas y de transferirle a la base de datos quién está intentando hacer eso, o sea Juan. Pero tu programa no tiene que tener una tabla que por ejemplo diga: Juan, puede hacer esto, Pepe, lo otro, etc. Simplemente pasa como parámetro la identificación de aquel que está ejecutando el programa, o sea yo; para eso tuve que haber dado login en algún sitio y es allí donde se sabe que soy yo. Luego la responsabilidd de todo lo que pase en el acceso a los datos es el que administra el acceso a la misma, en este caso Luis Felipe. El programa no tiene que contener en su código ningún dato de los usuarios que acceden al mismo, en ese caso habría que estar reescribiéndolos cada vez que cambiamos a los usuarios. Bueno si trabajas para una empresa y diseñas un sistema así, tendrás trabajo por años :-). Por supuesto es mucho mas profundo que eso, pero es a manera ilustrativa. Aquí tienes algo por donde empezar, aunque esto es tema para un foro de programación. http://html.rincondelvago.com/seguridad-en-bases-de-datos.html Saludos El 11 de febrero de 2016, 9:28, Rafael Cantos Villanueva < raf...@rafaelcantos.es> escribió: > Saludos > > Rafa > > El 11/02/2016 a las 14:24, alparkom . escribió: > >> El día 11 de febrero de 2016, 10:14, German Cardozo >> <gcard...@gmail.com> escribió: >> >>> >>> On Feb 11, 2016 7:38 AM, "Rafael Cantos Villanueva" < >>> raf...@rafaelcantos.es> >>> wrote: >>> >>>> >>>> Saludos >>>> >>>> Rafa >>>> >>>> >>>> >>>> El 11/02/2016 a las 12:28, alparkom . escribió: >>>> >>>>> >>>>> El día 11 de febrero de 2016, 8:01, Luis Felipe Tabera Alonso >>>>> <taber...@unican.es> escribió: >>>>> >>>>>> >>>>>> On Thursday 11 February 2016 07:33:51 alparkom . wrote: >>>>>> >>>>>>> >>>>>>> Explicado de forma simple; si hago una conexión en Java, el archivo >>>>>>> .java tendrá los datos de conexión (en caso de usar MariaDB, se >>>>>>> debería escribir en el .java la dirección del servidor, el usuario de >>>>>>> MariaDB, la contraseña del mismo y el puerto usado)... entonces, que >>>>>>> pasa si descompila dicho el .class que genera Java? >>>>>>> >>>>>> >>>>>> >>>>>> Lo estás haciendo mal, si el programa tiene todos esos datos 'tal >>>>>> cual', >>>>>> te va >>>>>> a dar igual el lenguaje de programación, compilado o no. Un usuario >>>>>> malicioso >>>>>> podrá obtenerlos. ¿Quién se supone que tiene acceso a la BD? ¿Solo >>>>>> usuarios? >>>>>> ¿Solo el programa? El usuario/programa que acceda a la BD ¿Puede hacer >>>>>> con >>>>>> ella lo que quiera? ¿debería poder? >>>>>> >>>>>> >>>>> Se supone que C++ es compilado a código máquina, y es imposible >>>>> obtener el código de este lenguaje una vez compilado por lo que no >>>>> podrían obtener los datos. >>>>> >>>> >>>> >>>> Te equivocas, yo te lo vuelvo a repetir. Da igual que el programa sea >>>> compilado o no, se puede descompilar igualmente y acceder a los datos. >>>> >>>> >>> +1 >>> >>> >> Vale. Eso es ingeniería inversa, no? También quiero aprender eso, >> suena interesante. >> >> >>>>> Se supone que el software debería tener acceso a la base de datos. Si >>>>> puede hacer lo que quiera es un sí, aunque dudo importe demasiado la >>>>> respuesta a esta pregunta. >>>>> >>>>> Entonces como lo hacen softwares como algunos Adobe, donde debes >>>>> iniciar sesión para ocupar varios de sus productos? Con HTTP? >>>>> >>>> >>>> >>>> Como te indicaba en otra respuesta, centra la seguridad en la base de >>>> datos y el servidor. Una opción es esta, enviar por htp, o mejor aún por >>>> https, emplear sockets, etc, una solicitud de acceso al servidor, con un >>>> usuario y contraseña. Desde el servidor, se realiza una conexión a la >>>> base >>>> de datos, con los datos almacenados de dicha conexión en el servidor, y >>>> autenticar al usuario. Una vez que lo has autenticado, puedes devolver >>>> un >>>> tokken de conexión que valide las comunicaciones realizadas entre ese >>>> usuario y el servidor a través de la aplicación. Esto, si te fijas, es >>>> igual >>>> que cuando accedes a un servicio web introduciendo tu usuario y >>>> contraseña >>>> desde un navegador web. >>>> >>>> >>> Si lo que quieres es una aplicación cliente-servidor, donde el cliente se >>> ejecute desde la estación como una aplicación instalable, y además >>> requieres >>> (tus argumentos tendrás para ello) que se use conexiones a la Base de >>> Datos >>> >> >> Mis argumentos? Suponiendo que tengo 50 mil personas distintas con el >> software instalado, tendré 50 mil usuarios en la base de datos... no >> crees que eso es demasiado? >> >> No hablo de columnas de una tabla, sino de usuarios de la base de datos... >> > > Si tienes una base de datos con acceso de 50000 usuarios diferentes, > simplemente necesitarásuna base de datos que te permita albergar ese número > de usuarios, con un hosting que soporte sin problemas ese número de > conexiones. El número de usuarios no es un problema en sí mismo. Todo > dependerá de que utilices una base de datos apropiada, con la capacidad > suficiente para albergar los datos personales de los usuarios (correo, > contraseña, nombre, etc) y un servidor que te permita servir el número de > conexiones que requieres. > > > > >> mediante un único usuario, mi recomendación es mediar con una capa entre >>> el >>> cliente y la BD que exponga la interfaz que deseas que conozca el >>> cliente. >>> Dicha capa se encargará de la funcionalidad, la autenticación y la >>> seguridad >>> entre otros, y allí implementar el protocolo que más convenga. >>> >>> La comunicación con la base de datos quedará bajo este "Middleware", y >>> podrás protegerle mediante firewall u otras medidas, dependiendo de tus >>> recursos y arquitectura. >>> >>> Varios lenguajes tienen facilidades para crear estos componentes, >>> exponiendo >>> mediante "buses de servicio" u otros elementos, un API. Puedes >>> desarrollar >>> además uno propio, pero todo dependerá del alcance propuesto para la >>> aplicación, como por ejemplo, hacer uso de estándares como SOA. Estas >>> tecnologías no son exclusivas de los servicios WEB, aunque su uso este >>> más >>> extendido en ese campo. >>> >>> Con este componente mediando entre tus clientes y el modelo de datos, >>> puedes >>> desacoplar el desarrollo de este, haciendo uso incluso de un lenguaje de >>> programación distinto al usado en el servidor, y disponer de clientes >>> para >>> diferentes sistemas operativos, dispositivos o situaciones como >>> requerimientos de accesibilidad. >>> >>> Siempre encontrarás problemas de seguridad a resolver, pero todo >>> dependerá >>> de los requerimientos exigidos y hasta donde estés dispuesto a ceder y >>> tolerar. >>> >> >> Vale. Veo que ni un solo lenguaje haría lo que yo quiero (aunque >> pensándolo bien, era obvio). >> La solución creo que será que el cliente tenga una base de datos >> propia y que cada cierto tiempo se compare con la del servidor y se >> actualicen unas a otras. >> >> Entonces, conectar C++, Java, entre otros, a bases de datos como MySQL >> o MariaDB, no sirve de mucho? Excluyendo a SQLite obviamente. >> >> > Analiza los requisitos que requieres de capacidad y conexión del servidor, > así como de la base de datos. A partir de ahí, y viendo las capacidades de > los distintos sistemas de bases de datos y los servidores en el mercado, > podrás determinar qué opción es la mejor. > > > --- > El software de antivirus Avast ha analizado este correo electrónico en > busca de virus. > https://www.avast.com/antivirus > > -- Juan Lavieri Errar es de humanos, pero es mas humano culpar a los demás.
