Implementación del manejador de desafíos en aplicaciones JavaScript (Cordova, Web)
improve this page | report issueVisión general
Requisitos previos: Asegúrese de leer la guía de aprendizaje de la implementación del manejador de desafíos de CredentialsValidationSecurityCheck.
El manejador de desafíos mostrará características adicionales (API) como, por ejemplo, las características login
, logout
y obtainAccessToken
preferentes.
Inicio de sesión
En este ejemplo, UserLogin
espera los valores clave llamados username
y password
. De forma opcional, también acepta una clave booleana rememberMe
, que le pide a la comprobación de seguridad que recuerde el usuario durante más tiempo. En la aplicación de ejemplo, lo recopila un valor booleano del recuadro de selección en el formulario de inicio de sesión.
userLoginChallengeHandler.submitChallengeAnswer({'username':username, 'password':password, rememberMe: rememberMeState});
Es posible que desee iniciar sesión en un usuario sin recibir desafíos. Por ejemplo, mostrar una pantalla de inicio de sesión como la primera pantalla de la aplicación, una pantalla de inicio de sesión después de cerrar sesión, o un error de inicio de sesión. Denominamos a dichos escenarios inicios de sesión preferentes.
No puede llamar la API submitChallengeAnswer
si no hay desafíos a los que responder. Para estos escenarios, el SDK de Mobile Foundation incluye la API login
:
WLAuthorizationManager.login(securityCheckName,{'username':username, 'password':password, rememberMe: rememberMeState}).then(
function () {
WL.Logger.debug("login onSuccess");
},
function (response) {
WL.Logger.debug("login onFailure: " + JSON.stringify(response));
});
Si las credenciales no son correctas, la comprobación de seguridad devuelve un desafío.
Es responsabilidad del desarrollador saber cuando utilizar login
, en lugar de submitChallengeAnswer
, en función de las necesidades de la aplicación. Una forma de conseguirlo es definiendo un distintivo booleano, por ejemplo isChallenged
, y establecerlo en true
cuando se alcance handleChallenge
, o establecerlo en false
en los otros casos (error, éxito, inicialización, etc).
Cuando el usuario pulsa el botón Iniciar sesión, puede elegir dinámicamente qué API desea utilizar:
if (isChallenged){
userLoginChallengeHandler.submitChallengeAnswer({'username':username, 'password':password, rememberMe: rememberMeState});
} else {
WLAuthorizationManager.login(securityCheckName,{'username':username, 'password':password, rememberMe: rememberMeState}).then(
//...
);
}
Nota: La API
WLAuthorizationManager
login()
tiene sus propios métodosonSuccess
yonFailure
; también se llama a los manejadores de desafíoshandleSuccess
ohandleFailure
del manejador de desafíos relevante.
Obtención de una señal de acceso
Como esta comprobación de seguridad da soporte a la funcionalidad RememberMe (como la clave booleana rememberMe
), sería de gran utilidad comprobar si el cliente tiene una sesión iniciada cuando se inicia la aplicación.
El SDK de Mobile Foundation permite que la API obtainAccessToken
le pida al servidor una señal válida:
WLAuthorizationManager.obtainAccessToken(userLoginChallengeHandler.securityCheckName).then(
function (accessToken) {
WL.Logger.debug("obtainAccessToken onSuccess");
showProtectedDiv();
},
function (response) {
WL.Logger.debug("obtainAccessToken onFailure: " + JSON.stringify(response));
showLoginDiv();
});
Nota: La API
WLAuthorizationManager
obtainAccessToken()
tiene sus propios métodosonSuccess
yonFailure
; también se llama a los manejadores de desafíoshandleSuccess
ohandleFailure
del manejador de desafíos relevante.
Si el cliente ya ha iniciado sesión o está en estado recordado, la API da como resultado “éxito”. Si el cliente no ha iniciado sesión, la comprobación de seguridad devuelve un desafío.
La API obtainAccessToken
incluye un ámbito. El ámbito puede ser el nombre de su comprobación de seguridad.
Obtenga más información acerca los ámbitos en la guía de aprendizaje Conceptos de autorización.
Recuperación del usuario autenticado
El método handleSuccess
del manejador de desafíos recibe data
como parámetro.
Si la comprobación de seguridad establece AuthenticatedUser
, el objeto contiene las propiedades del usuario. Puede utilizar handleSuccess
para guardar el usuario actual:
userLoginChallengeHandler.handleSuccess = function(data) {
WL.Logger.debug("handleSuccess");
isChallenged = false;
document.getElementById ("rememberMe").checked = false;
document.getElementById('username').value = "";
document.getElementById('password').value = "";
document.getElementById("helloUser").innerHTML = "Hello, " + data.user.displayName;
showProtectedDiv();
}
Aquí, data
tiene una clave denominada user
que contiene JSONObject
que representa a AuthenticatedUser
:
{
"user": {
"id": "john",
"displayName": "john",
"authenticatedAt": 1455803338008,
"authenticatedBy": "UserLogin"
}
}
Cierre de sesión
El SDK de Mobile Foundation también proporciona una API logout
para cerrar sesión de una comprobación de seguridad determinada:
WLAuthorizationManager.logout(securityCheckName).then(
function () {
WL.Logger.debug("logout onSuccess");
location.reload();
},
function (response) {
WL.Logger.debug("logout onFailure: " + JSON.stringify(response));
});
Aplicaciones de ejemplo
Se asocian dos ejemplos a este tutorial:
- PreemptiveLogin: Una aplicación que siempre se inicia con una pantalla de inicio de sesión mediante la API
login
preferente. - RememberMe: Una aplicación con recuadro de selección Recuérdame. El usuario podrá ignorar la pantalla de inicio de sesión la próxima vez que se abra la aplicación.
Los ejemplos utilizan la misma comprobación de seguridad UserLogin
del adaptador de SecurityCheckAdapters del proyecto Maven.
- Haga clic para descargar el proyecto Maven de SecurityCheckAdapters.
- Haga clic para descargar el proyecto Cordova RememberMe.
- Haga clic para descargar el proyecto Cordova PreemptiveLogin.
- Haga clic para descargar el proyecto Web RememberMe.
- Haga clic para descargar el proyecto Web PreemptiveLogin.
Uso de ejemplo
Siga el archivo README.md del ejemplo para obtener instrucciones. El nombre de usuario/contraseña de la aplicación debe coincidir, por ejemplo “john/john”.
Inclusive terminology note: The Mobile First Platform team is making changes to support the IBM® initiative to replace racially biased and other discriminatory language in our code and content with more inclusive language. While IBM values the use of inclusive language, terms that are outside of IBM's direct influence are sometimes required for the sake of maintaining user understanding. As other industry leaders join IBM in embracing the use of inclusive language, IBM will continue to update the documentation to reflect those changes.