[RUBY] Évitez le problème que la session ne peut pas être obtenue lorsque Canary est libéré lors de la mise à niveau de Rails 4.2.x vers 5.0.x

introduction

• La version Canary est une méthode de déploiement qui libère une nouvelle version d'une application sur une partie seulement de plusieurs serveurs.
• Lors de la mise à niveau de Rails 4.2.x vers 5.0.x, version canary, c'est-à-dire que si vous créez un environnement où les applications Rails 4.2.x et 5.0.x sont mélangées, vous ne pourrez pas obtenir de sessions, évitez donc cela. Vouloir

On ne sait pas si quelqu'un passera à Rails 5.0.x (et avec une version Canary) pour le moment, mais j'espère que cela aidera quelqu'un: priez:

Puisque le contenu est destiné à ceux qui connaissent dans une certaine mesure Ruby et Rails, les explications de base telles que la session et le rack dans Rails sont omises.

Solution

--Fixer la version du rack gem à 2.0.7

En un mot la cause

Causé par la mise à niveau de Rails 4.2.x-> 5.0.x faisant glisser le gem de rack pour mettre à jour vers 2.0.8 ou supérieur. (Il y a un changement destructeur dans la logique de génération de session_id dans le rack 2.0.7-> 2.0.8)

See. https://github.com/rack/rack/blob/master/CHANGELOG.md#208---2019-12-08

La description

Lib / rack / session / abstract / in [différence rack 2.0.7 ... 2.0.8](https://github.com/rack/rack/compare/2.0.7 ... 2.0.8) C'est très facile à comprendre si vous regardez autour de id.rb, lib / rack / session / memcache.rb.

• Jusqu'au rack 2.0.7, il est stocké dans le cookie du navigateur _session_id ([nommé par Rails](https://github.com/rails/rails/blob/v5.0.7.2/actionpack/lib/action_dispatch] /middleware/session/abstract_store.rb#L31)) a été utilisé comme clé pour le magasin de session (Redis, Memcached, etc.) --Depuis le rack 2.0.8, la valeur de _session_id as Digest :: SHA256.hexdigest est utilisée comme clé (Code is around here. /2.0.8/lib/rack/session/abstract/id.rb#L15-L39), public_id est égal à _session_id)
• La gemme de chaque magasin de session a une méthode de secours appelée # get_session_with_fallback ([for redis-rack](https://github.com/redis-store/redis-rack/blob/v2. 1.3 / lib / rack / session / redis.rb # L87-L89), Pour Memcache # L94-L96)) Vous pouvez donc récupérer les données de session générées par l'ancienne version du rack à partir de la nouvelle version du rack, mais pas l'inverse.

De ce qui précède, il n'y a aucun problème si vous déployez une nouvelle version de rack gem sur tous les serveurs à la fois, mais dans un environnement où les gemmes de rack de 2.0.7 ou moins et 2.0.8 ou plus sont mélangées sur chaque serveur (environnement de version Canary), session Ne peut plus être obtenu.