Usuarios bloqueados en Oracle

Si estáis trabajando con una aplicación vinculada a una base de datos y utilizando las capacidades de esta, si lo soporta, para gestionar usuarios, os podéis encontrar con el problema de que un usuario llegue al máximo numero de intentos de logueo y que, en consecuencia, se le bloquee la cuenta.

En Oracle para ver una lista de los usuario que tenemos y sus diferentes propiedades, como si esta bloqueado o no, hemos de ejecutar este comando en nuestro editor de SQL:





Esto nos permite ver cosas como:


 Cuando uno de estos usuarios llega al máximo numero de intentos de acceso y se bloquea, se actualizan el ACCOUNT_STATUS y el LOCK_DATE, y lógicamente el usuario no podrá entrar a la aplicación.

Para desbloquearlo:








Siendo el campo identified by, el password del usuario.

Por ultimo para ver el numero de intentos de logueo que tienen los usuarios:







Ya queda de nuestra mano el aumentar, hasta dejarlo ilimitado, o reducirlo!

Como crear y modificar un archivo .JAR

JAR (o Java ARchive): Es un formato utilizado normalmente para agrupar una serie de archivos .class de Java y los recursos que estos utilizan.

Pueden verse como archivos .Zip (y abrirse con un descompresor) aunque tambien pueden ser ejecutables, permitiendo que se lanza una aplicación desde ellos mismos.

Para crearlos, podemos hacer uso de un sencillo comando:



Ejemplo:

 


En ocasiones nos vemos en la necesidad de agregar un elemento concreto a un fichero .jar ya existente, y resultaría poco eficiente el crearlo de 0 y eliminar el anterior:




Hay que tener en cuenta que el JAR ha de estar en el directorio actual, sino habria que especificar su path, y tambien que si queremos meter el fichero dentro de una determinada carpeta del JAR deberíamos crear la misma estructura fuera para que vaya al sitio correcto.

 Para asegurarnos de que nuestro archivo ahora forma parte del JAR, o simplemente para saber que contiene, podemos ejecutar:

Tomcat JDBCRealm II - Funcionamiento

Segunda, y última, entrada sobre esta tecnología.

Quiero describir a mi manera los pasos que sigue Tomcat en este aspecto cuando se arranca y hasta que el usuario se trata de loguear en la Web.

Cuando iniciamos Tomcat podemos echar un vistazo en su log logs/catalina.out y veremos que nuestro Realm he empezado su andadura:



En cuanto este servicio se ejecuta va ir a la URL que le hemos proporcionado para tratar de establecer una conexión, para poder hacer esto requiere de un Usuario y contraseña validos de la base de datos con permisos de lectura sobre las tablas que luego va a utilizar, este Usuario esta almacenado en
el propio Realm que hemos definido:



 Aunque adicionalmente hay opción de sacarlo fuera, ya que el Realm va a utilizar el UserDatabase también definido en el mismo archivo:



Como se ve aquí el archivo que tiene la miga es el tomcat-users.xml que contiene una lista de los usuarios permitidos y el rol con el que se les permite la entrada al sitio web:











En cuanto Tomcat llega aquí trata de conectarse con la BBDD utilizando las credenciales que ha obtenido, esto lo hace mediante la clase JDBCRealm contenida en el catalina.jar de la librería de nuestro Tomcat que lanza el método authenticate() que tratara de abrir una conexión con los datos de los que se le ha proveído para posteriormente realizar una consulta a las tablas de Usuarios y Roles de Usuario que Tomcat nos ha obligado a crear para poder usar los Realms.





Si todo ha salido bien...enhorabuena estamos dentro!

Si no....

Tomcat JDBC Realm I - Creación

Los Realms de Tomcat son una lista de usuarios, passwords (y los roles asociados a estos), que permiten una forma de identificacion de un usuario en un sitio que utilice Tomcat como servidor.

Existen varias formas de implementar esta caracteristica en nuestro Tomcat (ahora mismo 6), y la que me ha tocado a mi, porque me ha tocado yo aqui no he elegido nada, es como la entrada indica JDBCRealm.

JDBCRealm se apoya en un driver JDBC para establecer una conexion entre la base de datos que utiliza tu web para buscar en ella los usuarios y grupos definidos por el creador como admitidos.

Para que funcione es necesario quela BBDD tenga:

1. Tabla Usuarios, con las columnas Usuario y Password.
2. Tabla Roles de Usuario, con las columnas Rol y Usuario

Hecho esto debemos copiar el driver ODBC que vamos a usar en nuestro y crear en base de datos un usuario con permisos de lectura para que Tomcat pueda usarlo para recuperar los resultados.

Finalmente tendremos que crear un Realm en nuestro server.xml para que todo esto funcione, algo tal que asi:

 

Git Error - push rejected non-fast forward

Este error que puede desconcertar un poco se produce al tratar de subir nuestros cambios al servidor remoto de GIT, lo que nos trata de decir es que no puede subir los cambios sin perder commits y por tanto quedaria alterado el historico.

Esto suele pasar si otro usuario ha realizado cambios en el repositorio remoto.

La forma mas sencilla de resolverlo es haciendo un pull sobre el remoto para que nos "actualice":



Y luego subiremos los cambios de forma normal:



Ojalá hubiese mas errores así de sencillos...

Seguir y dejar de seguir archivos en GIT

Una de las primeras cosas que se debe de hacer al empezar a trabajar con GIT es indicarle que archivos o directorios quieres que esten vigilados por el control de versiones.

Para hacer esto se utiliza el comando:

 

O en caso de querer seguir un directorio completo:

 

Con esto lograremos que cada vez que realicemos un cambio en uno de los ficheros seguidos GIT nos lo notifique al ejecutar el comando:





En ocasiones podemos tener la necesidad de que determiandos archivos de un proyecto no sean controlados por GIT, bien porque se trate de configuraciones personales o bien porque consideremos que no aportan nada al control de versiones.

Si queremos dejar de tener controlados esos archivos el comando a utilizar es:




o



Suficiente por hoy!