Экспресс-сессии путаются для некоторых пользователей с Passport.js

Я запускаю приложение Express node.js, которое позволяет пользователям входить в систему с помощью локальных стратегий PassportJS или стратегий LinkedIn, и для большинства пользователей это работает нормально — они входят в систему и видят свои профили.

Для небольшой группы пользователей (возможно, 5%), когда они впервые нажимают «зарегистрироваться», их браузер, кажется, считывает аутентифицированный файл cookie сеанса другого пользователя, поэтому они сразу же переходят в профиль другого пользователя. Все эти пользователи работают на одного и того же работодателя, но разбросаны по разным географическим точкам (не на одном компьютере, как я изначально надеялся).

Их ИТ-услуги не очень полезны, поэтому я был бы признателен, если бы у кого-нибудь был опыт работы с подобным сценарием, когда сеансы, кажется, совместно используются, когда они не должны быть? Может ли это быть проблемой с моей стороны или с их ИТ-инфраструктурой?

И я попробовал ответить на похожий вопрос, добавив app.disable('view cache'); в мой app.js, а радости нет.

Мои сеансы настроены с помощью Redis, поэтому мой app.js выглядит так:

var express = require('express');
var app = express();
var path = require('path');
var port = process.env.PORT || 3000;
var favicon = require('serve-favicon');
var logger = require('morgan');
var cookieParser = require('cookie-parser');
var bodyParser = require('body-parser');
var passport = require('passport');
var LinkedInStrategy = require('passport-linkedin').Strategy;
var LocalStrategy = require('passport-local').Strategy;
var config = require('./config').config();
var bcrypt = require('bcrypt-nodejs');
var helmet = require('helmet')
var Model = require('./data/models/model');

app.disable('view cache');

app.use(session({ 
  store: new RedisStore({
  host: '127.0.0.1',
  port: 6379
}), secret: 'mysecretkey' }));

app.use(passport.initialize());
app.use(passport.session());

// view engine and routes here

passport.serializeUser(function(user, done) {
  done(null, user);
});

passport.deserializeUser(function(obj, done) {
  if (obj.provider != 'linkedin'){
    new Model.User({id: obj.id}).fetch().then(function(user) {
      done(null, user.attributes);
    })
  }
  else {
    new Model.User({email: obj.emails[0].value}).fetch().then(function(data) {
      if(data != null){
        return done(null, data.attributes);
      }
      else{
        return done(null, obj);
      }
    })
  }  
});

app.listen(port);

#update2

Моя конфигурация nginx:

  location / {
    proxy_pass http://1.2.3.4:3000;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection 'upgrade';
    proxy_set_header Host $host;
    proxy_cache_bypass $http_upgrade;
  }

person Wikooo    schedule 13.06.2016    source источник
comment
У вас есть обратный прокси, такой как nginx или Apache впереди? Похоже, вам нужно изменить файл cookie (или просто не кэшировать).   -  person MrWillihog    schedule 13.06.2016
comment
Да, у меня есть nginx перед моим приложением. Я изо всех сил пытаюсь понять, как работает переменная в строке cookie и где ее следует добавить — нужно ли ее добавлять в конфигурацию nginx в #update2?   -  person Wikooo    schedule 13.06.2016
comment
Кэширование работает следующим образом: для заданного URL-адреса и набора заголовков сервер будет хранить кешированную версию. Для этого примера давайте представим, что мы различаемся только по URL. Пользователь А приходит и нажимает /myaccount. Сервер кеширует это. Пользователь B приходит и нажимает /myaccount. Сервер видит, что он находится в кеше, и возвращает кешированную версию (учетная запись пользователя А!!). Если мы добавим Vary Cookie, будут совпадать только уникальные комбинации URL-адреса и файла cookie (где хранится аутентификация пользователя). То есть /myaccount пользователя А отличается от /myaccount пользователя Б.   -  person MrWillihog    schedule 13.06.2016
comment
Чтобы установить, так ли это, вы можете посмотреть на отправляемые заголовки — откройте Chrome Inspector и посмотрите на вкладку сети — в ответе вы должны увидеть заголовок Cache-Control. Если это проблема кэширования, может быть лучше просто указать nocache для конфиденциальных страниц.   -  person MrWillihog    schedule 13.06.2016
comment
@mrwillihog Похоже, что это именно то, что происходит с некоторыми пользователями - возможно, с общим IP-адресом или в старой корпоративной сети. В Chrome после входа в систему я вижу Cache-Control:max-age=0. Я думал, что добавление res.header("Cache-Control", "no-cache, no-store"); к моему маршруту должно решить проблему, но я все равно получаю «max-age=0».   -  person Wikooo    schedule 13.06.2016
comment
Вы смотрите на заголовки запросов, а не на раздел заголовков ответов?   -  person MrWillihog    schedule 13.06.2016
comment
@mrwillihog ах, да, это то, на что я смотрел - извиняюсь. Когда я попытался установить res.header..., в заголовках ответов ничего не появилось. Не могли бы вы также указать, где мне нужно добавить nocache для конфиденциальных страниц? В заголовках установлены маршруты этих страниц?   -  person Wikooo    schedule 13.06.2016