Creo que el OP no tiene uso para una respuesta ahora. Sin embargo, esto merece una respuesta integral. De hecho, estoy sorprendido de que todavía no tenga uno.
En primer lugar, esta es una mala idea: una disposición como la propuesta por el OP es realmente demasiado insegura. Sin embargo, una solución al problema descrito puede ser un buen prototipo para alguien que esté creando un autologin para Liferay.
Ahora, digamos que desea iniciar sesión automáticamente en cualquier usuario cuyo nombre de pantalla se envíe en un parámetro de cadena de consulta. Por ejemplo, si uno accede al http://localhost:8080/web/guest/home?insecurely_login_user=juju, entonces el Liferay en el usuario juju debe iniciar sesión. ¿Cómo hacer eso? Siga los pasos a continuación:
crear la clase de sesión automático
En primer lugar, crear un plugin gancho. En su directorio docroot/WEB-INF/src, crea una clase que implementa la interfaz com.liferay.portal.security.auth.AutoLogin. En mi ejemplo, lo llamaré br.brandizzi.adam.liferay.insecure.InsecureAutoLogin.
La interfaz AutoLogin tiene sólo un método, llamado login(), que espera dos parámetros (a HttpServletRequest y un HttpServletResponse instancias) y devuelve una matriz de cadenas.Por lo tanto, mi clase se verá así sin aplicación:
public class InsecureAutoLogin implements AutoLogin {
@Override
public String[] login(HttpServletRequest request,
HttpServletResponse response) throws AutoLoginException {
// TODO Auto-generated method stub
return null;
}
}
El método AutoLogin.login() intentará recuperar la información necesaria para la autenticación de muchas fuentes, principalmente el objeto de solicitud. Si decide que el usuario debe iniciar sesión, devuelve una matriz con datos relevantes para la autenticación; si decide no iniciar sesión en el usuario, puede simplemente devolver null.
En nuestro caso, tratamos de obtener el nombre del usuario del parámetro insecurely_login_user de la solicitud. Si hay tal parámetro, procederemos con el inicio de sesión; Si no hay tal parámetro, sólo se devuelve null:
String screenName = request.getParameter("insecurely_login_user");
if (screenName == null || screenName.isEmpty()) {
return null;
}
Así que tienen el nombre de pantalla. ¿Qué hacer ahora? Permítanos obtener un usuario de la base de datos con el mismo nombre de pantalla.
long companyId = PortalUtil.getCompanyId(request);
User user = UserLocalServiceUtil.getUserByScreenName(companyId,
screenName);
Si una pantalla de un nombre de usuario, tales wich existe, se recuperará y se atribuye a la variable user. En este caso, la autenticación debería ser exitosa y la clase autologin debería devolver una matriz de tres cadenas: las credenciales . Esos son los valores que se devuelven como credenciales, en el orden en que deben aparecer en la matriz:
- el ID de usuario como una cadena
- la contraseña del usuario, que puede ser cifrada o no;
- un valor booleano, enviar a cadena, que indica si la contraseña está encriptada.
Así que aquí es la línea:
return new String[] {
String.valueOf(user.getUserId()),
user.getPassword(),
String.valueOf(user.isPasswordEncrypted())
};
Si no se encuentra un usuario, sin embargo, se produce una excepción. Entonces, tenemos que rodear el código anterior con una construcción try/catch. Si se produce una excepción, simplemente volver null:
try {
long companyId = PortalUtil.getCompanyId(request);
User user = UserLocalServiceUtil.getUserByScreenName(companyId,
screenName);
return new String[] { String.valueOf(user.getUserId()),
user.getPassword(),
String.valueOf(user.isPasswordEncrypted()) };
} catch (Exception e) {
return null;
}
Al final, esto es mi clase InsecureAutoLogin:
public class InsecureAutoLogin implements AutoLogin {
public String[] login(HttpServletRequest request,
HttpServletResponse response) throws AutoLoginException {
String screenName = request.getParameter("insecurely_login_user");
if (screenName == null || screenName.isEmpty())
return null;
try {
long companyId = PortalUtil.getCompanyId(request);
User user = UserLocalServiceUtil.getUserByScreenName(companyId,
screenName);
return new String[] { String.valueOf(user.getUserId()),
user.getPassword(),
String.valueOf(user.isPasswordEncrypted()) };
} catch (Exception e) {
return null;
}
}
}
El registro de la clase de sesión automático
Ahora nuestro gancho debe registrar esta clase como un procesador de autologin Eso es realmente fácil.
En primer lugar, editar el archivo docroot/WEB-INF/liferay-hook.xml adición de un elemento con el valor portal-propertiesportal.properties:
<?xml version="1.0"?>
<!DOCTYPE hook PUBLIC "-//Liferay//DTD Hook 6.1.0//EN" "http://www.liferay.com/dtd/liferay-hook_6_1_0.dtd">
<hook>
<portal-properties>portal.properties</portal-properties>
</hook>
Ahora, cree un archivo llamado portal.properties en docroot/WEB-INF/src. Debe contener una propiedad denominada auto.login.hooks cuyo valor debe ser el nombre de nuestra clase:
auto.login.hooks=br.brandizzi.adam.liferay.insecure.InsecureAutoLogin
Y eso es todo. Despliega este gancho y tu autologin funcionará.
Conclusión
Como ya he dicho, que no debe utilizar un método tan insegura "autenticación". Es muy fácil evitarlo, ¡obteniendo permisos de administración uniformes! Sin embargo, si sigues estos pasos, tienes un esqueleto para crear una mejor función de autologin. Además, sé que algunas personas realmente quieren hacer algo como este método inseguro "autenticación" y, a veces tenemos que suspender nuestros juicios y simplemente ayudar a uno para disparar los pies de uno ...
El código fuente de este proyecto puede encuentre here y puede descargar WAR here.
Quiero iniciar sesión un usuario de forma automática cuando se hace clic en un enlace, sin él tener que introducir el nombre y la contraseña . El nombre y la contraseña se guardan en nuestra base de datos de aplicaciones. – Luke
Aunque no sé por qué uno querría hacer eso: podría verificar la aplicación de muestra de LR que tiene este mecanismo como demostración ("iniciar sesión como Bruno", etc.). Aparte de eso, recomiendo utilizar algo como OpenID o CAS para minimizar el esfuerzo de inicio de sesión de los usuarios pero manteniendo un cierto nivel de seguridad. – Dirk
de acuerdo: Vaya con cualquier sistema de inicio de sesión único (por ejemplo, CAS) para que los usuarios solo se autentiquen una vez (o, si insisten, usen NTLM) y esta identidad se lleva a las aplicaciones. Se supone que las soluciones como el inicio de sesión de Bruno son para demostración, no para producción. También podría darle más permisos a su usuario invitado anónimo, para que ni siquiera necesite iniciar sesión si considera una solución de este tipo. –