Re: [OFF] Lenguajes de programación para escritorio
El día 11 de febrero de 2016, 10:14, German Cardozo
<gcardozo@gmail.com> escribió:
>
> On Feb 11, 2016 7:38 AM, "Rafael Cantos Villanueva" <rafael@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
>>> <taberalf@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...
> 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.
Reply to: