Aurélien GALTIER

Windows Phone 7 et Login page

Comment bien structurer son application WP7 lorsqu’une page de login est requise. Prenons un exemple d’une application.

Cas de base

LoginView.xaml ----Clique sur Connecter-----> MainView.xaml

Problèmes :

• Aucun login automatique
• Le bouton back renvoie sur la page LoginView
• Le temps d’ouverture complet est long (Login + Main)

Cas de base avec autologin

Même navigation que dans le cas précédent. On utilise le login automatique à l’ouverture de la page si on a enregistré les informations dans l’isolatedstorage.

LoginView.xaml ----automatique-----> MainView.xaml

Problèmes :

• Le bouton back renvoie sur la page LoginView et il est impossible de quitter l’application car on est reconnecté à chaque fois.
• Le temps d’ouverture complet est long (Login + Main)

Cas avec GoBack

On reprend le même mode que dans le cas de base et on va maintenant utiliser RootFrame.GoBack(). Cela nous demande de restructurer la navigation de nos pages.

MainView.xaml ----Clique sur se connecter----->LoginView.xaml-----Clique sur connecter(GoBack)----->MainView.xaml

A la sortie d'une page lorsque l'on a vérifié les informations de login on fait GoBack() ce qui évite d'ajouter des pages dans la pile des pages précédentes.

Problème :

• Il vous faut prévoir une page principale en mode non connecté.
• Pas d'autologin
• Le temps d’ouverture complet est toujours long

Ajout d'autologin

Dans tous les cas vous êtes obligé de garder un token qui identifie votre utilisateur. Ce token peut être un cookie ou un identifiant unique généré. J'ai choisi un token que le serveur renvoie pendant la phase d'authentification. Je stocke le token dans l'isolatedstorage afin d'authentifier automatiquement l'utilisateur. J'envoie le token dans le header de chaque requête WCF.

Coté client :

  1: using(new OperationContextScope(base.InnerChannel))
  2: {
  3:     OperationContext.Current.OutgoingMessageHeaders.Add(
  4:         MessageHeader.CreateHeader(
  5:             "UserToken",
  6:             "http://www.neobd.fr/",
  7:             WcfService.UserToken));
  8: 
  9:     return Channel.BeginGetNewsPosts3(serieId, possede, firstRow, countRows, callback, asyncState);
 10: }

Pour plus de sécurité il faudrait sécuriser les connections. Mais je ne rentrerai pas dans ces détails.

Je récupère le token côté serveur et j'authentifie l'utilisateur pour tout le contexte d'exécution de cette requête WCF.

Côté serveur :

  1: var incomeMessageHeaders = OperationContext.Current.IncomingMessageHeaders;
  2: int indexToken = incomeMessageHeaders.FindHeader("UserToken", "http://www.neobd.fr/");
  3: var monToken = incomeMessageHeaders.GetHeader<string>(indexToken)

A ce moment là si le token n'est pas correcte alors je renvoie une exception avec le message "security". J 'ai un helper côté Windows Phone qui intercepte les exceptions avec le message "security" et qui renvoie vers la page de login.

  1: private bool hasSecurityException = false;
  2: 
  3: protected void ExecuteConnection(Action action) 
  4: { 
  5:     if (NetworkInterface.GetIsNetworkAvailable()) 
  6:     { 
  7:         try 
  8:         { 
  9:             action(); 
 10:         } 
 11:         catch (CommunicationException ex) 
 12:         { 
 13:             if (ex.Message == "security") 
 14:             { 
 15:                 if (!hasSecurityException) 
 16:                 { 
 17:                     hasSecurityException = true; 
 18:                     ApplicationMvvm.Navigate("/LoginView.xaml?auto=true"); 
 19:                 } 
 20:             } 
 21:             else 
 22:             { 
 23:                 Application_ErrorConnection(ex); 
 24:             } 
 25:         } 
 26:     } 
 27:     else 
 28:     { 
 29:         Application_ErrorConnection(null); 
 30:     } 
 31: }

Au passage lorsqu'il y a une erreur ou que la connexion n'est pas disponible j'affiche un message d'erreur dans la méthode "Application_ErrorConnection". Attention on est en asynchrone, il faut appeler cette méthode sur la méthode "End" dans le callback pour intercepter l’exception.

Ainsi dans le cas d’un fonctionnement normal. Ouverture de MainView.xaml avec chargement des données. Aucune phase d'authentification n'est effectuée. On récupère le token de la dernière authentification.

En cas d'erreur d'authentification (le token a expiré, mot de passe expiré, compte bloqué, …)

MainView.xaml---navigation automatique--->LoginView.xaml

La page LoginView fait une tentative automatique pour renouveler le token. Si celui ci échoue l'utilisateur reçoit une information concernant le problème d'authentification.

Avantage, le temps d’ouverture complet sera réduit dans la majorité des cas.

En résumé

Le mode de développement par page a son importance. Il permet d'avoir une application structurée et intuitive. Sans en abuser il faut se souvenir que l'on peut faire un GoBack().

Ses avantages :

• Dépile une page peu importante (Page de login, page d'inscription, page de sélection, …)
• Permet de quitter une page sans connaitre sa destination. Ce qui est pratique dans un page de login qui peut être appelée à différents moments.

Je n’ai pas expliqué dans l’article mais il peut y avoir plusieurs niveau à dépiler. La page principale qui appelle la page de login puis la page de création de compte. De la même manière les pages sont dépilé pour retrouver la page principale.

L’utilisation d’un token est requise pour le fonctionnement global de l’application. Pourquoi ne pas le stocker pour réduire la phase de login ce qui évite d’authentifier à chaque ouverture de l’application.