Это продолжает случаться случайно у любых и всех пользователей. Со мной этого не происходило, но я был автоматически разлогинен, когда это случилось с кем-то другим. Я даже не представляю, с чего начать поиск.
У меня есть тема на форуме, которую я сделал публичной, чтобы предоставить больше информации. В этот раз два пользователя оказались залогинены как один и тот же пользователь: один — администратор, другой — нет. Причём пользователь, в чей аккаунт они вошли, даже не активен.
@Falco это проблема, которая существует уже несколько лет. Насколько мне известно, она связана с клиентской сессией пользователя и конкретно с идентификатором пользователя (userID). Эту проблему можно лишь обойти, но не исправить, если вместо локального входа (так называемой локальной аутентификации) использовать аутентификацию через сторонние сервисы.
Можете ли вы подтвердить, что это вызвано вашей некачественной локальной аутентификацией?
С уважением, но в интернете существуют тысячи установок Discourse. Только на нашем хостинге работают тысячи из них, и есть множество самохостинговых установок, а ваша — единственная, сообщающая об этой проблеме. Это означает, что проблема, скорее всего, создана вами самими.
Поскольку вы используете собственный обратный прокси перед Discourse, я бы начал с его удаления и перехода к нашей рекомендованной стандартной схеме установки, прежде чем сообщать об ошибке сюда.
Я не уверен, в чём заключается разница между моей кастомной настройкой и тем, что уже встроено в Discourse, поскольку в обоих случаях используется nginx. Однако я не могу её удалить, так как Discourse — не единственное, что я размещаю. Уверен, проблема в моей конфигурации, но если это может случиться у меня, то это может произойти и у любого другого. С остальным размещённым мной программным обеспечением у меня проблем нет. Я не прошу вас держать меня за руку, но я не могу найти никаких других ошибок.
Если у вас нет других идей, куда стоит посмотреть, возможно, вы знаете кого-то, кто сможет помочь. Я уже проверил логи как в обоих контейнерах, так и на соответствующих хостах. Не знаю, где ещё искать причину сбоя.
Я понимаю отсутствие поддержки. Мы не платим клиенты, и некоторые из нас ведут себя не очень вежливо. Я не виню вас в том, что вы указали на меня, так как согласен: это то, что я делаю иначе, и это вызывает такие проблемы. Однако, если вы искренне считаете, что причиной этой проблемы является обратный прокси, не является ли это огромной уязвимостью безопасности? Я не знаю того, чего не знаю о внутреннем устройстве Discourse, но для меня это выглядит как что-то, что должно представлять интерес для разработчиков.
Да, это определенно проблема безопасности. Но если это происходит только в этом конкретном экземпляре, то это проблема безопасности вашего сайта, а не платформы Discourse, верно?
Я с радостью помогу здесь. Были бы вы готовы перенести сайт на отдельный сервер на пару недель, используя нашу стандартную установку, чтобы исключить любые проблемы, связанные с обратным прокси-сервером?
Если мой обратный прокси способен каким-то образом исказить токен или что-то ещё так, что Discourse решит, что один пользователь стал другим… действительно ли имеет значение, что проблема в обратном прокси? Не указывает ли это на наличие уязвимости где-то ещё?
Опять же, я не знаю того, чего не знаю о том, как работает аутентификация.
Мы перешли от хостинга сторонних провайдеров из-за роста затрат, но, возможно, есть и другой способ решить эту проблему. Я изучу настройки обратного прокси. В настоящее время я использую этот контейнер для удобства администрирования, однако могу попробовать что-то другое.
Я понимаю, что вы говорите, будто это происходит только у меня, и у меня нет доказательств обратного, но действительно ли это означает, что для других это невозможно?
Я проведу расследование в конфигурации Nginx, поставляемой вместе с Discourse, чтобы понять, где я допускаю ошибку. Благодарю за ваши разъяснения.
Я не утверждаю, что понимаю всё здесь и сейчас, но когда я начал использовать Discourse, перед ним стоял Varnish, и я столкнулся с множеством забавных проблем, например, с отображением неверного контента.
Discourse выполняет собственное кэширование, и практически любой вид кэширования через обратный прокси — это большая ошибка. Но, конечно, мои очень ограниченные навыки — это совсем не то, что могут сделать «Большая компания» (Big Guys™).
Он попросил меня полностью убрать обратный прокси. Это просто означает удаление некоторых настроек из конфигурации прокси. Я не знал, что Discourse использует внутреннее кэширование, которое может конфликтовать с внешним кэшированием, так что это полезное замечание.
Ссылка, которую он постоянно спамит, ведет к тому, что мы уже делаем:
эти шаги будут работать на любом облачном провайдере, совместимом с Docker, или на локальном сервере.
Он запускает стандартный контейнер. В документации упоминается использование «совместимой с Docker» системы, что он и делает. В документации также упоминается использование локального сервера, что он тоже делает.
Нигде не упоминается использование специального одобренного прокси или отключение кэширования.
Также есть документация по настройке SSO, которая, похоже, вызывала в прошлом проблемы, аналогичные тем, с которыми мы сталкиваемся сейчас:
Всё ещё нет ни слова о конфигурации кэширования или «кастомных» решениях обратного прокси.
Как минимум я предлагаю обновить документацию, чтобы выделить эти потенциальные проблемы, поскольку они очевидны для экспертов Discourse.
Я бы очень беспокоился по поводу такой конфигурации кэширования. Я не до конца понимаю документацию nginx для proxy_ignore_headers, но по умолчанию nginx не кэширует ответы, содержащие заголовок Set-Cookie. Похоже, что эта конфигурация изменяет такое поведение, так что ответы с заголовком Set-Cookieмогут быть закэшированы. Если они будут закэшированы вместе с заголовком Set-Cookie и затем переданы другому пользователю, это вполне может привести к смене учётной записи.
В теории такая конфигурация должна применяться только к медиафайлам, но сопоставление конца URL (включая параметры запроса?) кажется довольно небезопасным способом этого добиться.
Я прекратил его использование. Поскольку другие указали на это, похоже, что в целом это довольно плохая идея. Я ценю объяснение. Я сразу не увидел ничего плохого в том, что оно делало, но я, конечно, не эксперт в этой области.
