Загадочное поведение Django API в рабочей среде

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

В настоящее время существует серверная часть веб-приложения (django / wagtail / coderedcms), которую необходимо преобразовать в мобильное приложение. Чтобы мобильное приложение могло взаимодействовать с сервером Backend, я реализовал конечную точку API с помощью Django-rest-framework. Для аутентификации пользователя я уже реализовал простую конечную точку аутентификации с помощью Django-rest-simplejwt. Эта часть работает нормально. Одним из требований к приложению является то, что пользователь должен иметь возможность просматривать / обновлять свой профиль через мобильное приложение.

При работе на сервере разработки на моем локальном хосте поведение такое, как задумано, каждый пользователь может войти в систему с помощью приложения, серверная часть отправит обратно токен, и токан будет впоследствии использоваться для доступа к различным частям приложения.

Когда одна и та же кодовая база реализуется в производственной среде (в настоящее время на стадии UAT), обнаруживается одно поведение. Если несколько пользователей вошли в систему одновременно, сервер вернет только профиль первого пользователя, запросившего профиль.
значение:
пользователь A вошел в систему ....
пользователь B вошел в систему ....
пользователь B запросил просмотр своего профиля (показан профиль B)
пользователь Запрос на просмотр его профиля (показан профиль B) ‹- должно быть правильное поведение Показан профиль A.

Это сбило меня с толку, так как во время тестирования на localhost поведение было следующим:
пользователь A вошел в систему ....
пользователь B вошел в систему ....
пользователь B запросил просмотр своего профиля (profile Отображается B)
пользователь Запрос на просмотр его профиля (отображается профиль A)

Я не знаю, связано ли это с настройками docker, nginx или django.
Однако теперь я могу ограничиться только Nginx и docker, поскольку я использую ту же конфигурацию в localhost рядом с статусом debug = true.

Любая помощь или указатель были бы полезны.

Заранее благодарю вас за все что прочитал и отвечаю на этот глупый, но загадочный вопрос

С уважением,
Ашраф

Редактировать

В ответ Огулкану Ольгунеру

с производственного сервера почтальон владеет этим в заголовке отвечает

allow →GET, POST, OPTIONS
cache-control →max-age=300
connection →keep-alive
content-encoding →gzip
content-type →application/json
date →Wed, 25 Nov 2020 20:59:03 GMT
expires →Wed, 25 Nov 2020 21:03:30 GMT
server →nginx/1.17.4
strict-transport-security →max-age=31536000
transfer-encoding →chunked
vary →Accept, Origin, Cookie
x-cdn →Incapsula
x-content-type-options →nosniff
x-frame-options →ALLOWALL
x-iinfo →4-22327133-22328885 NNYN CT(2 2 0) RT(1606337880159 62932) q(0 0 0 -1) r(1 1) U16
x-wagtail-cache →hit

для LocalHost

allow →POST, GET, OPTIONS
content-length →204
content-type →application/json
date →Wed, 25 Nov 2020 20:57:45 GMT
server →WSGIServer/0.2 CPython/3.8.5
vary →Accept, Origin
x-content-type-options →nosniff
x-frame-options →DENY

person Ash Zol    schedule 25.11.2020    source источник
comment
звучит как проблема с кешированием.   -  person thebjorn    schedule 26.11.2020
comment
Спасибо я тоже так думаю   -  person Ash Zol    schedule 26.11.2020


Ответы (1)


Я предполагаю, поскольку информации о том, почему могла быть вызвана ошибка, не так много. Если вы не используете отдельную систему кеширования в производственной среде (например, Redis), эта ошибка может быть вызвана клиентом. Вы пробовали тот же сценарий с таким инструментом, как Postman?

person Ogulcan Olguner    schedule 25.11.2020
comment
Пожалуйста, обратитесь к моей редакции исходного сообщения для почтальона, также я не использую отдельную систему кеширования - person Ash Zol; 26.11.2020
comment
Вы уверены, что у вас локально запущен Nginx? WSGI отображается как веб-сервер в запросе, отправленном на localhost. Если в вашем Nginx есть какие-либо настройки кеша, это может быть актуально. Если вы не управляете местоположениями в проекте с помощью Nginx одно за другим, я рекомендую вам установить настройки публичного и частного кеша в Django вместо Nginx. Фреймворк кеширования Django - person Ogulcan Olguner; 26.11.2020