Accueil > .Net, Développement > Partage de sessions : Focus, SQL Server

Partage de sessions : Focus, SQL Server

Ce billet fait partie de la série « Partage de sessions » :

  1. Présentation
  2. Gestion native des sessions en .Net
  3. Focus, State Server
  4. Focus, SQL Server (ce billet)
  5. Focus, Couchbase
  6. Autres possibilités
  7. Conclusion
  8. Annexes

Dans ce billet, nous allons voir ce qu’est la gestion de session via SQL Server, ses avantages et inconvénients et comment le mettre en place.

 

Généralités

 

ASP.Net - Sql Server

Dans le cas d’une session sous SQL Server, il faut bien évidemment avoir une base de données SQL Server à disposition.
Il y a alors deux possibilités :

  • Utiliser le tempdb
  • Utiliser de la persistance

Dans le premier cas, dès que SQL Server va redémarrer, tout le tempdb va être vidé et toutes les sessions seront perdues. Il faudra alors rejouer le script de créations des éléments.

Pour la solution tempdb, deux scripts sont utilisés :

  • InstallSqlState.sql
  • UninstallSqlState.sql

Les scripts sont présents dans le Framework .Net (ex : C:\Windows\Microsoft.NET\Framework64\v4.0.30319).

Cette gestion s’appuie sur une nouvelle base de données « ASPState » qui va contenir tous les éléments qui lui sont utiles. Sont présents des tables, procédures, mais aussi jobs (pour purger les sessions expirées).

Pour la persistance, deux autres scripts sont utilisés :

  • InstallPersistSqlState.sql
  • UninstallPersistSqlState.sql

Il est cependant fortement encouragé d’utiliser la commande Aspnet_regsql.exe pour jouer le script (déjà parce que c’est plus simple), plutôt que les scripts.
En effet, les scripts sont surtout présents pour être adapté ou pour retrocompatibilité.
Voir ASP.NET SQL Server Registration Tool (Aspnet_regsql.exe) pour plus d’informations.

Dans les deux cas, le cookie de session de base du Framework seront utilisé (ASP.NET_SessionId), côté utilisateur pour qu’il conserver l’identifiant de session. Il aura pour seul contenu une chaîne de 36 caractères. Les 24 premiers représentent l’identifiant de session et les 8 derniers le code de l’application.

Exemple :

SessionId SQL Server = lehxv4so4ioi2gqqaxtjzhyo84497b6f
SessionId .Net = lehxv4so4ioi2gqqaxtjzhyo

 

Avantages et inconvénients

 

Il y a plusieurs avantages à cette approche. Le premier est de sécuriser (au sens utilisateur, et non sécurité applicative) les sessions et de pouvoir les garder dans un endroit centralisé. Ainsi, les sessions étant persistées en base de données, un redémarrage du serveur Web (ou dans une moindre mesure de IIS ou du pool d’application) n’aura aucun effet sur les sessions utilisateurs.

Dans un scénario de Load Balancing, par exemple, cette approche est idéale puisque tous les applicatifs pourront aller chercher les sessions en base de données sans aucune difficulté.

Dans une optique de surveillance et traçabilité, cette solution est également intéressante car elle permet de garder trace de la session (en modification la procédure DeleteExpiredSessions et/ou le job de purge, par exemple).

Côté inconvénients, comme pour le State Server, il faut que tous les objets soient sérialisables.
De plus, c’est, des trois solutions (InProc, State Server, SQL Server), la solution la plus lente du fait de la persistance sur disque (et des I/O liés).

 

Configuration

 

<?xml version="1.0" encoding="utf-8"?>

<configuration>
  <appSettings>
    <add key="ApplicationName" value="ApplicationName"/>
  </appSettings>
  <system.web>
    <sessionState
        mode="SQLServer"
        sqlConnectionString="Integrated Security=SSPI;data source=.\SQLEXPRESS;" />

    <machineKey validationKey="EB9231989609C0587218913BD4A9CF56A51977A8DCAA04D224AB86581173BDB6A636FFCFC234669049C531EF9C4123883EE9DC509C3E8AE650166476D7FC1AE4"
      decryptionKey="41A0588A0553E66942683538425AF806BA1B89DA6AB70699"
      validation="SHA1"
    />
  </system.web>
  
</configuration>

 

Mise en place

 

Pour configurer SQL Server pour qu’il accueille un gestionnaire de session, il est conseillé par Microsoft de passer par l’utilitaire Aspnet_regsql.exe. C’est donc dans cette situation que nous allons nous positionner, avec la ligne de commande suivante :

ASPNET_REGSQL.exe
          -ssadd
          -sstype p
          -E
          -S ".\SQLEXPRESS"
Option Signification
-ssadd Ajoute le mode Session State pour SQL Server.
-sstype T : temporaire : ajoute les éléments dans le tempdb.
P : persistance, créé une base de données « ASPState ».
C : custom, permet de positionner les éléments dans une autre base de données, dont le nom doit être spécifié après l’option « -d »
-E Utilise l’utilisateur courant pour s’authentifier dans SQL Server.
-S Indique le nom du server.

Une nouvelle base va donc être créée, avec pas mal d’éléments :
ASP.Net - Sql Server - Eléments créés

Un job est également créé pour purger les données à intervalles réguliers.

Note : comme pour le State Server, la méthode Init doit être surchargée dans le Global.asax. Voir State Server, partie « Mise en place ».

 

Proof of Concept

 

L’application d’exemple est disponible.

Catégories :.Net, Développement

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :