Restringir el acceso a la agrupación de conexiones en Weblogic?
https://stackoverflow.com/questions/2312342
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
En pocas palabras, ¿cómo puedo restringir el acceso a la piscina de conexión X basado en nombre de la aplicación o el nombre del JAR? Un simple caso de uso podría ayudar ...
Una aplicación web de negocios (lo llaman WEB_APP_A) usos Piscina y hacer básica de consulta de SQL. Algunos usuarios de esta aplicación Web tienen acceso a actualizar también algunos datos sensibles en la base de datos. Este código es proporcionado por un archivo JAR (llámese HR_JAR) que se puede caer en donde sea necesario. Este sistema utiliza JAR piscina X para todas sus conexiones.
No queremos que los desarrolladores de WEB_APP_A utilizando piscina X. Sólo queremos HR_JAR utilizando piscina X. Esto es para mantener los desarrolladores de WEB_APP_A abusen accidental o intencionalmente el acceso a la piscina X proporciona.
Algunas consideraciones:
- Este es el código heredado de manera HR_JAR está aquí para quedarse
- Estamos funcionando en Weblogic 9.2
- No se puede mantener las contraseñas en cualquier partir del código fuente
- Hemos investigado WebLogic nivel de usuario authn / authz de recursos JDBC pero esto plantea la pregunta; ¿Cómo aseguramos los creds de usuarios que utilizamos para convertirse en un usuario por aplicación / frasco?
ideas? Pensamientos? Puedo elaborar más de lo que he intentado, pero quería ideas frescas.
Solución 2
No hay una buena manera de hacer esto por lo que yo puedo decir. Hay algunos trucos inteligentes con AspectJ pero al final es más problemas de lo que vale la pena.
Otros consejos
¿No han intentado alguna vez esto y no tienen acceso a una instancia de jugar en este momento, pero en su JDBC configuración que podría intentar agregar un elemento <scope> para la aplicación de la piscina contra X, dentro de la <jdbc-data-source-params> creo ... a pesar de que se supone que tiene una aplicación separada definido para HR.jar, que no estoy seguro es el caso de su descripción. No sé si se puede restringir un JAR individual dentro de una aplicación sin embargo.
