Auteur: Mikael KROK

Google met à disposition un DNS public afin que vous puissiez y faire vos nslookup. L’avantage, c’est la garantie de mise à jour de cet annuaire DNS…

8.8.8.8 est l’IP de ce DNS public. Plus de précisions ici : https://developers.google.com/speed/public-dns/?hl=fr

Auteur: Alain BELUT

J’ai voulu franchir le cap : Windows 7 vers Windows 8.

En réalité, je prévoyais de changer mon OS 32 bits pour un OS 64 bits. J’ai longuement hésité, en me demandant Windows 7 64 bits ou Windows 8 64 bits.
J’ai dû lire et relire ce qui se disait ici et là concernant les premiers retours de la version officielle de Windows 8.

Dans les critiques j’entendais :
- c’est déroutant, on a du mal à utiliser Windows. C’est contre productif et vraiment pas pratique. On est obligé de passer du bureau à l’interface avec les tuiles en permanence.
Très sincèrement, je ne sais pas si c’est parce que j’ai lu les critiques avant mais je trouve que Windows 8 est très simple d’utilisation. Finalement au lieu d’avoir la barre des tâches en bas, on a un équivalent qui apparaît lorsqu’on positionne le curseur en haut à gauche… Je n’ai pas eu besoin de plus de 4 minutes pour m’y faire ! Enfin, je ne crois pas que ce changement mérite une telle critique.
Alt-Tab permet toujours de passer d’une fenêtre à l’autre et lorsqu’on est dans le mode bureau, mis à part la disparition du bouton démarrer, il n’y a pas de grands changements insurmontables.

- c’est comme Vista : une version intermédiaire qui est buguée, qui ne convaincra pas.
Si elle n’arrive pas à convaincre c’est difficile à déterminer. Personnellement je pense que celui qui l’essaiera va aimer… A moins qu’il soit complètement terrifié par quelques changements mineurs (placer la souris en haut à droite de l’écran pour avoir un accès à tout)…
Dire que Windows 8 est bugué, me semble pour le moment injuste… J’ai pu sans soucis installer et utiliser Visual Studio 2012, SQL Server 2008 R2, des outils de sauvegardes et quelques outils indispensables pour mes développements et que j’utilisais sous Windows 7.
48h après, je ne vois aucun soucis ! Aucun plantage. Aucune récupération de situation par Windows pour un programme qui aurait crashé !

- il faut avoir un écran tactile, c’est vraiment pas pratique avec la souris.
Il est vrai qu’avec un écran tactile, faire défiler serait sans doute plus simple. Mais en même temps cela reste parfaitement exploitable.

Ma conclusion :

Au final, l’expérience est très bonne. Je suis vraiment admiratif du nouveau design de l’O/S et je n’ai qu’une envie développer une application à placer dans le Windows Store. Les 75 Euros d’abonnement annuels ne me font pas peur et j’espère être présent sur Téléphone, Tablette, et PC.

Non ce qui me fait peur et me poussait de toutes façons à découvrir le nouveau O/S c’est plutôt l’API WinRT tant poussée par Microsoft qui semble vouloir faire oublier l’Api WIN32. Une vraie révolution qui s’annonce. Et même si je me doute que cela ne se fera pas du jour au lendemain, je crains quand même d’être dépassé ! Et quand on sait que Microsoft va dépenser la plus grosse campagne de communication pour faire adopter Windows 8, on se dit qu’il ne faut pas trop rester spectateur mais bien devenir acteur.

Microsoft l’a dit, il vise avec Windows 8, le particulier et non plus l’ingénieur. Il vient chasser sur le terrain d’Apple et je crois qu’il s’y prend bien !
On verra ce que nous réserve l’avenir.

Windows 8 est vraiment intéressant à découvrir. Il ne nuit pas à la productivité et n’est pas lourd à utiliser. Au contraire, il apporte de l’animation dans un style Mac, dans un univers qui PC qui reste austère. Evidemment les linuxiens et autres fans d’écrans noirs de type console ne vont pas du tout apprécier… Pour les autres, cela vous apportera un Windows plus animé, plus agréable à regarder, plus ludique tout simplement et une impression de changer d’O/S…

A faire !

Auteur: Alain BELUT

Depuis Windows Vista, une application qui n’est pas signée, téléchargée sur le Web, provoquera une alerte de sécurité.

Cela pénalise votre application car l’utilisateur aura une alerte de sécurité de la part de Windows. Politique de Microsoft pour relancer la vente de Certificats comme certains le prétendent ou simplement volonté de l’éditeur de renforcer la sécurité au maximum… Il est préférable de signer vos applications avec un certificat.

1) Obtenir un certificat

Pour cela vous devrez vous tourner vers un organisme tel Verisign, GlobalSign, Comodo…
La plupart des organismes proposent des tarifs très avantageux (à partir de 100$ / an) si vous souhaitez un certificat à titre individuel. Pour une entreprise en revanche il faudra sortir un peu plus. De 200$ à 500$ pour une année, des remises sont proposées pour la souscription sur 2 ou 3 ans.

Après avoir choisi une autorité de certification, vous devrez compléter un formulaire en ligne et fournir un maximum d’informations sur votre identité ou celle de votre entreprise. Adresse, numéro de téléphone, numéro d’inscription au RCS, numéro de TVA, etc… Vous devrez choisir un mot de passe pour votre compte et aussi pour votre certificat. A ne pas perdre ! Vraiment pas, à moins de vouloir griller votre certificat. Même si généralement, les organismes vous permettent de recréer un certificat en cas d’oublis, il ne le feront pas forcément 10 fois de suite.

L’organisme que vous solliciterez prendra quelques jours (3 à 7) pour vérifier votre identité. Ils sont cette obligation bien évidemment.

Pour un particulier, vous devrez adresser des documents justifiant qui vous êtes : Passeport, carte d’Identité, Permis de Conduire etc…

Pour une entreprise, il y aura forcément une prise de contact par téléphone et vous devrez fournir un numéro de téléphone référencé dans un annuaire public (pages jaunes par exemple…), sinon une facture de téléphone stipulant votre numéro, les coordonnées de l’entreprise seront demandé. Et sinon enfin, si vous ne pouvez pas justifier de ce numéro de téléphone, un courrier d’un « homme de loi » (avocat, huissier, comptable…) attestant que le numéro vous appartient sera aussi demandé.

Les vérifications réalisées, vous pourrez télécharger le certificat PFX sur le site Web de l’organisme sélectionné. Vous devrez vous rappeler de vos mots de passe !

2) Utilisation du certificat

Le certificat pfx désormais copié sur votre ordinateur, vous pouvez l’utiliser pour signer vos Assemblies. Et pour cela vous aurez besoin de l’utilisateir signtool.exe de Microsoft. Si cet utilitaire a été distribué avec plusieurs éditions de Visual Studio, dans les dernières versions depuis la 2008, ce n’est plus le cas ! Et il est donc probable que signtool.exe soit absent de votre ordinateur. Vous devrez dans ce cas télécharger le SDK Windows ici et procéder à l’installation des utilitaires .NET. Vous voilà équipé de l’indispensable !

Vous pouvez signer votre application en ligne de commandes MS-DOS :
[CheminVersSigntool]\signtool.exe sign /t [UrlTimeStamp] /f [CheminVersCertificatPFX] /p [MotDePasseCertificatPFX] [CheminAssemblyASigner]
exemple :
« c:\program files\microsoft sdks\windows\v7.1\bin\signtool.exe » sign /t http://timestamp.globalsign.com/scripts/timestamp.dll  /f « c:\certificats\124ARI.pfx » /p password « c:\projets\MonProjet\bin\Release\MonProgramme.exe »

L’URL de serveur Time Stamp permet de dater la signature. C’est un horodatage indispensable.

On peut signer de cette façon, EXE, DLL, SETUP…

3) Signature automatique pendant le Build avec Visual Studio 2010

Il est possible de faire procéder à la signature des programmes générés pendant la compilation avec Visual Studio. Cela vous assurera de ne jamais oublier de signer les assemblys qui doivent l’être.

Pour un projet (DLL, EXE autre) :
Dans l’Explorateur de Solutions, clic Droit sur le projet concerné et clic sur Propriétés.
Dans le menu de gauche de la fenêtre ouverte, cliquez sur Signature et décochez []Signer les manigestes ClickOnce.
Dans le menu de gauche, cliquez sur Evénements de build et ajoutez dans la zone de texte Ligne de commande de l’événement Post-Build la ligne de commande vu précédemment en (2) en l’adaptant un peu :
[CheminVersSigntool]\signtool.exe sign /t [UrlTimeStamp] /f [CheminVersCertificatPFX] /p [MotDePasseCertificatPFX] « $(TargetPath) »
exemple :
« c:\program files\microsoft sdks\windows\v7.1\bin\signtool.exe » sign /t http://timestamp.globalsign.com/scripts/timestamp.dll  /f « c:\certificats\124ARI.pfx » /p password « $(TargetPath) »

A chaque compilation, votre fichier de sortie sera signé.

Pour un projet de SETUP :
Dans l’Explorateur de Solutions, clic gauche sur le projet de Setup. Dans les Propriétés du projet (fenêtre de propriétés traditionnelle), vous verrez le paramètre PreBuildEvent. Cliquez sur le bouton … pour faire apparaître une fenêtre de saisie acceptable et saisir comme précédemment, l’instruction de signature un peu adaptée :
[CheminVersSigntool]\signtool.exe sign /t [UrlTimeStamp] /f [CheminVersCertificatPFX] /p [MotDePasseCertificatPFX] /d « Description obligatoire – (c)MonEntreprise » « $(BuiltOuputPath) »   (et oui c’est bien BuiltOuputPath avec Ouput et non pas Output !)
exemple :
« c:\program files\microsoft sdks\windows\v7.1\bin\signtool.exe » sign /t http://timestamp.globalsign.com/scripts/timestamp.dll  /f « c:\certificats\124ARI.pfx » /p password /d « Description obligatoire – (c)MonEntreprise » « $(BuiltOuputPath) »

Le /d « description » est nécessaire pour le setup, sans quoi votre setup afficherait un nom aléatoire au moment de l’installation et ce ne sera pas très appréciable.

4) Conclusion

Il est finalement simple de générer des applications signées authentifiées et donc d’apporter plus de sécurité aux utilisateurs. Cela a un coût, mais si vous distribuez des applications vous n’avez plus vraiment la possibilité de vous passer de ces certificats qui permettent simplement à un utilisateur de votre application d’avoir la quasi certitude que vous en êtes bien l’auteur. Si cela peut sembler inutile, en y réfléchissant bien, c’est plutôt très pratique.

Auteur: Alain BELUT

Contexte : le but est de partager un dossier pour des personnes habilitées sur un réseau d’entreprise en s’appuyant sur l’Active Directory.

1)  Partager le dossier en donnant les droits MAXIMUM au compte « Tout le monde » (Everyone)

-    Clic droit sur le dossier puis cliquer sur Propriétés (Properties)
-    Dans la fenêtre de propriétés cliquer sur l’onglet Partage (Sharing)
-    Définir le nom de partage du dossier puis cliquer sur le bouton Autorisations (Permissions)
-    Si besoin ajouter le compte Tout le monde (Everyone) en cliquant sur le bouton Ajouter.
-    Au niveau des droits (permissions) accorder tout, c’est-à-dire : Contrôle total (Full Control)

A ce stade le dossier est partagé pour tout le monde et n’importe qui du réseau peut y faire n’importe quoi (consulter, ajouter, modifier, supprimer)

2)  Le partage fait, rendant accessible le dossier, il faut maintenant affiner les droits en utilisant NTFS :

-   Clic droit sur le dossier puis cliquer sur Propriétés (Properties)
-   Dans la fenêtre de propriétés cliquer sur l’onglet Sécurité (Sécurity)
-   Le compte « Tout le monde » est présent et la liste de ses droits NTFS stipule que tout est permis.
-   Décocher la case tout en bas de la fenêtre Autoriser l’héritage des permissions des parents…(Allow inheritable permissions from parent to propagate…). Une fenêtre demandera s’il faut réimporter les droits existants ou non, cliquer sur COPIER de sorte que les droits des parents soient réimportés à l’objet avant que nous n’appliquions nos nouvelles règles.
-    A ce stade, vous pouvez décider clairement des droits pour le compte « Tout le monde » (Everyone) ou tout autre compte que vous ajouteriez par le biais du bouton Ajouter (Add).

Les comptes qui accéderont aux partages se verront attribués les droits NTFS.

Le concept à retenir :

1)   On partage en Full Access pour définir par défaut un partage en accès complet.
2)   On limite au niveau NTFS les droits comptes par comptes car les droits les plus restrictifs l’emportent toujours.

Si on définit des droits restrictifs au niveau du partage, ce sont ces droits qui l’emporteront sur NTFS et cela provoquera de véritable crise de nerfs si l’on pense pouvoir donner certains droits d’accès à certains utilisateurs et pas à d’autres. Le principe de base est donc de toujours avoir à l’esprit : je crée un partage en accès complet et je limite ensuite les autorisations via NTFS.

Exemple :

 Je veux partager le dossier « Documents Classifiés » aux utilisateurs Achile et Hervé. Achile devra uniquement pouvoir LIRE les documents et Hervé devra pouvoir aussi éditer ces documents.

1)     Clic droit sur le dossier « Documents Classifiés » puis cliquer sur Propriétés.
2)     Clic sur onglet « Partage » puis donner un nom de partage au dossier. Par exemple « DocumentsClassifiés ».
3)     Clic sur le bouton « Autorisations » puis attribuer à « Tout le monde » le « Contrôle total »
4)     Clic sur le bouton « Appliquer ».
5)     Clic sur l’onglet « Sécurité » pour définir en finesse les droits via NTFS.
6)     Décocher la case « Héritage des droits »
7)     Ajouter le compte « Achile » et lui donner les droits de Lecture et Exécution.
8)     Ajouter le compte « Hervé » et lui donné les droits de Lecture, Exécution, Modification…
9)     Supprimer le compte « Tout le monde »

Seuls Achile et Hervé peuvent accéder au contenu du partage

Seul Hervé peut modifier le contenu du partage.

Auteur: Alain BELUT

Lorsque l’on fait appel à un service WCF via des requêtes HTTP on peut vouloir utiliser un proxy nécessitant une authentification.

Solution

Pour pouvoir configurer un proxy avec authentification depuis une application cliente qui utilise donc un service WCF, une solution est de coder ceci :

var svc = new MonService.ServiceClient();
var b = svc.Endpoint.Binding as BasicHttpBinding;
b.UseDefaultWebProxy = true;

A ce stade nous indiquons que nous souhaitons utiliser le Proxy Web par defaut pour tous les appels.

Il nous suffit de configurer le proxy par défaut :

WebProxy proxy = new WebProxy(new Uri(http://xxxxxxxx/));
proxy.Credentials = new NetworkCredential(login, password);
WebRequest.DefaultWebProxy = proxy;

Problème

Très bien… Maintenant, les tests sont plus compliqués. Si le service appelé par le client est un service local (ce qui peut arriver en tests), donc accessible via localhost ou 127.0.0.1 , cela ne fonctionnera pas. Le proxy sera forcément ignoré. Et il n’y a pas d’alternative. Une solution consiste à publier le site sur un autre serveur pour tester de sorte que le service soit appelé avec une autre adresse IP et que le proxy soit bel et bien appelé…

Infos complémentaires

var b = svc.Endpoint.Binding as BasicHttpBinding;
b.UseDefaultWebProxy = true;
b.BypassProxyOnLocal = false; // n’aura aucun impact. Et n’est de toutes façons pas fait pour ce cas.
b.ProxyAdress = new Uri(http://XXXXXXX/);  //spécifie un proxy mais ne donne pas moyen de passer une authentification.

Auteur: Alain BELUT

la Recomposition: Nouvelle « donne » 2012 ?

Vous trouverez ci-dessous la présentation.

Bonne lecture