Go to Hackademy website

Le mécanisme de session en rails

Martin Catty

Posté par Martin Catty dans les catégories back

Cet article est publié sous licence CC BY-NC-SA

Le fonctionnement d’HTTP

HTTP est un protocole sans état. Il n’inclue pas de notion d’identité de base et chaque requête est donc indépendante.

Cela signifie que le serveur ne me reconnait pas entre chaque requête.

C’est la base du fonctionnement du web, et l’opposé d’une connexion client - serveur tel que FTP.

L’avantage est que le serveur n’a pas à gérer ses clients, tout le monde est logé à la même enseigne. L’inconvénient est que l’ajout d’un mécanisme d’identification va ajouter un surplus d’information à chaque requête.

Les sessions, ou comment transformer HTTP en protocole à état

Le mécanisme de session prend place à la fois côté client et serveur. Il est activé de base sur une application Rails par le biais d’un middleware (ActionDispatch::Session::CookieStore) qui peut être désactivé au besoin.

Lorsqu’un nouvel utilisateur arrive sur l’application, si le serveur ne reçoit pas d’identifiant de session il va en créer un qu’il va transmettre dans sa réponse.

Côté client cet identifiant va être stocké dans un cookie. Les cookies ne sont pas forcément des fichiers plats. Sous chrome les cookies sont stockés dans une base SQLite et sont limités à 4ko en contenu.

Il est fortement déconseillé de placer des objets en session car cela pourrait poser des soucis d’encodage / décodage.

Par exemple on mettra un id utilisateur plutôt que l’objet utilisateur. Qui plus est, cela permet de limiter l’espace occupé par le cookie.

Les sessions avec Ruby on Rails

Ruby on rails possède plusieurs mécanismes de stockage de session. Par défaut il utilise le cookie store qui stocke tout sur le client et ne nécessite aucune configuration.

Dans ce cas l’id session n’a pas d’intérêt pour la partie serveur.

Ce paramètre peut être modifié dans config/initializers/session_store.rb

App::Application.config.session_store :cookie_store, :key => '_app_application_session'

Les autres mécanismes de stockage sont la base de données et le cache. Dans ces cas l’id session va permettre au serveur de retrouver les données associées en base ou en cache.

L’avantage de ces mécanismes est de pouvoir stocker plus de données voir d’améliorer les performances dans le cas du cache.

Attention toutefois, si votre serveur de cache vient à tomber vous n’avez plus d’utilisateur connectés. D’autre part ces mécanismes impliquent une purge côté applicatif si vous ne voulez pas stocker des miliers de sessions fantômes.

Dernier point, vous aurez besoin de partager ces sessions entre serveurs si vous mettez en place du load balancing sur votre application.

Le contenu des cookies

Le contenu des cookies est encodé avec le secret de l’application rails, qui peut être surchargé dans votre initializer avec l’option secret_token.

Voici un exemple de contenu de cookie:

BAh7CEkiD3Nlc3Npb25faWQGOgZFRkkiJWNhZTFlMjY0YWRlZTc2NjNhZDc4YzY4YzkwMzk3NWVlBjsAVEkiEF9jc3JmX3Rva2VuBjsARkkiMXBEZlQrdkVXZndjdGpQd1JSNTRQUjhYWlp6WHFldUlZYURZZklkYmh4UVE9BjsARkkiGXdhcmRlbi51c2VyLnVzZXIua2V5BjsAVFsISSIJVXNlcgY7AEZbBmkE8NcBLUkiIiQyYSQxMCRMUXNTdU9rbk4wSVIySUZORHFESVcuBjsAVA==--f58cf55b4d11b47c398103643b0ffe7ffdbff309

Le cookie présente 2 parties, séparées par –, d’un côté le contenu et de l’autre côté la signature. Séparons les:

  content = "BAh7CEkiD3Nlc3Npb25faWQGOgZFRkkiJWNhZTFlMjY0YWRlZTc2NjNhZDc4YzY4YzkwMzk3NWVlBjsAVEkiEF9jc3JmX3Rva2VuBjsARkkiMXBEZlQrdkVXZndjdGpQd1JSNTRQUjhYWlp6WHFldUlZYURZZklkYmh4UVE9BjsARkkiGXdhcmRlbi51c2VyLnVzZXIua2V5BjsAVFsISSIJVXNlcgY7AEZbBmkE8NcBLUkiIiQyYSQxMCRMUXNTdU9rbk4wSVIySUZORHFESVcuBjsAVA=="
  signature = "f58cf55b4d11b47c398103643b0ffe7ffdbff309"

À la réception du cookie, rails va vérifier que le contenu et la signature correspondent. Pour cela il va utiliser son secret token. Note: vous ne devez jamais divulguer ce token où vos sessions seront usurpables.

Voyons quel est le secret de notre app de démo:

secret = Rails.application.config.secret_token
"0b22c3a50d0ba81e396b880268d8d13c5980896a3761a24bc87e704f3589f9d0ef2528ef7480101e0edeccc5320f6310d54fd06ad7df574ee6e8e349ba01ace2"

Voilà ce que fait rails pour générer la signature:

OpenSSL::HMAC.hexdigest(OpenSSL::Digest::SHA1.new, secret, str)
"f58cf55b4d11b47c398103643b0ffe7ffdbff309"

Effectivement, on retombe bien sur notre signature.

Par le biais de ce mécanisme, modifier le contenu du cookie ne permet pas d’usurper une session car la signature ne sera plus valable et notre framework s’en rendra compte.

Attention, si les cookies sont signés leur contenu n’est toutefois pas encrypté.

Il est tout à fait possible d’extraire le contenu d’un cookie.

session = Marshal.load(Base64.decode64(CGI.unescape(content)))
{
              "session_id" => "cae1e264adee7663ad78c68c903975ee",
             "_csrf_token" => "pDfT+vEWfwctjPwRR54PR8XZZzXqeuIYaDYfIdbhxQQ=",
    "warden.user.user.key" => [
        [0] "User",
        [1] [
            [0] 755095536
        ],
        [2] "$2a$10$LQsSuOknN0IR2IFNDqDIW."
    ]
}

J’espère que cet article vous aura permi de mieux appréhender le fonctionnement des sessions, notamment dans Ruby on Rails.

L’équipe Synbioz.

Libres d’être ensemble.

Articles connexes

WebRTC Partie 1 : Signalement par pigeon voyageur

09/07/2020

Alors qu’on parle de connexion pair à pair, si l’on regarde les cas d’usage de WebRTC en ligne, on pourra être surpris de constater que des serveurs centraux sont quasiment toujours requis...

Pilotez vos tests Elixir avec des scénarios

11/06/2020

Photo par Avel Chuklanov depuis Unsplash

Regex : attrapez-les tous !

09/04/2020

Encore un article sur les regex me direz-vous !? Effectivement, après avoir traité des quantificateurs, des propriétés Unicode, et même des emojis, que pourrais-je encore raconter que vous ne sachiez...

Ruby, Sidekiq et Crystal

25/07/2019

Dans le cadre d’une application web il nous est tous déjà arrivé de devoir effectuer une tâche assez longue en asynchrone pour ne pas gêner le flux de notre application. En Ruby la solution la plus...