Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

N'étant pas un professionnel et l'orthographe, j'ai toujours pris l'habitude de localiser mes applications. J'ai très vite trouvé mon intérêt dans le fait d'avoir un seul endroit où trouver tous les textes à corriger.

Cela m'a aussi forcé à ne rien mettre en dure dans le code et à toujours en extraire ce qui était localisable. Ceci m'a évité nombre d'erreurs. Vous comprendrez donc que je m'énerve quand je tombe sur un programme qui me parle dans ma langue et qui me prose de répondre dans une autre :

Je crois que la capture parle d'elle-même. Je me suis bien énervé sur le « O » de oui, avant de taper le « Y » de yes.

Amis développeurs, s'il vous plait retenez cet exemple comme étant une erreur à ne pas reproduire.

Si au passage, vous pouviez faire attention à l'encodage des textes, ce serait top ;)

Merci

 

PS : En plus c'était pour désinstaller un produit…. Arg !!!!

Vous cherchez les mises à jour pour Test Professional, mais vous ne les trouvez pas ? C'est normal, il n'y en a pas. Ou du moins, il n'y a pas de package de mise à jour propre à ce produit. Celui-ci dépendant de Visual Studio, il faut utiliser l'iso des updates de Visual Studio. Ceci métra à jour vos clients TFS, comme les compléments Office.

Capture de l'Update 3

En faisant le ménage dans mes captures d'écran, je suis tombé sur cette petite perle qui m'avait fait sourire : c'est une boite de dialogue qui s'affiche après la création d'un projet d'équipe via le site web de Visual Studio Online.

 

 

Bonne année et bon code pour 2015.

Je vous souhaite un bon Visual Studio 2015 tout neuf et tous les beaux produits qui vont avec !

Aujourd'hui, je m'attaque à un fleau bien connu du monde TFS : l'utilisation d'une édition SQL Enterprise qui empêche de migrer son TFS vers une édition inférieure (type Standard ou Express).

Tout administrateur TFS, le sait, la solution est simple. Il suffit de supprimer les features Enterprise activées sur les bases de données à migrer. En soit, rien de compliquer. Par contre quand il faut l'appliquer à une un gros volume de collections... cela devient vite rébarbatif.

Pour faciliter la chose, j'ai réalisé un script SQL bien pratique :

-- Déclarations
declare 
 @DataBase sysname

-- Crusor pour aller chercher les bases de données
declare databases_cursor cursor for
select db.name
from sys.databases as db
where db.name like 'tfs_%';

open databases_cursor

-- Passer à la base suivante
fetch next from databases_cursor into @DataBase

while @@FETCH_STATUS=0
begin
    -- Changement de propriétaire
	exec('exec [' + @DataBase + '].dbo.prc_EnablePrefixCompression @online = 0, @disable = 1');

	-- Passer à la base suivante
	fetch next from databases_cursor into @DataBase
end

close databases_cursor
deallocate databases_cursor

 

Note, en plus d'empêcher la migration, si l'édition SQL Server est inapproprié, car induisant des features superflues, on peut contacté un usage de la RAM plus important que ce qu’il devrait être.

Exemple constaté : TFS 2013, SQL 2012, une trentaine de collections, 2 CPU, 4 Gb RAM. Après suppression de la compression, le serveur utilise 11% de RAM en moins et les performances pour les utilsaiteurs sont restées identiques.

Voilà, bonnes migrations ;)

Mauvaise surprise pour les utilisateurs de Windows Technical preview sur Windows To Go : Les upgrades de builds ne sont pas possibles.

J'ai testé avec les toutes les builds disponibles à ce jour, et aucune ne permet l'upgrade.

Voici le message obtenu :

Note : Windows Update reste fonctionnel.

Grand fan de Windows To Go, je me suis lancé dans la préparation d'un disque externe avec Windows 10. Dans un élan de folie, j'ai voulu tenter l'opération à partir de mon Windows 8.1 Enterprise.

Bonne surprise, ça marche. Cela fait maintenant une semaine que j'utilise la Technical Preview Enterprise à partir d'un support Windows To Go.

Le déploiement a suivi les étapes classiques d'une installation Windows To Go à partir d'un PC Windows 8.1.

Il faut ouvrir son panneau de configuration. Utiliser le raccourci Windows To Go.

 

On sélectionne sa clé USB ou son disque externe.

 

On ajoute le chemin vers le disque (ici, j'ai monté l'iso sur F:\)

 

On fait suivant (hors mis si on veut tester BitLocker)

 

Et c'est parti

 

Ensuite il faut patienter

 

La dernière boite de dialogue propose de rebooter. On peut la fermer sans apporter de modification a sa machine et utiliser le disque.

 

Testé et approuvé ;)

Aujourd'hui, je vous propose un petit tour d'horizon des possibilités offertes par IIS et .net pour personnaliser ses pages d'erreurs.

Première chose à assimiler, il ne faut pas confondre les pages d'erreurs de nos applications .net et les pages d'erreur IIS :

  • La première catégorie sert principalement à afficher les erreurs internes à nos applications (exceptions diverses)
  • La seconde catégorie contient toutes les erreurs clients et applicatifs IIS qui peuvent être utilisée par des applications autres qu'ASP .net (erreurs 400-500 type : page introuvable, site indisponible, accès refusé …)

La première catégorie d'erreur se gère assez facilement via la section customErros du fichier web.config. Il n'y a pas grand-chose à dire. Vous pouvez gérer les erreurs dans vos applications web, et choisir sur quel client on veut ou non afficher les erreurs en détail. Dans certains cas, vous risquez d'être en grosse galère, car les pages d'erreur IIS peuvent prendre le dessus sur vos pages d'erreurs ASP.net. Un développeur .net doit donc avoir connaissance des possibilités offertes par la personnalisation des pages d'erreur IIS.

La seconde est bien plus intéressante car elle offre des possibilités de personnalisations aux hébergeurs et administrateurs système. Ceci de manière uniforme quelle que soit la technologie utilisée. Certes les pages ainsi personnalisées sont en général statiques (pour éviter de donner trop d'informations aux utilisateurs finaux), mais au moins elles sont chartes aux couleurs de la société.

Pour ceux qui n'auraient jamais fait attention, voici une capture du panneau IIS qui met en avant les deux zones de configurations :

 

Pour présenter correctement la chose, j'ai choisi d'utiliser le plan suivant :

  1. Activité les erreurs personnalisées IIS
  2. Scope de la configuration des pages d'erreurs
  3. Possibilité 1 : Modification de la configuration machine et Structure du dossier des pages d'erreurs
  4. Possibilité 2 : Embarquer les pages dans son site
  5. Possibilité 3 : Hébergement sur un serveur dédié

Ma volonté étant de vulgariser les pages d'erreurs IIS pour les développeurs .net, j'omettrai volontairement un certain nombre de détails. Je n'aborderai donc pas des notions comme :

  • Les pages détaillées
  • Les redirections/réécritures de pages
  • La possibilité absolument diabolique d'empêcher les développeurs de personnaliser les pages d'erreurs (c'est méchant ça !)

Attaquons donc dans le vif !

 

1. Activité les erreurs personnalisées IIS

En soit, l'activation des pages personnalisées n'a rien de bien compliquer. Sur un poste client, il suffit d'aller dans le panneau de configuration t d'ajouter une fonctionnalité Windows.

Ici sur un Windows 8.1 en français : « Erreurs http » 

 

Sur un serveur, il faut ajouter une fonctionnalité au rôle IIS. Ici sur un Windows 2012 R2 qui a déjà cette fonctionnalité activé : « Erreurs HTTP (Installé) » 

Aucun reboot n'est utile.

 

2. Scope de la configuration des pages d'erreurs

La configuration des pages d'erreurs étant enregistrée dans un fichier *.config section system.webServer (nœud httpErrors). Voici ce à quoi ressemble la configuration par défaut :

Il est possible de la modifier à différents endroits :

  • applicationHost.config
  • web.config

Bien entendu, machine.config ne fait pas parti des possibilités envisageables. Imaginez une page d'erreur qui change en fonction de la CLR ou de la plateforme ciblée (32 ou 64bits). Ce serait un cauchemar !

 

En fonction de l'endroit où l'on configure la section system.webServer, il est donc possible de personnaliser les erreurs pour :

  • Tous les sites d'un même serveur (applicationHost.config)
  • Un site (web.config)
  • Une application (web.config)
  • Un répertoire virtuel ou non (web.config)

La configuration peut donc être très souple. Via la console IIS, on dispose même d'une interface très pratique. Celle-ci permet de changer une page d'erreur existante et d'ajouter/supprimer des erreurs.

 

Le formulaire de configuration d'une erreur reste simple, à condition de comprendre les trois possibilités de personnalisation offertes par IIS.

 

3. Possibilité 1 : Modification de la configuration machine et Structure du dossier des pages d'erreurs

La première possibilité offerte consiste dans l'usage de pages statiques stockées sur le serveur. Il s'agit de la configuration par défaut de IIS. Les fichiers sont stockés dans le répertoire « %SystemDrive%\inetpub\custerr\ » (donc bien souvent dans C:\ inetpub\custerr\).

Si vous le souhaitez, vous pouvez choisir d'utiliser des pages qui diffèrent en fonction de la langue de l'utilisateur (pages localisées). Pour cela, il suffit de créer un répertoire par langue. Exemple : ici le français (fr-FR)

 

Lors de la saisie, si la case «Essayer de retourner le fichier d'erreur dans le langage client » est cochée, le bouton définir est disponible. Il permet d'accéder au formulaire suivant :

Dans le cas où cette case n'est pas cochée, vous ne pourrez pas avoir de pages d'erreurs localisées. Il faudra donc donner le lien complet vers la page d'erreur.

Voici par exemple, la configuration obtenue en personnalisant uniquement deux pages (401 localisée et 403 non localisée)

Notes :

  • errorMode doit être défini sur Custom pour que votre configuration soit prise en compte
  • On peut utiliser un noeaud <clear/> si on veut supprimer les autres pages.

 

4. Possibilité 2 : Embarquer les pages dans son site

Il s'agit là de l'approche préférée des développeurs. Les pages font partie du site. On peut en profiter pour avoir une page dont le contenu change dynamiquement (exemple erreur 403 du fichier de configuration suivant).

 

5. Possibilité 3 : Hébergement sur un serveur dédié

Cette approche est très pratique dans le cas d'une ferme IIS. Les fichiers n'ont pas besoin d'être répliqués sur l'ensemble des serveurs de la ferme. Cette approche comme la précédente permet d'avoir une page dont le contenu change dynamiquement (exemple erreur 403 du fichier de configuration suivant).

 

Voilà, j'espère que cet article vous donnera envie de considérer cette possibilité de personnalisation de IIS.

Aujourd'hui je suis toujours surpris pas la complexité mise en place pour sécurisées des informations (bases de données, partages de fichiers, FTP…). Pour une même application, il y a les développeurs qui vont stocker 50 comptes qui ne sont utilisés que par l'application (ou le groupe d'applications qu'ils gèrent). Pour ne pas distribuer les mots de passe sur les serveurs, ou les pc clients, on se retrouve souvent avec trois solutions qui parfois se complètent:

  • Le stockage de logins, mots de passe cryptés (dans l'application ou le fichier de configuration).
  • L'utilisation d'un API tiers de sécurité pour stocker logins et mots de passe (parfois avec un mot de passe ou token d'accès qui lui n'est pas sécurisé)
  • L'impersonation pour que le processus s'exécute avec des droits d'un autre utilisateur.

Il y a peut-être d'autres solutions que je n'ai pas croisées.

Dans tous les cas, on finira systématiquement avec un problème : « il y aura toujours un mot de passe qu'une personne devra conserver », ou « une personne qui aura accès à l'information sans restriction ».

Exemples absurdes, car l'utilisateur aura accès quoi qu'il soit décidé :

  • Ne pas vouloir donner accès à un site SharePoint alors que l'utilisateur est administrateur de la collection contenant le site.
  • Ne pas vouloir donner accès à un partage alors que l'utilisateur gère aussi le compte qui sert au backup de ce dossier (donc un compte qui lui aura accès quoi qu'il arrive)
  • … etc ….

Chacun a connu dans sa carrière l'une de ses situations absurdes. Je sais d'expérience qu'il y a des personnes qui préfèrent ne pas expliquer la situation : « c'est sécure ! ». Personnellement, j'ai toujours bataillé pour que la situation soit claire. Il n'y a pas de sécurité dans l'opacité.

La solution simple :

1. L'humain :

Ne pas prendre un responsable de votre société, car dans la plupart des cas, ils ne sont pas formés à la sécurité et risquent de compromettre l'information.

Exemple typique de ce type d'utilisateur :

  • Téléphone sans verrouillage d'accès posé sur une table.
  • PC laissé session ouverte lors de la pause pipi.
  • Lien vers les mots de passe sur le bureau Windows.
  • … etc…

Mettre en avant une personne « administrateur système » ou un « administrateur applicatif ». Cette personne a l'accès complet à l'outil et la sécurité fait partie de son métier. S'il faut conserver un mot de passe, c'est lui qui doit le faire.

 

2.  Le technique simple

La quasi-totalité des applicatifs peut utiliser une authentification Windows (aussi appelée authentification intégrée sur certaines applications comme SQL Server). Ce qui permet aussi la centraliser la gestion des comptes dans l'Active Directory. Notre administrateur aillant accès à l'AD, il pourra immédiatement couper un compte si besoin. Ceci est très pratique dans le cas d'applications compromises, ou changer le mot de passe rapidement.

A partir du moment où l'on utilise ce mode d'authentification, il n'est plus utile de stocker des chaines de connexion avec mot de passe dans l'applicatif ou le fichier de configuration. Ni même de stocker un mot de passe. Le ou les processus lancés se feront avec les droits de l'utilisateur qui a lancé le processus.

Pour chaque type d'application, il y a une solution simple qui s'appuie sur un compte Windows:

  • Application Windows classique : Le compte d'ouverture de session est utilisé
  • Site Web : Le compte du pool IIS est utilisé.
  • Planificateur de tâche : On peut déterminer un compte lors de la mise en place
  • Service Windows : On peut déterminer un compte lors de la mise en place
  • SharePoint : On a une liste de compte géré.

Note : On peut faire encore plus simple si l'on n'a pas besoin d'accéder aux ressources d'autres machines. On peut utiliser un compte système (ou un compte intégré à IIS par exemple)

 

3. Le technique un peu plus évolué

Si l'authentification Windows n'est pas disponible et qu'il faut sécuriser des données, on stocke les données cryptées dans un fichier de configuration. Mais avant de crypter les données, il faut commencer par extraire les clés machines qui serviront au cryptage.

Sans ces clés, votre fichier ne pourra pas être déployé hors de la machine qui a servi au cryptage. Ceci est très important pour une ferme IIS, ou pour un plan de reprise d'activité (PRA). Il s'agit là d'une erreur qui est malheureusement trop courante.

Il y a une documentation très claire que l'on peut trouver ici : http://msdn.microsoft.com/en-us/library/ff650304.aspx

Cette page date un peu, mais son contenu reste valable. Vous y trouverez le nécessaire pour sécuriser vos fichiers de configuration de manière fiable et portable.

 

Voilà. Vu que sécurité rime avec simplicité, j'espère que ces petites vous seront utiles et vous faciliterons la tâche.

Après avoir lu avec beaucoup d'attention l'annonce de S. Somasegar, j'ai été surpris de ne pas trouver de lien direct vers l'ISO de Visual Studio 2015.

Ce matin, une recherche sur Bing ou Google ne donnait pas grand-chose. Ce soir la donne a un peu changé et on peut enfin trouver facilement le lien vers la preview ici :

http://www.visualstudio.com/en-us/downloads/visual-studio-2015-downloads-vs

Petit avertissement pour les plus distraits : c'est le second lien qu'il faut utiliser pour obtenir l'ISO complète. Le premier pointe vers l'installer web.

Bons tests ;)

Un petit bug existe sur le package Oracle Database Client (12.1.0.2.0) for Microsoft Windows (32-bit) qui se trouve sur la page de téléchargement suivante : http://www.oracle.com/technetwork/database/enterprise-edition/downloads/database12c-win64-download-2297732.html

Le fichier oranfsodm12.dll est manquant, ce qui empêche l'utilisation de SQL*Loader.

En recherchant dans la documentation, on découvre qu'il s'agit d'une version modifiée de la librairie oraodm.

https://docs.oracle.com/database/121/NTDBI/postcfg.htm

 

En copiant oraodm12.dll et en la renommant oranfsodm12.dll on obtient une dll de remplacement utilisable sans NFS. On peut donc l'utiliser sur un poste client, mais on ne profitera pas de fonctionnalités du client direct NFS documenté ici (en version 11) :

http://www.oracle.com/technetwork/articles/directnfsclient-11gr1-twp-129785.pdf

 

Si la solution est acceptable dans un environnement, de développement, sur un environnement de production, il sera préférable de se procurer la DLL présente dans le package DataBase. Seul hic, ce package n'existe pas en 32 bits L

 

Derrière ce titre étrange se cachent quelques conseils sur l'utilisation de dépendance externes à vos projets. Que ce soit dans le cadre d'une maintenance, de la migration d'une application ou tout simplement dans l'évolution d'une application, des dépendances mal gérées peuvent faire capoter votre projet.

1. Lister ses dépendances

Il n'y a rien de pire qu'un projet dont on ne connait pas les dépendances. Savoir quelles dépendances on a, s'est déjà connaitre une partie de ce que l'on a besoin pour faire fonctionner son application. Dans certains cas, si vous connaissez les dépendances, vous pouvez même anticiper certains problèmes.

Si l'on ne connait pas ses dépendances, il est possible que l'on ne puisse pas déployer l'application.

Dans le cadre d'une migration, c'est une étape primordiale. Cette liste vous permettra de savoir quelles dépendances pourront être conservées, mises à jour, ou devront être supprimés. Si trop de dépendances n'existent pas sur la plateforme cible, il est possible que cela change complètement la philosophie de votre projet de migration en le transformant en projet de réécriture complète (pas de chance).

2. Ne garder que des dépendances utiles

Cette remarque vous fait sourire ? Si oui, avez-vous déjà listé les dépendances utilisées par le Template d'application web de Visual Studio ? Êtes-vous certain d'avoir besoin de toutes celles-ci pour votre projet ?

Il y a trop de projets qui incluent des dépendances pour effectuer des opérations déjà possibles avec les Frameworks. Exemple : sur un projet .net on peut déjà faire de la compression ou du cryptage sans utiliser de dépendances supplémentaires (et ça n'est pas très compliqué).

Parfois, il y a de dépendances que l'on garde par habitue. Il faut être vigilant avec celles-ci et régulièrement se tenir informé sur les évolutions de son Framework pour vérifier que celles-ci ne sont pas devenues inutiles. Exemple : avec le passage de Windows 8.0 à 8.1, j'ai supprimé plus de la moitié de mes dépendances, car j'ai presque trouvé tout ce dont j'avais besoin dans WinRT et les évolutions de Xaml.

3. Bien choisir ses dépendances

On a vite fait de lancer une recherche sur CodePlex, Nuget…etc… pour aller chercher des dépendances censées nous simplifier la vie. Certain préfèrerons acheter des composants aux près de fournisseurs bien connus comme DevExpress, Telerik… etc…

Quelle que soit la source des dépendances, il faut s'assurer de :

  • La viabilité de la source : un projet maintenu par un seul développeur très actif peut être parfaitement viable. Mais qu'en est-il d'un projet dont il n'y a toujours eu qu'une version ?
  • La fraicheur de la dépendance : un produit qui n'a pas été mis à jour depuis longtemps est un produit qui est peut-être mort. Il n'a donc pas d'avenir. Un bon indicateur pour identifier un projet mort, c'est de vérifier qu'il utilise un Framework récent. Exemple : une dépendance qui cible .net 2 en 2014… c'est risqué.
  • La maintenance corrective et évolutive : Un produit acheté doit toujours l'être avec ses mises à jour. Cela vous permettra de profiter des correctifs de celui-ci. Ce surcout doit être considéré avant tout achat pour éviter des débordements sur votre budget. J'ai déjà vu des projets en galère, car les bugs induits par les dépendances ne peuvent être résolus.
  • Regarder les breacking change : toujours vérifier si une dépendance est habituée à induire des breackin change suite à ses mises à jour. S'il y en a beaucoup, vous aurez beaucoup de travail à fournir lors des mises à jour.

4. Les dépendances ont des dépendances

On l'oublie souvent, mais une dépendance peut induire l'utilisation d'autres dépendances. Rien de pire que le message disant : «  la dépendance X où l'une de ses dépendances ne peut être résolue…. ».

À ce titre, vous devez appliquer les mêmes précautions sur celles-ci que sur vos dépendances directes. Il faut aussi être très prudent sur le fait qu'une dépendance n'aille pas à contrario des contraintes qui vous sont imposées. Exemple : Dépendance indirecte qui dépend de .net 4.5 alors que vous ciblez .net 4.0.

5. Garder un œil sur ses dépendances

Comme votre application, les dépendances évoluent. Ceci peut être pour votre plus grand bonheur. Mais ceci peut aussi être un véritable casse-tête à gérer.

Les problèmes pouvant être anticipés si on suit l'actualité de ses dépendances :

  • Breaking changes
  • Classes/Méthodes obsolètes
  • Classes/Méthodes abandonnées
  • Classes/Méthodes remplacées par d'autres
  • Ajout/suppression de dépendances indirectes
  • Abandon du projet par l'éditeur
  • .. etc…

Outre le fait de suivre ses informations, il faut aussi mettre à jour régulièrement ses dépendances. Ceci permet de réduire le travail à fournir. Si on espace les mises à jour de plusieurs mois ou années, on s'expose à de grands risques. Exemple : perte de temps, delta trop important entre deux versions et donc situation difficilement gérable.

6. Garder ses dépendances au chaud

Il faut toujours stocker les dépendances et/ou les fichiers qui ont servi à leur déploiement. Que ce soit sur un TFS, un SharePoint ou un simple partage. Ces fichiers vous seront indispensables pour remonter un environnement. Que ce soit un environnement de développement ou de production.

Même si aujourd'hui des dispositifs types Nuget sont devenus fréquents, j'ai toujours pris l'habitude de conserver les fichiers téléchargés par ceux-ci. Qui sait, la source sera peut-être coupée un jour.

Stocker, c'est bien, mais il faut aussi penser à noter clairement la plateforme cible. Il n'y a rien de pire que d'avoir deux DLL avec le même nom, le même numéro de version et ne plus savoir laquelle est destinée au 32 bits ou au 64 bits.

 

Il est fort probable que j'oublie une ou deux petites choses, mais l'essentiel est là.

Et vous, auriez-vous d'autres conseils à donner sur la gestion des dépendances ?

Depuis ce début d'après-midi, on peut aussi profiter des Minidrones de Parrot avec une tablette Windows 8.1 !

Contrairement à la version Windows Phone, cette version n'est pas en beta.

L'ensemble des fonctionnalités déjà présentes sur iOS, Androïd et Windows Phone sont disponibles, exception faite de la partie sociale. L'application a exactement la même ergonomie que sur les autres plateformes. On peut donc passer de la tablette au téléphone sans se poser de questions.

Je viens de tester avec un Rolling Spider et ma tablette Asus Vivota. On retrouve les mêmes comportements qu'avec un Windows Phone. C'est aussi bon. J'ai tout de même préféré utiliser le mode de pilotage dit « manette » , car utiliser le gyroscope de la tablette pour déplacer le drone m'a semblé trop étrange (voir inutilisable du fait de la taille de la tablette 10pouces). Il y a une option associée à bing map, mais cela ne semble pas marché comme convenu. Il y a un petit problème de compte développeur Bing Map ;) (en tout cas, c'est ce que j'ai constaté sur ma tablette)

Pour le téléchargement, cela diffère d'une machine à l'autre. Par exemple mon PC portable n'a pas accès à l'application (Dell XPS 17)

Belle exemple d'application universelle adaptée ;)

Maintenant, il me reste à m'acheter une seconde batterie pour mon drone. 10 minutes de jeux, c'est court quand on reste un grand gamin..

Depuis ce matin, on peut enfin profiter des Minidrones de Parrot avec un Windows Phone !

L'application est en beta pour le moment, mais l'ensemble des fonctionnalités déjà présentes sur iOS et Androïd semblent disponibles. D'ailleurs l'application a exactement la même ergonomie.

Je viens de tester avec un Rolling Spider et mon Lumia 1520 (Windows Phone 8.1 Cyan) et c'est bon, c'est même très bon ;)

Pour le téléchargement, cela se passe par ici.

Heureux propriétaire de SSD Samsung 840 EVO, j'ai une bonne nouvelle pour vous. Disposant moi-même de deux de ces SSD pour mes serveurs de test, j'ai testé l'utilitaire « Samsung SSD 840 EVO Performance Restoration Software » destiné à résoudre les récents problèmes de performance découverts sur ce modèle.

http://www.samsung.com/global/business/semiconductor/minisite/SSD/global/html/support/downloads.html

 

L'utilitaire fonctionne parfaitement sur Windows 2012 R2 en version Core. Je l'ai exécuté sur mes deux serveurs Core sans la moindre difficulté. Il faut cependant noter que le processus nous oblige dans un premier temps à arrêter le serveur pour appliquer la mise à jour. Il faudra donc être près de la machine pour pouvoir la relancer. Après redémarrage, l'utilitaire se relance de lui-même et termine les opérations d'optimisation. Rien à redire, cela fonctionne parfaitement bien et depuis je n'ai pas constaté le moindre problème.

Juste un petit mot pour partager avec vous la joie de m'être vu décerner un nouveau MVP Award dans la spécialité Microsoft Integration.

 

L'information date du 1er octobre, mais ce n'est qu'aujourd'hui que j'ai enfin pris le temps de déposer le dernier disque reçu. Cela commence à avoir de l'allure.

 

Merci à Microsoft pour cette reconnaissance et bravo à tous les nouveaux MVP et à tous les MVP renouvelés ;)

Depuis l'arrivée des rubans dans SharePoint, il m'a de nombreuses fois été remonté des difficultés pour naviguer dans une librairie utilisant des dossiers. Avec le temps, je me suis rendu compte qu'il y avait une commande que les utilisateurs ne trouvaient pas naturellement « Naviguer vers le haut ».

Celle-ci se trouve dans le ruban « Bibliothèque » groupe « Gérer les affichages ». Bien entendu la commande est grisée si l'on ne se trouve pas dans un dossier.

Petite perle constatée lors du déploiement de IIS8, la Technical Preview de Windows Server conserve la compatibilité avec IIS6. Au vu du nombre de produits qui en ont encore besoin aujourd'hui pour la MetaBase, WMI ou les scripts, il n'y a pas de quoi être surpris. La petite bizarrerie vient du fait de garder la console de gestion II6. Pourquoi supporter une console pour un serveur IIS6 (donc 2003R2) qui n'est plus supporté ? Cela sent la feature qui n'a pas encore été revisitée.

Cela devrait en réjouir plus d'un. Mais gardon tout de même à l'esprit qu'il ne s'agit pas là de la version finale du produit, et que tout peut changer d'ici là.

En voulant activer l'interface de gestion de Windows Defender sur un Windows Server Technical Preview, je suis tombé sur une petite perle : un feature nommé « Soft Restart ».

Qui n'a jamais rêvé rebooter un serveur sans avoir à étendre le reboot du bios et de tous ses contrôleurs ?!!!

Si le titre ne vous dit rien ou que l'affirmation vous semble étrange, il y a des chances que le contenu qui suit vous concerne.

De manière générale, pour les services ou un site web on utilise des certificats pour sécuriser des échanges ou authentifier un tiers. À plusieurs reprises déjà, j'ai été confronté à de mauvais usages de certificats, mais très récemment j'ai été confronté à un cas qui dépasse tout. Cela n'est pas la première fois que j'observe cette situation. Je profite donc de cet article pour tenter d'endiguer cette pratique qui compromet la sécurité de vos applications.

  1. L'objectif visé (mais non atteint) consiste à vouloir authentifier les applications autorisées à se connecter à un service. Pour se faire, les applications clientes doivent disposer de certificats signés par une autorité de certificat (CA).
  2. Dans le cas présent, les certificats sont fournis par les administrateurs en charge de l'hébergement des services.
  3. Chaque équipe de développeurs reçoit le certificat public du CA pour le reconnaitre comme une autorité de certificat de confiance + un certificat qui lui est propre.
  4. Les développeurs de l'application cliente 1 doivent utiliser le certificat 1
  5. Les développeurs de l'application cliente 2 doivent utiliser le certificat 2
  6. … etc…

En soi, la chose est classique.

Note : Je ne sais pas pourquoi, cette démarche est confondue avec l'utilisation de certificats d'authentification mutuelle. Pour rappel, dans le cas de certificats d'authentification mutuelle, il faut que chaque partie (client et serveur) fournisse un certificat pour s'identifier. Rien à voir donc avec ce cas. Une présentation propre du sujet peut se trouver ici.

Là où le bât blesse, c'est que les développeurs n'arrivent pas à s'authentifier quand ils utilisent leurs certificats d'applications. Et là on me sort la solution folle qui marche : « utiliser le certificat de l'autorité de certificat »… oui, le certificat public que tout le monde connait et qui sert à dire « en tant que client je fais confiance aux certificats fournis par ce serveur », (oui, le fameux certificat avec CA dans son nom !)…. Mais cela ne choque personne… (hors mis moi...peut être...)

Une erreur de configuration a certainement été opérée sur le serveur.

Les conséquences sont énormes :

  • On ne peut plus interdire une application ou une autre.
  • Il suffit de fournir le certificat du CA pour se connecter.

À partir du moment que quelqu'un connait l'autorité de certificat, il a le droit de se connecter. C'est fou !

Certains défendront la chose en disant « oui, mais il faut déjà connaitre le certificat ». À ceux-ci je répondrai :

  • Imaginer dans le cas d'une autorité de certificat d'entreprise, toutes les machines d'un AD peuvent utiliser le service !
  • Pour faciliter l'administration, le certificat du CA est généralement public et fourni via un site web (que ce soit sous Apache ou IIS)

D'autre diront, « il y a peu de chance que quelqu'un essai d'utiliser ce certificat comme cela ». Pour ceux-ci mes réponses seront basées sur l'expérience.

  • Une chance de contourner la sécurité, c'est une chance de trop.
  • Cela fait déjà 3 fois que je suis confronté à ce cas et qu'aucun développeur n'est choqué par ce qu'il fait en utilisant un certificat CA comme ClientCredential.

Moralité : Attention lors de vos développements, ce qui fonctionne n'est pas forcément bon. Et une information publique comme ce certificat public de CA ne doit surtout pas être utilisée de la sorte. On doit toujours utiliser une information « privée, valide », et donc un certificat non révoqué généré par une autorité de certificat de confiance.

Plus de Messages Page suivante »


Les 10 derniers blogs postés

- Localisation et globalisation ne sont pas des options par Blog de Jérémy Jeanson le 01-17-2015, 11:47

- [Clean Code] les commentaires… par Fathi Bellahcene le 01-10-2015, 17:17

- Mise à jour de Test Professional 2013 par Blog de Jérémy Jeanson le 01-10-2015, 11:32

- [Dynamics CRM] Ajouter un bouton pour déclencher un workflow ou un script (dialogue) par Christine Dubois le 01-09-2015, 14:03

- RDV aux #SharePoint Days 2015 à Casablanca les 28 et 29 janvier ! par Le blog de Patrick [MVP Office 365] le 01-06-2015, 08:41

- TFS Online, vous allez aimer vos projets par Blog de Jérémy Jeanson le 01-03-2015, 11:19

- Bon code 2015 ! par Blog de Jérémy Jeanson le 01-02-2015, 19:01

- [Dynamics CRM] Créer un contact à partir d’une signature email par Christine Dubois le 12-30-2014, 14:37

- SharePoint: Les stratégies de migration - Etape 1 - Préparation par Blog Technique de Romelard Fabrice le 12-24-2014, 16:36

- Faire un workflow personnalisé avec email et colonne de type plusieurs lignes de texte et ajouter des modifications à un texte existant par Le petit blog de Pierre / Pierre's little blog le 12-23-2014, 14:55