sql >> Base de Datos >  >> RDS >> PostgreSQL

¿Cómo puedo consultar de forma segura (indirectamente) una base de datos postgresql dentro de Android?

Versión rápida:

Utilice una capa intermedia de servicio web que se ejecute en un host público que controle (posiblemente, pero no necesariamente, el host de la base de datos). Exponga métodos de servicios web públicos para realizar el trabajo limitado que desea permitir y nada más.

Preguntas relacionadas:

Opciones de implementación

Personalmente, usaría un servidor de aplicaciones Java como Apache Tomcat o JBoss AS 7 y escribiría mis métodos de servicio web usando JAX-RS para producir una buena API de estilo REST para que la use mi aplicación. Eso es con lo que estoy familiarizado y funciona bien, pero tiene muchas opciones, incluidas implementaciones de:

  • API similares a REST (JAX-RS de Java implementa Jersey y RESTEasy, varias otras herramientas de idiomas) que usan solicitudes HTTP y producen respuestas JSON o XML.

  • SOAP con WSDL, la clásica capa de "servicio web". En Java hecho con JAX-WS entre otras opciones. La mayoría de los lenguajes tienen herramientas para SOAP+WSDL, pero es un poco complicado trabajar con ellos, especialmente en dispositivos conectados intermitentemente como los móviles.

  • XML-RPC si te gusta el dolor

Hay algunos JAX-RS quickstarts en las inicios rápidos de JBoss AS 7 lista; simplemente busque "JAX-RS". El "fregadero de cocina El inicio rápido es útil, aunque tal vez no sea ideal si no está familiarizado con los conceptos básicos de JBoss AS 7 y Jave EE 6. Para las especificaciones de JAX-RS, es mejor que consulte un tutorial de Jersey o RESTEasy como esto o esto .

Consideraciones importantes

Utilice HTTP si es posible y, si el acceso no va a ser público, utilice un esquema de autenticación HTTP adecuado, como la autenticación básica HTTP sobre HTTP. Cualquier implementación de servicios web decente ofrecerá opciones de autenticación o admitirá las de la plataforma en la que se ejecuta. Evite la tentación de implementar su propia autenticación y administración de usuarios en la capa de servicios web, podrá arruinarlo; use la autenticación en la capa HTTP que ya está escrita y probada. Esto puede requerir el uso de algo como mod_auth_pgsql de Apache , dominios de seguridad JDBC de JBoss AS 7, etc. El único caso en el que consideraría no realizar una autenticación HTTP adecuada por usuario es cuando no necesito separar a mis usuarios por razones de seguridad, solo me importa que sea mi aplicación la que acceda al servidor , es decir, si mis requisitos de seguridad son bastante débiles. En este caso, usaría un nombre de usuario/contraseña fijos para toda la aplicación y posiblemente un certificado de cliente X.509 si Android los admite.

Recuerde que no importa cómo asegure las cosas, todas las credenciales son conocidas por el usuario o pueden extraerse trivialmente de un .apk, por lo que aún debe suponer que cualquiera podría acceder a los métodos de su servicio web, no solo a su aplicación. Escríbelas en consecuencia.

no simplemente envíe SQL desde su aplicación a través de una llamada de servicio web al servidor y devuelva los resultados como JSON. Esto es horriblemente inseguro, además de feo y torpe. Escriba un método de servicio web para cada tarea individual que desee que la aplicación pueda realizar y mantenga el SQL en el servidor. Recuerde usar consultas parametrizadas y tenga cuidado con otros riesgos de inyección SQL. Estos métodos de servicio web pueden usar una o más consultas para producir una sola respuesta; por ejemplo, puede recopilar un registro de "Cliente" y todos los registros asociados de "Dirección" y "Contacto" y luego devolver el resultado en un buen objeto JSON en el dispositivo Android. puede consumir, ahorrando numerosos viajes de ida y vuelta de red lentos y poco confiables.

Independientemente de lo que utilice, asegúrese de realizar las llamadas al servicio web en un subproceso de trabajo en segundo plano y de no bloquear la interfaz de usuario. Esté preparado para tiempos de espera y errores, y para la necesidad de reintentos. Pruebe su aplicación simulando pérdida de conexión intermitente, alta latencia y altas tasas de pérdida de paquetes y asegúrese de que siga siendo utilizable.