Кажется, что пользователи вошли в систему как другой пользователь

Я использую Flask-Security для управления пользователями, и я получаю отчеты о том, что пользователи успешно вошли в систему как они сами, но случайным образом, когда они загружают страницу, он показывает, что они вошли как кто-то совершенно другой. Я не уверен, что ошибаюсь. Как это могло произойти?

Я использую UserService для простого управления пользователями. Я создаю пользовательский сервис перед каждым запросом и передаю current_user.


@app.before_request
def load_request_services():
    g.user_service = UserService(user_datastore, application_service, email_service, ORGS, current_user)

Затем я получаю текущего пользователя в UserService с помощью этого метода:


def current_user_get_info(self):
    return {
        'user': self.current_user.email,
        'first_name': self.current_user.first_name,
        'last_name': self.current_user.last_name,
        'phone_number': self.current_user.phone_number,
}

это вызывается при выполнении этого кода запроса API:

    class CurrentUser(restful.Resource):
     def get(self):
         return json_response(g.user_service.current_user_get_info())

person vik    schedule 31.10.2014    source источник
comment
Вы когда-нибудь играли с сессией? session["userid"] - это место, где Flask-Login / Security ищет текущего пользователя (источник). Так что, возможно, стоит начать с этого момента, а затем продвигаться вверх к созданному вами коду, чтобы найти, где вы начинаете замечать что-то странное.   -  person Doobeh    schedule 31.10.2014
comment
Я не играю с сессиями. Однако одно, что я делаю, - это устанавливаю Remember_me = True, когда я вызываю login_user и никогда не применяю новый логин. Однако время от времени я заново развертываю свое приложение, когда делаю обновления. Это испортит сеанс? Если пользователь вернется на сайт после повторного развертывания, все сеансы будут очищены? Я предполагаю, что приложение где-то хранит информацию о сеансе, и, вероятно, она исчезнет после повторного развертывания. Однако я заметил, что мне не нужно повторно входить в систему после повторного развертывания.   -  person vik    schedule 01.11.2014
comment
app.secret_key используется для подписи сеансов, поэтому, если он остается неизменным между повторными развертываниями, ваши сеансы все равно будут действительными.   -  person Doobeh    schedule 01.11.2014
comment
Долгая перспектива: используете ли вы Flask-Cache (или любой другой серверный кеш) для кеширования ваших просмотров?   -  person iurisilvio    schedule 01.11.2014
comment
Я не использую Flask-Cache или какое-либо другое кеширование. Тем не менее, я немного читал о Flask и читал, что если вы находитесь в режиме отладки и есть необработанное исключение, Flask сохранит контекст запроса для отладки. Поскольку сайт тестировался, я оставил включенным режим отладки. Если это так, возможно, это какой-то артефакт прокси-объекта current_user и контексты невыполненных запросов. Не могу быть полностью уверенным, но я отключил режим отладки и посмотрю, что произойдет.   -  person vik    schedule 04.11.2014


Ответы (1)


Я нашел проблему и отправляю ее сюда для других, у кого может быть такая же проблема.

Оказывается, пользователи, которые обращались к моему сайту, находились за VPN с прокси. Прокси-сервер кэшировал страницы вместе с файлами cookie пользователя. Когда один пользователь делает запрос, прокси кэширует страницу вместе с файлом cookie этого пользователя в заголовке. По запросу следующего пользователя прокси-сервер будет обслуживать страницу с файлом cookie первого пользователя, и, таким образом, второй пользователь обнаружит себя кем-то другим.

Дополнительную информацию см. Здесь: https://code.google.com/p/doctype-mirror/wiki/ArticleHttpCaching

Я решил это, установив для HTTP-заголовка управления кешем значение «частный», чтобы прокси не пытался его кэшировать. Во Flask это выглядит так:

@app.after_request
def add_header(response):
    response.cache_control.private = True
    response.cache_control.public = False
    return response
person vik    schedule 08.11.2014