Comment améliorer les performances de votre application intranet ASP.NET ?

Avez-vous déjà regardé le nombre de requêtes effectuées par une application web intranet ?J’insiste sur Intranet, parce que je parle des application utilisation l’authentification windows. Généralement, pour  ce type d’applications, on les configure pour rejeter les utilisateurs anonymes. Cependant, cela implique que chaque fichier aura besoin d’une authentification, ce qui totalement faux : les fichiers javascript, css, images, … Tout ces fichiers ne devrait pas nécessiter d’authentification. C’est pourquoi, il faudrait autoriser les utilisateurs anonymes à y accéder.

Pourquoi désactiver l’authentification pour ces fichiers améliorerait les performances ? Tout simplement parce que l’authentification windows fonctionne sur le principe suivant : le navigateur envoie une requête en anonyme, le serveur réponds 401 (non autorisé), alors, et seulement à partir de ce moment, le navigateur envoie une nouvelle requête authentifiée, et vous pouvez maintenant récupérer le fichier. Cela veut dire qu’il y a 2 aller/retour pour récupérer un fichier. Cela fait sens pour les pages, mais pas pour les styles, les scripts ou les images. A mon avis, la “best-practice” serait de mettre les fichiers non sensible dans un dossier. Typiquement, le but serait d’utiliser la fonctionnalité de thèmes (même si vous n’avez qu’un seul thème).

Maintenant, nous arrivons à la partie pratique.

Pour chaque dossier contenant uniquement des données non sensible, vous devriez ajouter un fichier web.config contenant les lignes suivantes :

<?xml version="1.0"?> 
<configuration> 
    <system.web> 
      <authorization> 
        <allow users="?"/> 
      </authorization> 
    </system.web> 
</configuration>

C’est mieux maintenant, mais ce n’est pas suffisant. En effet, il y a aussi les resources script qui sont chargées par le ScriptManager. Puisqu’on ne peux pas rediriger simplement le chemin vers ScriptResource.axd et WebResource.axd, il faut appliquer les changement directement dans le web.config racine de l’application en ajoutant les lignes suivantes dans l’élément configuration racine :

<location path="WebResource.axd">
    <system.web>
        <authorization>
            <allow users="?" />
        </authorization>
    </system.web>
</location>

<location path="ScriptResource.axd">
    <system.web>
        <authorization>
            <allow users="?" />
        </authorization>
    </system.web>
</location>

J’espère que vous avez apprécié l’astuce. A bientôt

Comment faire un proxy HTTP

Comme vous l’avez vu, j’ai récemment mis à jour mon projet codeplex zeroconf. Ce projet ne contient pas seulement l’implémentation du protocol DNS et du protocol Bonjour. Il contient aussi l’implémentation du protocol HTTP qui me permet d’envoyer des requêtes HTTP en UDP, chose qui n’est pas faisable avec l’implémentation du framework .NET. Au boulot, j’ai besoin de vérifier qu’une application que j’ai développé fonctionne correctement avec IE6( oui, ca existe encore… malheureusement). Puisque je suis sur Windows 7, je me suis dit que ca pourrait être super d’utiliser IE6 en application virtuelle. Je pense que vous voyer où je veux en venir. Sur une machine virtuel, on n’a pas accès au serveur de développement web démarré par visual studio. Ce que j’aurais pu faire, c’est déployer sur la machine virtuelle, ce qui veut dire, installer IIS, le configurer, passer du temps à vérifier le fichier web.config… Bref, pas une solution des plus simple à mettre en place. Alors, je me suis dit : Ce qu’il me faut, c’est un proxy, et j’ai déjà l’implémentation du protocole HTTP !

Voici le code du fameux proxy :

public class Proxy
    {
        RestServer proxy;
        string hostToRedirectTo;

        static void Main(string[] args)
        {
            Proxy p = new Proxy(ushort.Parse(args[0]), args[1]);
            p.Start();
            Console.ReadLine();
            p.Stop();
        }

        private void Stop()
        {
            proxy.Stop();
        }

        private void Start()
        {
            proxy.StartTcp();
        }

        public Proxy(ushort portToListenOn, string hostToRedirectTo)
        {
            proxy = new RestServer(portToListenOn);
            this.hostToRedirectTo = hostToRedirectTo;
            proxy.HttpRequestReceived += proxy_HttpRequestReceived;
        }

        void proxy_HttpRequestReceived(object sender, HttpRequestEventArgs e)
        {
            e.Request.Host = this.hostToRedirectTo;
            e.Response = e.Request.GetResponse(true);
            e.Response.Body.Position = 0;
        }
    }

Comme vous pouvez le voir, la solution est très simple, et ne nécessite qu’une dizaine de lignes de code !!!

Bonjour mis à jour

Bonjour à tous,

J’ai mis à jour mon projet codeplex zeroconf. Le principal but de cette release est du refactoring. Ce project n’est pas seulement une implémentation de bonjour, mais contient aussi une implémentation de serveur. Avec cette implémentation de serveur, vous pouvez faire presque tout ce que vous voulez. Le seul désavantage, c’est que je ne gère pas les sessions. Pour comprendre de quoi je parle, je vous conseille de télécharger la dernière release de bonjour et de jeter un oeil à l’assembly Network.dll. Je vous promets que je fournirai un peu plus de documentation à ce sujet.

Vous pouvez déjà regarder la documentation sur le site du projet.

Amusez-vous bien !

Singleton réutilisable dépendant d'un context Http

Salut à tous,

Après avoir lu le post d'Ayende Rahien, je me suis dit qu'il fallait que je partage l'implémentation de mon module de singleton http que j'utilise depuis un certain temps maintenant. Ce module me permet avec très peu de lignes de codd d'avoir une seule instance de ce que je veux. Si comme Ayende, vous utilisez NHibernate, vous avez seulement d'hériter du code que je vais vous donner pour faire votre propre HttpSessionModule, et ainsi avoir une session créée HttpContext. Je l'utilise pour avoir non pas un ObjectContext (j'utilise euss), mais un service qui cache cette couche de persistence.

Voici l'implémentation abstraite de mon module de singleton Http :

    public abstract class HttpSingletonModule<T> : IHttpModule
    {
        #region IHttpModule Members

        public void Dispose()
        {
        }

        public void Init(HttpApplication application)
        {
            application.PostAuthorizeRequest += new EventHandler(application_AuthorizeRequest);
            application.EndRequest += new EventHandler(application_EndRequest);
        }

        void application_EndRequest(object sender, EventArgs e)
        {
            HttpApplication application = sender as HttpApplication;
            HttpContext context = application.Context;
            if (context != null)
            {
                T instance = (T)context.Items[typeof(T).AssemblyQualifiedName];
                if (instance is IDisposable)
                    ((IDisposable)instance).Dispose();
            }
        }

        public static T Instance
        {
            get { return (T)HttpContext.Current.Items[typeof(T).AssemblyQualifiedName]; }
            set { HttpContext.Current.Items[typeof(T).AssemblyQualifiedName] = value; }
        }

        void application_AuthorizeRequest(object sender, EventArgs e)
        {
            HttpApplication application = sender as HttpApplication;
            HttpContext context = application.Context;
            if (context != null)
                context.Items.Add(typeof(T).AssemblyQualifiedName, CreateInstance(context));
        }

        protected abstract T CreateInstance(HttpContext context);

        #endregion
    }

Comme vous devez l'avoir compris maintenant, pour implémenter un module, c'est assez simple. Voici l'implémentation que j'utilise dans un projet :

    public class PortalServiceModule : HttpSingletonModule<PortalService>
    {
        protected override PortalService CreateInstance(HttpContext context)
        {
            if (context.User.Identity.IsAuthenticated)
                return new PortalService(context.User.Identity.Name);
            return new PortalService();
        }
    }

Vous voyez ? Si peu de lignes de code pour une telle simplicité d'utilisation : pour récupérer l'instance de mon PortalService, j'ai juste à appeler la propriété static Instance de mon PortalServiceModule. Comment pourrait-on faire plus simple ?

ModalPopup paramétrée

Bonjour à tous,

Certains d'entres vous ont peut-être déjà eu le problème : ouvrir une fenêtre modale (en l'occurence avec AjaxControlToolkit), et pouvoir lui passer un paramètre, l'id du contrôle ayant ouvert la popup par exemple. Sachez que c'est entièrement possible, cela nécessite juste un peu de code. La première chose à savoir c'est qu'avec le framework AjaxControlToolkit, il existe une propriété BehaviorID sur tous les extenders. Cette propriété vous permet ensuite de manipuler cet extender côté client (en javascript, donc). Je vous propose de jeter un coup d'oeil sur le code avant les explications.

<asp:ModalPopupExtender runat="server" BehaviorID="myPopupBehavior"
PopupControlId="myPopup" TargetControlId="dummyLB" />
<asp:Panel ID="myPopup" runat="server">
<asp:HiddenField runat="server" ID="myParameter" />
</asp:Panel>
<asp:LinkButton ID="dummyLB" runat="server" style="display:none" />

<style type="text/javascript">
function openPopup(parameter)
{
   $find("myPopupBehavior").show();
   $get("<%= myParameter.ClientID %>").value=parameter;
}
</style>

Après avoir vu le code, je pense que vous avez besoin d'explications, et c'est tout à fait normal. Tout d'abord, la première chose à savoir, c'est qu'un extender AjaxControlToolkit a toujours besoin d'un TargetControlID. J'ai donc fait un LinkButton invisible pour l'utilisateur, mais qui est bien là pour ne pas faire planter l'application. La seconde chose à remarquer, c'est que dans le panel qui sera affiché, j'ai un champ caché (Hidden field). C'est ce dernier qui contiendra la valeur de mon paramètre. Pour affecter mon paramètre, j'ai donc fait une fonction javascript qui encapsule ce fonctionnement d'affectation de la valeur du champ caché. Ainsi, j'ai donc une fonction réutilisable à tout moment. Voici un exemple d'utilisation :

<a onclick="openPopup('http://www.google.fr')>lien vers google</a>

L'avantage de ce code est donc de pouvoir récupérer la valeur de votre paramètre côté serveur, puisque le champ caché est un contrôle serveur !

Voilà, j'espère que cet article vous aura plut.

jQuery Control Toolkit

Bonjour à tous,

Cela fait longtemps que je n'avais pas posté quelque chose sur mon blog, J'ai été légèrement occupé par mon travail. Mais ce travail me permet aujourd'hui de vous présenter un nouveau projet codeplex : jQuery Control Toolkit. Le but de ce projet est de permettre d'utiliser jQuery au travers d'extenders en ASP.NET, mais plus généralement de fournir des nouvelles fonctionnalités en tant que plugins jQuery. Ce projet n'est pas encore beaucoup détaillé, mais si vous ne pouvez pas attendre la description de chaque fonctionnalité, vous pouvez jetter un oeil dans le code source, il y a une application web qui utilise chaque fonctionnalité (principale). Il y a aussi plus de fonctionnalités dans le fichier source javascript jQuery.ACT.js, mais il n'est pas (encore) documenté.

Amusez-vous bien.

Powershell pour Visual Studio

Bonjour,

Voilà mon nouveau projet : Powershell for Visual Studio. Vous pourrez déjà y trouver la coloration syntaxique, ainsi qu'un intellisense basique (cmdlets disponibles, avec leur aide). Actuellement, il semble que le SDK VS2008 soit requis pour le faire marcher. Ce sera résolu dans la prochaine version...

Amusez-vous !
Powershell for Visual Studio