vendredi 21 novembre 2008

[Sharepoint] Refaire le contrôle utilisateur Welcome.ascx

Dernièrement, j’ai eu besoin de faire un userControl du style de Welcome.ascx mais personnalisé.

Un de mes besoins était d’afficher le nom prénom de la personne connectée et pas le “Bienvenue”. Or, en authentification Forms, je ne voyais que le “Bienvenue login”.

Un petit coup de Refelctor sur la dll Sharepoint m’a permis de voir qu’il y avait plusieurs options (PostCacheSubstitutionTextType) pour cette affichage.

image

Par défaut, l’option utilisée est “WelcomeUser”, voici les autres options :

  • Invalid

  • UserEmail

  • UserId

  • UserLoginName

  • UserName

  • WebTitle

  • WelcomeUser


Le développement

Pour faire simple, je suis repartie du code de Welcome.ascx, et ai créé Welcome2.ascx.

Au chargement du contrôle j’ai rajouté ces quelques lignes qui me permettent de modifier le type de l’affichage.

[sourcecode language='c-sharp']
PostCacheSubstitutionText child = this.ExplicitLogout.MenuControl.Controls[0] as PostCacheSubstitutionText;
           if (child.TextType == PostCacheSubstitutionTextType.WelcomeUser)
           {
               this.ExplicitLogout.MenuControl.Controls.Remove(child);
               child.TextType = PostCacheSubstitutionTextType.UserName;
               this.ExplicitLogout.MenuControl.UseShortId = true;
               this.ExplicitLogout.MenuControl.Controls.Add(child);

           }
[/sourcecode]

A partir de la, rien ne m’empêcher de créer mon propre userControl :

image

Il ne suffit plus que de créer une feature/solution pour le déploiement de ce contrôle et de l’intégrer dans notre masterpage personnalisée.

 

Ce n’est certainement pas la solution la plus propre, mais la plus simple dans mon cas car elle ne m’implique que très peu de développement.

[Article] Pratiques fondamentales pour un développement logiciel sûr

L’article sur les pratiques de sécurité dans le développement de M. Howard a été traduit en français par K. Yildirim.

C’est un article de 20 pages vraiment très intéressant, voici le lien MSDN pour le téléchargement de l’article :

http://msdn.microsoft.com/fr-fr/security/msdn.securite.pratiques.fondamentales.aspx

Et une copie de la synthèse :

Synthèse

La fiabilité logicielle comprend le développement et l’implémentation de méthodes et de processus pour garantir que le logiciel fonctionne comme prévu tout en minimisant les risques de failles et de codes malveillants qui peuvent faire du tort à l’utilisateur final. Reconnaissant que la fiabilité logicielle est une ligne de défense essentielle dans le contexte actuel des menaces, de plus en plus dynamique et complexe, les principaux éditeurs ont entrepris des efforts considérables pour réduire les failles, améliorer la résistance aux attaques et protéger l’intégrité des produits qu’ils vendent. Ces efforts ont conduit à d’importantes améliorations dans la sécurité logicielle et donnent ainsi un très bon aperçu sur la manière d’améliorer l’état actuel de la sécurité logicielle.

A travers l’analyse des efforts de fiabilisation logicielle de chacun de ses membres, SAFECode a identifié un ensemble de pratiques de développement sûr qui peuvent s’appliquer dans divers environnements de développement pour améliorer la sécurité logicielle. Il est important de noter que ce sont des “pratiques terrain” utilisées par les membres de SAFECode. En rassemblant ces méthodes et en les partageant avec une plus large communauté, SAFECode espère faire bouger l’industrie de la définition de bonnes pratiques souvent citées, mais rarement mises en œuvre, à la qualification d’un ensemble de disciplines logicielles qui ont démontrées leur efficacité à améliorer la sécurité des applications et qui sont actuellement en place chez les principaux éditeurs. Avec cette approche SAFECode encourage l’adoption de bonnes pratiques qui ont prouvé leur efficacité et capacité de mise en œuvre même avec des besoins produits et des méthodologies de développement très différents.

Un des principaux objectifs de ce document est de rester concis, pragmatique et très pratique. Il préconise des pratiques de sécurité spécifiques à chaque phase du processus de développement—Définition des besoins, Conception, Développement, Test, Codage et Documentation— qui peuvent être implémentées dans divers environnement de développement.

Les éditeurs logiciels ont à la fois une responsabilité et un avantage business à assurer la fiabilité et la sûreté des produits. SAFECode a collecté, analysé et livré ces bonnes pratiques de sécurité dans l’objectif d’aider les autres acteurs du secteur à initier ou améliorer leur propre programme de fiabilisation logicielle et encourage l’adoption par l’ensemble de l’industrie des méthodes de développement sûres décrites dans ce document.

Table des matières

  • Aperçu
  • Définition des besoins
  • Conception
  • Programmation
  • Test
  • Intégrité et gestion du code
  • Documentation
  • Conclusion
  • A propos de SAFECode

A propos de SAFECode

Le “Software Assurance Forum for Excellence in Code” (SAFECode) est une organisation à but non lucratif exclusivement dédiée à accroitre la confiance envers les produis et les services de technologies de l’information et des communications à travers la promotion de méthodes efficaces de fiabilisation des logiciels. SAFECode est une initiative tirée par l’industrie, pour identifier et promouvoir les bonnes pratiques pour développer et livrer des logiciels, du matériel et des services plus sûrs et fiables. On compte parmi ses membres EMC Corporation, Juniper Networks, Inc., Microsoft Corp., Nokia, SAP AG and Symantec Corp. Pour plus d’information, vous pouvez visiter www.safecode.org.

Téléchargez le document complet au format PDF (20 pages)

lundi 3 novembre 2008

[Sharepoint] Les types de contenu et leurs IDs

Voici un bref récapitulatif de ce que l’on peut trouver sur MSDN concernant les types de contenu. En effet, quelle douleur de créer un type de contenu qui hérite d’autres types de contenu.

Les types de contenu de Sharepoint sont gérés par des IDs unique pour une même collection de site.

SharePoint utilise cette information pour déterminer la relation entre le type de contenu et l'élément qui l'utilise (liste, modèle de page, document,...).

Il est donc possible de construire un type de contenu valide via l'une des 2 conventions suivantes :

  • ID du type de contenu parent + 2 valeurs héxadécimales (ces 2 valeurs ne peuvent être "00")

  • ID du type de contenu parent + "00" + GUID héxadécimal


Un cas spécial, le type de contenu "System", il est défini par "0x". Il est celui dont tous les types de contenu héritent.

Voici la liste des types de contenu de base dans Sharepoint :

Base content type hierarchy structure

ID du type de contenu parent + 2 valeurs héxadécimale


Voila par défaut la construction d'un ID avec cette convention

Document content type ID

Example of default content type ID hierarchy

ID du type de contenu parent + "00" + GUID héxadécimal


Sharepoint utilise cette méthode dans les cas suivants :

  • Type de contenu de Site basé sur d'autres types de contenu

  • Type de contenu de List, dans ce cas, le type de contenu est copié dans la liste quand on ajoute un type de contenu de site à cette liste.


Taille des IDs des types de contenu


La taille maximum d'un ID de type de contenu est de 512 octets.

Exemple (le niveau concerné est en bleu) :

Example of content type ID hierarchy

Lien msdn pour plus d'informations sur cette patie