android - support - iniciar sesion gmail con codigo de verificacion

Inicio de sesión de Android-Autenticador de cuenta vs Autenticación manual

Question

Estoy a punto de implementar el inicio de sesión junto con la autenticación de usuario en mi aplicación.

Mi primera idea fue hacerlo manualmente, registrar nombre de usuario y contraseña con el servidor, obtener auth token, guardarlo y usarlo en las solicitudes posteriores.

Después de buscar en Google, descubrí que la forma correcta de hacerlo en Android era usar Account Authenticator. He visto algunos ejemplos de su implementación, pero no entiendo la ventaja de hacerlo de esta manera. ¿Es porque puedo tener más de una cuenta almacenada? ¿Es por problemas de sincronización? Agradecería si alguien pudiera explicarme esto. Probablemente me haría entender mejor el código y por qué está haciendo lo que es.

Answer 1

Puedo tener más de una cuenta almacenada?

Sí. Vea cómo Google o Facebook lo hacen.

¿Es por problemas de sincronización?

Sí, necesita Cuenta para usar el Mecanismo de sincronización como SyncAdapter

¿Por qué deberías usar AccountAuthenticator ?

• Soporte de mecanismo de sincronización de fondo como SyncAdapter ;

• Forma estándar para autenticar usuarios;

• Soporta diferentes tokens;

• Cuenta compartida con diferentes privilegios

¿Qué es lo que hay que hacer?

1). Crear Authenticator ;

2). Crear Activity para el inicio de sesión de usuario;

3). Crear Service para comunicarse con la cuenta.

Condiciones.

AccountManager : administra la cuenta en el dispositivo. Solicite los tokens de autenticación que debería usar AccountManager .

AbstractAccountAuthenticator - componente para trabajar con tipos de cuenta. Contiene toda la lógica para trabajar con la cuenta (autorización, derechos de acceso, etc.) One AbstractAccountAuthenticator puede ser utilizado por diferentes aplicaciones (como la cuenta de Google para Gmail, Calendar, Drive, etc.)

AccountAuthenticatorActivity - Activity base, para autorizar / crear cuenta. AccountManager llama a esta cuenta si es necesario para identificarla (el token no existe o ha caducado)

¿Cómo funciona todo? Mira la imagen a continuación:

Pasos.

1). Crear Authenticator ;

Necesita extender AbstractAccountAuthenticator y anular 7 métodos:

• Bundle editProperties(AccountAuthenticatorResponse response, String accountType) link
• Bundle addAccount(AccountAuthenticatorResponse response, String accountType, String authTokenType, String[] requiredFeatures, Bundle options) link
• Bundle confirmCredentials(AccountAuthenticatorResponse response, Account account, Bundle options) link
• Bundle getAuthToken(AccountAuthenticatorResponse response, Account account, String authTokenType, Bundle options) link
• String getAuthTokenLabel(String authTokenType) link
• Bundle updateCredentials(AccountAuthenticatorResponse response, Account account, String authTokenType, Bundle options) link
• Bundle hasFeatures(AccountAuthenticatorResponse response, Account account, String[] features) link

Ejemplo:

public class LodossAuthenticator extends AbstractAccountAuthenticator {
private static final String LOG_TAG = LodossAuthenticator.class.getSimpleName();
private final Context mContext;
public LodossAuthenticator(Context context) {
super(context);
mContext = context;
}
@Override
public Bundle editProperties(AccountAuthenticatorResponse response, String accountType) {
return null;
}
@Override
public Bundle addAccount(AccountAuthenticatorResponse response, String accountType, String authTokenType, String[] requiredFeatures, Bundle options) throws NetworkErrorException {
final Intent intent = new Intent(mContext, CustomServerAuthenticatorSigninActivity.class);
intent.putExtra(Config.ARG_ACCOUNT_TYPE, accountType);
intent.putExtra(Config.ARG_AUTH_TYPE, authTokenType);
intent.putExtra(Config.ARG_IS_ADDING_NEW_ACCOUNT, true);
intent.putExtra(AccountManager.KEY_ACCOUNT_AUTHENTICATOR_RESPONSE, response);
final Bundle bundle = new Bundle();
bundle.putParcelable(AccountManager.KEY_INTENT, intent);
return bundle;
}
@Override
public Bundle confirmCredentials(AccountAuthenticatorResponse response, Account account, Bundle options) throws NetworkErrorException {
return null;
}
@Override
public Bundle getAuthToken(AccountAuthenticatorResponse response, Account account, String authTokenType, Bundle options) throws NetworkErrorException {
// If the caller requested an authToken type we don''t support, then
// return an error
if (!authTokenType.equals(AccountGeneral.AUTHTOKEN_TYPE_READ_ONLY) && !authTokenType.equals(AccountGeneral.AUTHTOKEN_TYPE_FULL_ACCESS)) {
final Bundle result = new Bundle();
result.putString(AccountManager.KEY_ERROR_MESSAGE, "invalid authTokenType");
return result;
}
// Extract the username and password from the Account Manager, and ask
// the server for an appropriate AuthToken.
final AccountManager am = AccountManager.get(mContext);
String authToken = am.peekAuthToken(account, authTokenType);
// Lets give another try to authenticate the user
if (TextUtils.isEmpty(authToken)) {
final String password = am.getPassword(account);
if (password != null) {
try {
authToken = sServerAuthenticate.userSignIn(account.name, password, authTokenType);
} catch (Exception e) {
e.printStackTrace();
}
}
}
// If we get an authToken - we return it
if (!TextUtils.isEmpty(authToken)) {
final Bundle result = new Bundle();
result.putString(AccountManager.KEY_ACCOUNT_NAME, account.name);
result.putString(AccountManager.KEY_ACCOUNT_TYPE, account.type);
result.putString(AccountManager.KEY_AUTHTOKEN, authToken);
return result;
}
// If we get here, then we couldn''t access the user''s password - so we
// need to re-prompt them for their credentials. We do that by creating
// an intent to display our AuthenticatorActivity.
final Intent intent = new Intent(mContext, AuthenticatorActivity.class);
intent.putExtra(AccountManager.KEY_ACCOUNT_AUTHENTICATOR_RESPONSE, response);
intent.putExtra(com.lodoss.authlib.Config.ARG_ACCOUNT_TYPE, account.type);
intent.putExtra(com.lodoss.authlib.Config.ARG_AUTH_TYPE, authTokenType);
intent.putExtra(Config.ARG_ACCOUNT_NAME, account.name);
final Bundle bundle = new Bundle();
bundle.putParcelable(AccountManager.KEY_INTENT, intent);
return bundle;
}
@Override
public String getAuthTokenLabel(String authTokenType) {
if (AccountGeneral.AUTHTOKEN_TYPE_FULL_ACCESS.equals(authTokenType))
return AccountGeneral.AUTHTOKEN_TYPE_FULL_ACCESS_LABEL;
else if (AccountGeneral.AUTHTOKEN_TYPE_READ_ONLY.equals(authTokenType))
return AccountGeneral.AUTHTOKEN_TYPE_READ_ONLY_LABEL;
else
return authTokenType + " (Label)";
}
@Override
public Bundle updateCredentials(AccountAuthenticatorResponse response, Account account, String authTokenType, Bundle options) throws NetworkErrorException {
return null;
}
@Override
public Bundle hasFeatures(AccountAuthenticatorResponse response, Account account, String[] features) throws NetworkErrorException {
final Bundle result = new Bundle();
result.putBoolean(KEY_BOOLEAN_RESULT, false);
return result;
}
}

Explicación:

Entonces, necesita ver solo 2 métodos: addAccount , getAuthToken .

En addAccount he agregado algunos parámetros de configuración, que serán utilizados por mi Activity para el inicio de sesión de usuario. El punto principal aquí es intent.putExtra(Config.ARG_ACCOUNT_TYPE, accountType); - debe especificar el tipo de cuenta aquí. Otras manipulaciones no son necesarias.

En getAuthToken : lee los comentarios por favor . UdinicAuthenticator.java y pegué este método desde UdinicAuthenticator.java

Además, necesitarás seguir los permisos en tu AndroidManifest.xml:

<uses-permission android:name="android.permission.GET_ACCOUNTS" />
<uses-permission android:name="android.permission.MANAGE_ACCOUNTS" />
<uses-permission android:name="android.permission.AUTHENTICATE_ACCOUNTS" />
<uses-permission android:name="android.permission.USE_CREDENTIALS" />

Resumen de los métodos addAccount y getAuthToken

Intenta obtener token, si el token existe, devuelve el resultado, de lo contrario verás Activity para autorización

2). Crear Activity para el inicio de sesión de usuario;

Ver AuthenticatorActivity

Breve explicación: crear formulario con UserId y Password. Utilizando los datos UserId y Password, obtén el token de autenticación del servidor y luego ejecuta el siguiente paso:

mAccountManager.addAccountExplicitly(account, accountPassword, null);
mAccountManager.setAuthToken(account, authtokenType, authtoken);

3). Crear un Service para comunicarse con la cuenta.

Ver UdinicAuthenticatorService

No olvides agregar esta línea en AndroidManifest.xml al Service :

 <intent-filter>
<action android:name="android.accounts.AccountAuthenticator" />
</intent-filter>
<meta-data android:name="android.accounts.AccountAuthenticator"
android:resource="@xml/authenticator" />

Y también en res/xml add file authenticator.xml :

<?xml version="1.0" encoding="utf-8"?>
<account-authenticator xmlns:android="http://schemas.android.com/apk/res/android"
android:accountType="com.mediamanagment.app"
android:icon="@drawable/ic_launcher"
android:smallIcon="@drawable/ic_launcher"
android:label="@string/authenticator_label"/>

Eso es todo. Puede usar su AccountAuthenticator .

Para materiales de origen gracias a

• Udi Cohen ;

• Daniel Serdyukov (todo el texto traducido de su artículo (excepto mis pequeñas adiciones) "Sincronización en aplicaciones Android. Parte 1" en ruso solamente. Enlace: http://habrahabr.ru/company/e-Legion/blog/206210/ )

Answer 2

El AccountManager es bueno por las siguientes razones:

• Lo primero es almacenar varios nombres de cuentas con diferentes niveles de acceso a las funciones de la aplicación en un solo tipo de cuenta. Por ejemplo, en una aplicación de transmisión de video, uno puede tener dos nombres de cuenta: uno con acceso de demostración a una cantidad limitada de videos y el otro con acceso de mes completo a todos los videos. Sin embargo, este no es el motivo principal para usar Accounts , ya que puede administrarlo fácilmente en su aplicación sin la necesidad de este aspecto de Accounts aspecto elegante ...
• La otra ventaja del uso de Accounts es deshacerse de la autorización tradicional con nombre de usuario y contraseña cada vez que el usuario solicita una función autorizada, ya que la autenticación se realiza en segundo plano y al usuario se le pide su contraseña solo en ciertas condiciones, lo abordaré más tarde.
• El uso de la función Accounts en Android también elimina la necesidad de definir el propio tipo de cuenta. Es probable que haya encontrado las aplicaciones que utilizan las cuentas de Google para la autorización, lo que ahorra la molestia de crear una nueva cuenta y recordar sus credenciales para el usuario.
• Accounts se pueden agregar de forma independiente a través de Configuración → Cuentas
• La autorización de usuario multiplataforma se puede administrar fácilmente usando Accounts . Por ejemplo, el cliente puede acceder al material protegido al mismo tiempo en su dispositivo android y PC sin la necesidad de inicios de sesión recurrentes.
• Desde el punto de vista de la seguridad, el uso de la misma contraseña en cada solicitud al servidor permite una posible escucha en conexiones no seguras. El cifrado de contraseña no es suficiente aquí para evitar el robo de contraseñas.
• Finalmente, una razón importante para usar la función Accounts en Android es separar a las dos partes involucradas en cualquier negocio dependiente de Accounts , denominado autenticador y propietario de recursos, sin comprometer las credenciales del cliente (usuario). Los términos pueden parecer bastante vagos, pero no te rindas hasta que leas el siguiente párrafo ... 😉

Permítanme detallar esto último con un ejemplo de una aplicación de transmisión de video. La Compañía A es la titular de una empresa de transmisión de video en contrato con la Compañía B para proporcionar a sus miembros ciertos servicios de transmisión de video premium. La Compañía B emplea un método de nombre de usuario y contraseña para reconocer a su usuario. Para que la empresa A reconozca a los miembros premium de B, una manera sería obtener la lista de ellos de B y utilizar un mecanismo similar de coincidencia de nombre de usuario / contraseña. De esta forma, el autenticador y el propietario del recurso son los mismos (Compañía A). Además de la obligación del usuario de recordar una segunda contraseña, es muy probable que establezcan la misma contraseña que el perfil de su empresa B para usar los servicios de A. Esto obviamente no es favorable.

Para disipar las deficiencias anteriores, se introdujo OAuth. Como un estándar abierto para autorización, en el ejemplo anterior, OAuth exige que la autorización sea hecha por la Compañía B (autenticador) al emitir un token denominado Token de acceso para los usuarios elegibles (terceros) y luego proporcionar a la Compañía A (propietario del recurso) el token Entonces, ningún token significa que no hay elegibilidad.

He elaborado más sobre esto y más en AccountManager en mi sitio web digigene.com/android/accounts-in-android-part-one

Answer 3

En la configuración de Android tienes cuentas para tu tipo de cuenta y desde allí puedes agregar una cuenta. AccountManager también es un lugar central para almacenar credenciales, por lo que solo debe iniciar sesión una vez para cada vendedor. Si descargas otra aplicación de Google o accedes a una aplicación varias veces, solo ingresas credenciales una vez