Browsed by
Month: January 2012

Animer la rotation de l'écran du windows phone

Animer la rotation de l'écran du windows phone

 

Les animations et les transitions sont très importantes pour rendre votre application windows phone 7 sexy et la faire sembler performante.

Lorsque l’on parle de transition, on pense directement à l’animation entre les pages, or il existe un autre type de transition souvent mis de côté : l’animation de la rotation de l’écran lors du passage en mode portrait vers le mode paysage (en supposant que la propriété SupportedOrientation est mise à PortraitOrLandscape).

Par défaut le changement des écrans est direct, sans animations, or si on compare aux applications natives, on remarque que la rotation de la page est animée.

Afin de reproduire cet effet, j’ai développé un behavior qui une fois lié à votre page va se brancher sur l’évènement OrientationChanged de la page et va jouer un storyboard qui tournera la page.

Optimisation

Pour optimiser le processus, j’ai décidé de ne créer qu’un seul storyboard, qui sera créer au premier usage et qui sera réutilisé pour chaque animation (en changeant quelques valeurs).

De la même façon, je force la mise en cache bitmap de la page juste avant l’animation, la gestion du cache étant réinitialisé après cette dernière. De la même façon, la propriété IsHitTestVisible de la page est mise à faux afin d’éviter que l’utilisateur puisse interagir avec cette dernière pendant l’animation.

Utilisation

Pour utiliser le behavior, il suffit d’ajouter une référence vers la librairie Huyn.PageRotation, et de glisser le behavior sur la page dans Blend. Si toutefois vous êtes faché avec Blend (honte sur vous), voici le code :

 


 

xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity" xmlns:Huyn="clr-namespace:huyn;assembly=Huyn.PageRotation"

<i:Interaction.Behaviors>
<huyn:PageRotationBehavior/>
</i:Interaction.Behaviors>

Note

Pour la transition entre landscapeLeft et landscapeRight et inverse (soit donc 180°), a été calqué sur le comportement de la rotation des icônes de l’application bar, histoire d’avoir une cohérence entre les deux animations.

La librairie, le code source ainsi qu’une application exemple est disponible ici :

http://pagerotationwp.codeplex.com/

Détection des localisations de votre application par le marketplace

Détection des localisations de votre application par le marketplace

Suite à une question sur le forum MSDN : http://social.msdn.microsoft.com/Forums/fr-FR/wmdevfr/thread/de190a0e-d54b-46bb-b11b-8d8ec9b89ae1

Je suis en train de soumettre une appli sur le market dans pratiquement toutes les langues dispo sur Mango (en display language d’après ce lien http://msdn.microsoft.com/en-us/library/hh202918%28v=vs.92%29.aspx).

Le souci est que sur l’AppHub les seules langues proposé sont : English, English(international), French, German, Italian, Japanese, Korean, Spanish.

Dans mon csproj j’ai : <SupportedCultures>cs;da;de;en;es,fi;fr;it;ja;ko;nl;nb;pl;pt;ru;sv;zh-CN;zh-TW</SupportedCultures>

La balise est au bon endroit sinon je n’aurai aucun choix de langue.

Après un test, en effet, si je créé une application vide et que j’ajoute les cultures au csproj, le marketplace continuera à me proposer que la langue par défault (l’anglais dans la majorité des cas) comme langue.

En fait, le marketplace ne se contente pas d’analyser uniquement les SupportedCultures, il va aussi regarder quelles ressources sont disponibles dans votre application. Cela signifie que si je ne créé pas de fichiers ressources spécifiques pour chaque langue, alors celle ne disposant pas de fichier ressource seront ignoré par le marketplace.

Comment faire sans resx ?

Si jamais vous ne souhaitez pas utiliser les fichiers resx pour la gestion de la localisation de votre application (c’est votre choix !), il faudra quand même ajouter des fichiers ressources vides correspondant aux langues supportées par votre application.

 

SupportedCultures est-il utile alors ?

Oui, il va en fait servir de filtre, le marketplace va dans un premier temps lister les cultures dans SupportedCultures, mettre de côté la langue par défaut, et chercher si les autres cultures disposent de fichier resx, si ce n’est le cas, la langue sera ignoré par le marketplace

Additional tiles disappear by themselves

Additional tiles disappear by themselves

 

Since Mango, we can add additional tiles to the home screen of our Windows Phone. But, there is a small bug which is very annoying for the user and for the developer.

I met this problem with Fuse, additional tiles sometimes disappeared but was still visible by the application in the ShellTile.ActiveTiles list. Furthermore, as the tile is still shown, it was impossible for the user to re-add it cause a tile already exists for this uri. After a rebooting the phone, the tiles could reappear at the bottom of the home screen and not to their original positions.

The problem is necessarily the system, because the application is not even instantiated when the tiles disappear, the question is what is the problem and how to get around.

Introduction

When creating a new tile, we can specify two images, one for each face of the tile(BackgroundImage and BackBackgroundImage). This image can be an image stored in isolated storage or remote image. In the second case, the tile is displayed without background and when the image is downloaded, it appears.

The problem

The problem is that when the phone quits the lockscreen or an application, it will use the original state of tiles, including the background used when we create the tile, even if the tile has been updated since.

Do you have a solution ?

No , it’s a bug in the system, it will be a next update the system so that it works.

In December, the MSDN has been modified to warn of this problem, we can read the following information:

When creating a secondary Tile, the BackgroundImage and the BackBackgroundImage images must be created using a local resource.

 

A workaround?

You may have noticed, when you create a tile, the application closes, the home screen appears, and the tile is placed at the bottom of the screen. But …. your program is still running a little bit, so it is possible to create a tile without remote uri, and to update this tile in the same time (with remote uri this time).The tile is displayed with its distant uri, but was created without remote uri,your tile won’t disappear again!

So here is a little helper I coded that should help you. It can be used exactly the same way as ShellTile.Create, just replace ShellTile.Create by ShellTileExt.Create


namespace Huyn
{
public static class ShellTileExt
{
public static void Create(Uri uri, StandardTileData data)
{
var bgImage = data.BackgroundImage;
var backBgImage = data.BackBackgroundImage;

bool found = false;
if (bgImage != null && bgImage.IsAbsoluteUri)
{
data.BackgroundImage = null;
found = true;
}

if (backBgImage != null && backBgImage.IsAbsoluteUri)
{
data.BackBackgroundImage = null;
found = true;
}

ShellTile.Create(uri, data);

//if no distant uri, do nothing
if (!found)
return;

//find my tile
ShellTile mytile = ShellTile.ActiveTiles.FirstOrDefault(currentTile => currentTile.NavigationUri == uri);
if (mytile == null)
return;

//update the tile
mytile.Update(new StandardTileData() { BackgroundImage = bgImage, BackBackgroundImage = backBgImage });

}
}
}

How do I update my application that is experiencing this trouble?

Imagine that you have on the marketplace an application that uses additional tiles and experiencing this problem, even using my code and updating your application, the old tiles will continue to meet this concern, cause they were created with a remote uri. The only easy solution (as it is not conceivable to remove all tiles to replace them, the home of the user will be disturbed) is to simply alert the user that there a bug in windows phone, and if it meets the concerns, it can remove the tile and pin it again, the problemwill be fixed

Tuiles additionnelles qui disparaissent toutes seules

Tuiles additionnelles qui disparaissent toutes seules

 

Depuis Mango, nous pouvons ajouter des tuiles additionnelles à l’écran d’accueil du Windows Phone. Bien que très pratique, il existe un petit bug qui est très embêtant à la fois pour l’utilisateur qui voit ses tuiles disparaitrent sans raison mais aussi pour le développeur car le problème ne vient pas de lui.

C’est un problème que j’ai rencontré avec Fuse, des tuiles disparaissaient parfois mais était toujours visibles par l’application dans l’énumération ShellTile.ActiveTiles. De plus comme la tuile est toujours dans la liste, il était impossible pour l’utilisateur de les re-ajouter car une tuile existe déjà pour cette uri. Après un reboot du téléphone, les tuiles pouvaient réapparaître mais en bas de l’écran d’accueil et non à leurs positions d’origine.

Le problème vient forcément du système, car l’application n’est même pas instanciée quand les tuiles disparaissent, reste à savoir quel est ce problème et comment le contourner.

La base

Lorsque l’on créé une nouvelle tuile, on peut lui spécifier deux images, une pour chaque face de la tuile (BackgroundImage et BackBackgroundImage). Cette image peut être une image stockée dans l’isolated storage ou une image distante, téléchargée ensuite via internet par le système. Dans le second cas, la tuile est affiché sans fond et dès que l’image est téléchargée, celle-ci s’affiche.

Le problème

Le problème est que le téléphone, en retour de lockscreen ou en sortie d’application, va pendant un moment utiliser l’état d’original de la tuile, notamment le background utilisé lorsque l’on a fait un createTile, même si la tuile a été mise à jour depuis.

Si on a créé notre tuile avec une Uri distante, à ce moment là, si l’image n’est plus en cache et le téléphone va bogué, il va alors détruire la tuile (physique, donc l’UI) sans détruire l’association entre la tuile et l’application. Pour résumer, au niveau IHM, la tuile n’est plus présente, mais au niveau logique, elle est toujours là. C’est donc pour cela, qu’après un reboot, celle-ci reviendra mais ne reprendra pas sa place d’origine, elle sera à la place, en bas de l’écran d’accueil

La solution ?

Y’en a pas, c’est un bug du système, il faudra attendre une prochaine mise à jour du système pour que ca fonctionne.

En décembre dernier, la MSDN a été modifié pour alerter de ce problème, on peut ainsi lire l’information suivante :

When creating a secondary Tile, the BackgroundImage and the BackBackgroundImage images must be created using a local resource.

Un contournement ?

Evidemment ! La solution est de ne pas créer la tuile avec une uri distance (facile hein ?), mais bon, on a parfois pas le choix. Il existe donc une petite astuce, qui profite d’une petite latence du système.

Vous l’avez remarqué, quand vous créez une tuile, l’application se ferme, l’écran d’accueil s’affiche alors, et la tuile vient se placer en bas de l’écran. Mais…. votre programme s’execute encore un petit peu, il est donc possible d’enchaine directement la création de la tuile (sans Uri distante) avec une mise à jour de cette même tuile (avec Uri distante cette fois). La tuile est alors affiché avec son background distant, mais a été créée sans uri distante, votre tuile ne disparaitra donc plus !

Voilà donc un petit helper que j’ai codé qui devrait vous rendre service. Il s’utilise exactement de la même manière que ShellTile.Create, il suffira donc de remplacer tous les appels à ShellTile.Create par ShellTileExt.Create

namespace Huyn
{
public static class ShellTileExt
{
public static void Create(Uri uri, StandardTileData data)
{
var bgImage = data.BackgroundImage;
var backBgImage = data.BackBackgroundImage;

bool found = false;
if (bgImage != null && bgImage.IsAbsoluteUri)
{
data.BackgroundImage = null;
found = true;
}

if (backBgImage != null && backBgImage.IsAbsoluteUri)
{
data.BackBackgroundImage = null;
found = true;
}

ShellTile.Create(uri, data);

//if no distant uri, do nothing
if (!found)
return;

//find my tile
ShellTile mytile = ShellTile.ActiveTiles.FirstOrDefault(currentTile => currentTile.NavigationUri == uri);
if (mytile == null)
return;

//update the tile
mytile.Update(new StandardTileData() { BackgroundImage = bgImage, BackBackgroundImage = backBgImage });

}
}
}

Comment mettre à jour mon application qui rencontre ce soucis ?

Imaginons que vous avez déjà sur le marketplace une application qui utilise des tuiles additionnelles et qui rencontre ce problème, même en utilisant mon code et en mettant à jour votre application, les anciennes tuiles continueront à rencontrer ce soucis, car elle auront été créées avec une uri distante. La seule solution viable (car il n’est pas imaginable de supprimer l’ensemble des tuiles de l’utilisateur pour les remplacer, l’organisation de l’utilisateur sera alors perturbée) est de tout simplement alerter l’utilisateur qu’il y a un bug dans windows phone, et que s’il rencontre ce soucis, il peut supprimer la tuile et la remettre, le problème étant contourné.

Display a giant windows phone in Facebook chat

Display a giant windows phone in Facebook chat

I played with Facebook today and I discovered some nice hack.

Here is the first : Display a giant windows phone in facebook chat :

The result:

For that, just copy-paste this code :

[[308362632536465]][[308362662536462]][[308362682536460]][[308362712536457]]
[[308362735869788]][[308362759203119]][[308362779203117]][[308362795869782]]
[[308362809203114]][[308362825869779]][[308362872536441]][[308362905869771]]
[[308362942536434]][[308362972536431]][[308363009203094]][[308363022536426]]
[[308363042536424]][[308363069203088]][[308363115869750]][[308363135869748]]
[[308363155869746]][[308363189203076]][[308363215869740]][[308363239203071]]
[[308363282536400]][[308363309203064]][[308363342536394]][[308363375869724]]
[[308363405869721]][[308363419203053]][[308363435869718]][[308363469203048]]

I’ve made also a smaller version :

[[308359029203492]][[308359085870153]][[308359112536817]]
[[308356302537098]][[308356332537095]][[308356369203758]]
[[308356399203755]][[308356452537083]][[308356469203748]]
[[308356492537079]][[308356549203740]][[308356572537071]]
[[308356625870399]][[308356649203730]][[308356695870392]]
[[308356742537054]][[308356792537049]][[308356825870379]]

if you prefer

Comment fonctionne le site md5decryption.com

Comment fonctionne le site md5decryption.com

Comment fonctionne le site md5decryption.com ?

Encore plus simplement qu’un dictionnaire ou une rainbow table.

Le site dispose de deux partie, encrypt et decrypt, dans la partie encrypt on peut saisir une phrase et il nous retournera son md5. Dans la partie decrypt, à partir d’un md5 il peut nous retourner la phrase d’origine.

En fait, lorsque vous utilisez la partie encrypt du site, il va stocker dans sa base de données votre saisie et le md5 resultat.

Pour la partie decrypt du site, il va tout simplement aller voir dans sa base de données s’il a un md5 correspondant, sauf… qu’indirectement, c’est vous qui avez ajouté à la base de donnée votre donnée source, donc normal qu’il la retrouve.

Un exemple avec des captures. Imaginons que mon mot de passe est “unepomme”, son md5 est a44e271893f51d903bc85302b43f5070 (il est important de ne pas calculer son md5 à partir de md5decryption.com).

Demandons maintenant à md5decryption de retrouver mon mot de passe à partir du md5.

Veuillez donc noter qu’il n’arrive pas à trouver un mot de passe aussi simple. Maintenant allons dans la partie encrypt du même site et je vais lui demander de calculer le md5 de “unepomme”.

Très bien, ce n’était pas très dur non plus, mais en fait, il vient d’ajouter unepomme à sa base de donnée avec le md5, donc maintenant si je refais un decrypt du même md5 :

Quelle surprise, il trouve maintenant la donnée source, normal, vu que c’est moi qui vient de lui apprendre…

Par conséquent, le site en question ne sait pas décrypter du md5, il se contente de stocker les md5 calculés dans la partie encrypt du site et de faire une recherche dans sa base de données pour la partie decrypt. Cela signifie aussi qu’à chaque fois que vous utilisez la partie encrypt avec vos vrais données (mots de passe, etc…) vous les affaiblissez puisqu’il seront découvrable par les autres utilisateurs !!!

De la même façon, si pour tester, vous utilisé le même site pour encrypter vos md5 et pour décrypter ensuite, il aura en effet 100% de chance, c’est comme si je vous posais la question : “quel est ton prénom ?” et qu’ensuite après votre réponse je vous dis : je parie que tu t’appelles XXX !!!

PS : n’essayez pas avec “unepomme”, maintenant que je lui ai appris le md5 de ce mot, il vous le trouvera forcément 😉

Le MD5 est t'il cassable ?

Le MD5 est t'il cassable ?

La réponse est non évidemment !

Cette article fait suite à une publication d’un de mes collègues MVP, Olivier Dahan, à propos de la vulnérabilité du md5.

http://www.e-naxos.com/Blog/post/2012/01/07/La-fusee-de-Free-et-la-securite-informatique.aspx

Pour résumer, il est indiqué que le MD5 est très facilement crackable et que donc qu’il ne faut surtout plus l’utiliser dans les bases de données.

Voila la partie concernant la vulnérabilité du md5 :

si vous utilisez MD5 pour protéger des clés, des mots de passe, etc, sachez que cela ne sert à rien.

 

La leçon : vérifiez que vous n’utilisez pas MD5 dans vos applications (vous ou ceux qui vous ont précédé dans l’écriture des logiciels dont vous avez la charge). N’utilisez plus ce codage car tout le monde sait le percer rapidement.

 

La seconde leçon est plus malveillante : si vous tombez sur un fichier ou une base de données utilisant MD5 pour “planquer” des mots de passe ou des informations sensibles, hélas, vous savez maintenant comment décrypter tout cela et en faire éventuellement mauvais usage.

 

 

En effet, le MD5 à une vulnérabilité aujourd’hui, mais je vais essayer de démontrer pourquoi il ne faut pas s’inquiéter.

Qu’est ce le MD5 ?

MD5 (Message Digest 5) est un hashage, donc destructif, c’est pour résumer un moyen de calculer une clé par rapport à une donnée, dans tous les cas le MD5 fera 32 caractères hexadécimal.

Je vous laisse donc imaginer comment on pourrait “décrypter” un livre de Shakespeare à partir de son md5 (ou alors un peu comme dans les films où on arrive à zoomer 10000 fois sur une image de caméra de sécurité…)

Comment peut on retrouver la donnée d’origine depuis son md5 alors ?

Un des moyens pour de remonter à l’origine est aujourd’hui le brute forcing, c’est à dire : essayer tous les combinaisons de caractères qui peuvent exister et calculer leurs md5 pour le comparer, je vous laisse imager le temps nécessaire pour cela… A dans 10 siècles !

On peut toutefois aller un peu plus vite en utilisant un dictionnaire de mot existant, mais si la donnée d’origine n’est pas dedans, il est impossible de la retrouver. Cette méthode est encore moins fiable quand on sait que la majorité des sites utilisant le md5, “salt” la donnée auparavant. C’est à dire, que si votre mot de passe est “1234”, on va lui ajouter d’autre caractères avant de le hasher : “1234CeciEstLeSaltDeMonSiteWeb” et on calculera le md5 sur cette nouvelle chaine.

On peut aussi utiliser une rainbow table, c’est pour résumer une gigantesque base de données qui nous servira à prémacher le travail lors de la recherche. Pour vulgariser, on peut dire qu’au lieu de calculer les md5 d’un dictionnaire à chaque fois, on stocke le md5 résultat et on cherche ensuite dans ces résultats s’il n’y a pas un md5 qui vaut la valeur que l’on cherche. Encore une fois, si le site utilise un grand SALT et que le mot de passe n’est pas “simple”, c’est quasi impossible de le retrouver (à moins d’avoir un md5 d’un mot simple qui vaut la même valeur que le votre).

C’est avec cette dernière méthode qu’à été trouvé une correspondance au md5 “efb7929e6a5b7dcc6ebb79aa3c45af13”, qui est “jesaispas”. Mais ce dernier n’a été trouvé que parce qu’il appartenait au dictionnaire ayant servi à créer la rainbow table. Si ce dernier avait été “salté” ou jesaispas322, il n’aurait pas été possible de le trouver (il se peut même que la donnée source était autre chose mais que jesaispas avait le même md5, même si la proba est supra faible vu la simplicité de la donnée :D)

Mais il faut alors que j’utilise une autre méthode ?

Non.

Quelque soit le hashage que vous allez choisir, les trois méthodes précédentes seront toujours aussi fiable (enfin peu fiable). Que ce soit le brute forcing, le dictionnaire ou la rainbow table, on a toujours utilisé le sens “donnée source” -> “hash” et non l’inverse !!!!

Mais je suis sur que le MD5 est vulnérable !

Oui en effet le MD5 a une vulnérabilité, mais pas du tout dans le domaine qui nous concerne (stockage de mot de passe dans une base de données).

Une faille a été trouvée en 1996 puis amélioré fin 2004 concernant la possibilité de trouver des collisions MD5 (c’est-à-dire des blocs de données différents possédant la même MD5).

Ahh je l’avais dit !

Non, car en fait une collision est la possibilité à partir d’une donnée (mon mot de passe par exemple), de trouver une autre donnée ayant le même md5 !

Pour simplifier, imaginons que mon hashage n’est plus le md5, mais l’addition des valeurs des caractères de ma chaine, je vais pouvoir faire des collisions en inversant l’ordre des lettres car le résultat de l’addition de mes caractères sera toujours pareil.

En beaucoup plus complexe (mais sexy) c’est ce que l’on sait faire pour le MD5 (et aussi pour le SHA1).

Comme je l’ai préciser, pour calculer une collision il faut la donnée d’origine, c’est à dire que si je veux utiliser cela pour trouver un mot de passe dans une base de données, il me faut au préalable… le mot de passe que je cherche 😀

Il est toujours impossible de forger des données ayant un MD5 précis. 

Donc à quoi sert une collision ?

La faille de la collision peut servir par exemple de changer quelques bits dans la donnée et d’avoir le même MD5 au final, avec notamment l’intégration d'”invariant md5″, soit, un lot de données qui ne feront pas évoluer le md5 après inclusion. On trouve parfois des fichiers en téléchargement accompagné de leurs md5 pour vérifier l’authenticité du fichier. Grâce à cette faille donc, je peux modifier le fichier et avoir le même md5. Sauf que je ne suis pas libre des données modifiées/ajoutées, il est donc difficile d’imaginer intégrer un virus ou autre dedans.

Conclusion

Le MD5 dans son utilisation de hashage de mots de passe n’est pas aujourd’hui vulnérable, du moins il l’est autant que tous les autres algorithmes de hashage existant ou futur.