session expired что значит

Использование сессий ¶

Активация сессий ¶

Чтобы включить функцию сеансов, сделайте следующее:

Настройка механизма сеанса ¶

По умолчанию Django хранит сеансы в базе данных (с шаблоном django.contrib.sessions.models.Session ). Хотя это может быть удобно, в некоторых конфигурациях быстрее хранить данные сеанса в другом месте; поэтому можно настроить Django для хранения данных сеанса в файловой системе или в кеше.

Использование сессий в базе данных ¶

После настройки установки запустите для установки единой таблицы базы данных, в которой хранятся данные сеанса. manage.py migrate

Использование кешированных сессий ¶

Для лучшей производительности рекомендуется использовать механизм сеанса на основе кеша.

Чтобы хранить данные сеанса с использованием системы кеширования Django, вам сначала нужно убедиться, что кеш настроен; см. документацию по кешу для получения более подробной информации.

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

После настройки кеша у вас есть два варианта хранения данных в кеше:

Использование файловых сессий ¶

Также может быть желательно установить параметр SESSION_FILE_PATH (значение по умолчанию для которого tempfile.gettempdir() обычно является результатом /tmp ), чтобы контролировать, где Django хранит файлы сеанса. Убедитесь, что у веб-сервера есть разрешения на чтение и запись.

Использование сессий на основе файлов cookie ¶

Рекомендуется оставить параметр SESSION_COOKIE_HTTPONLY равным значению, True чтобы предотвратить доступ к сохраненным данным из JavaScript.

Если вы используете сеансы на основе файлов cookie, следует проявлять особую осторожность, чтобы всегда держать секретный ключ в абсолютном секрете для любой системы с удаленным доступом.

** данные сеанса подписаны, но не зашифрованы **

При использовании механизма на основе файлов cookie данные сеанса могут быть прочитаны клиентом.

MAC-код (код проверки подлинности сообщения) используется для защиты данных от модификации клиентом, поэтому данные сеанса недействительны, когда они были изменены. Такая же защита происходит, если клиент, который хранит cookie (например, браузер пользователя), не может сохранить весь файл cookie сеанса и усекает данные. Несмотря на то, что Django сжимает данные, все же возможно превышение обычный лимит 4096 байт на файл cookie.

Нет гарантии свежести

Производительность

Использование сессий в представлениях ¶

Вы можете читать и писать в него request.session в любое время, когда вам будет удобно. Вы можете изменить его несколько раз.

класс backends.base. SessionBase ¶

Это базовый класс для всех объектов сеанса. Он имеет следующие стандартные словарные методы:

Пример: request.session[‘fav_color’] = ‘blue’

Пример: ‘fav_color’ in request.session

Пример: fav_color = request.session.get(‘fav_color’, ‘red’)

Пример: fav_color = request.session.pop(‘fav_color’, ‘blue’)

keys () ¶ items () ¶ setdefault () ¶ clear () ¶

Также есть следующие методы:

Удаляет данные для текущего сеанса и удаляет файл cookie сеанса. Это полезно для обеспечения того, чтобы данные предыдущего сеанса больше не могли воспроизводиться браузером пользователя (например, он это делает django.contrib.auth.logout() ).

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

Удалите тестовый файл cookie. Используется для уборки позади вас.

Определяет, как долго истекает сеанс. Можно передать несколько разных значений:

Чтение сеанса не считается занятием с точки зрения истечения срока действия. Срок действия сеанса исчисляется с момента последнего изменения сеанса.

Эта функция принимает два необязательных именованных параметра:

Возвращает True или в False зависимости от того, истекает ли срок действия cookie сеанса пользователя при закрытии веб-браузера пользователя или нет.

Создает новый ключ сеанса с сохранением данных текущего сеанса. django.contrib.auth.login() вызывает этот метод для борьбы с атаками фиксации сеанса.

Сериализация сессий ¶

Например, вот сценарий атаки, если вы используете pickle для сериализации данных сеанса. Если вы используете механизм сеанса на основе подписанных файлов cookie и ключ SECRET_KEY известен злоумышленнику (в Django нет известной уязвимости, которая раскрыла бы эту информацию), этот злоумышленник может вставить строку в сеанс, это что может привести во время десериализации («распаковки») к выполнению произвольного кода на сервере. Техника для этого проста и легко доступна в Интернете. Даже если файлы cookie хранилища сеанса подписывают данные сеанса, чтобы предотвратить подделку, раскрытие ключа SECRET_KEY немедленно создает уязвимость удаленного выполнения кода.

Встроенные сериализаторы ¶

Кроме того, поскольку JSON поддерживает только текстовые ключи, имейте в виду, что нетекстовые ключи в request.session не будут работать должным образом:

Точно так же данные, которые не могут быть закодированы в JSON, такие как байты, отличные от UTF-8, такие как ‘\xd9’ (который производит UnicodeDecodeError ), не могут быть сохранены.

Подробную информацию об ограничениях сериализации JSON см. В разделе « Написание собственного сериализатора».

класс serializers. PickleSerializer ¶

Принимает любой объект Python, но, как объяснено выше, может привести к уязвимости удаленного выполнения кода, если ключ SECRET_KEY будет раскрыт злоумышленнику.

Написание собственного сериализатора ¶

Класс сериализации должен реализовывать два метода и для сериализации и десериализации словаря данных сеанса соответственно. dumps(self, obj) loads(self, data)

Рекомендации для объектов сеанса ¶

Примеры ¶

Это очень простое представление подключает «участника» сайта:

. и это отключает член, учитывая приведенный login() выше пример :

Создание тестовых файлов cookie ¶

Для удобства Django предоставляет способ проверить, принимает ли браузер пользователя файлы cookie. Вызов метода set_test_cookie() из request.session в представлении, а затем вызвать test_cookie_worked() в одном из следующих представлений, но не в том же виде вызова.

Это странное разделение между set_test_cookie() и test_cookie_worked() необходимо из-за того, как работают файлы cookie. Когда вы устанавливаете файл cookie, на самом деле невозможно узнать, принял ли его браузер до получения следующего запроса браузера.

Рекомендуется использовать delete_test_cookie() для уборки позади вас. Сделайте это, убедившись, что тестовый файл cookie работает.

Вот пример типичного использования:

Использование сессий вне представлений ¶

Доступен API для управления данными сеанса вне представлений:

Обратите внимание, что вам нужно будет позвонить, get_decoded() чтобы получить словарь сеанса. Это необходимо, потому что словарь хранится в закодированном формате:

Запись сеансов ¶

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

В последнем случае приведенного выше примера мы можем явно сообщить объекту сеанса, что он был изменен, установив его атрибут modified :

Аналогичным образом, часть expires файла cookie сеанса обновляется каждый раз при отправке файла cookie сеанса.

Сеанс не сохраняется, если код состояния ответа 500.

Истечение или сохранение сеанса ¶

Этот параметр SESSION_EXPIRE_AT_BROWSER_CLOSE позволяет вам контролировать тип сеансов, используемых инфраструктурой сеансов: сеансы, срок действия которых истекает при закрытии браузера, или постоянные сеансы.

Очистка хранилища сеансов ¶

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

Обратите внимание, что механизм на основе кеша не подвержен этой проблеме, поскольку кеши автоматически удаляют устаревшие данные. То же самое и с движком на основе файлов cookie, поскольку данные сеанса хранятся в браузерах пользователей.

Настройки ¶

Некоторые настройки Django позволяют контролировать поведение сессий:

Безопасность сеанса ¶

Поддомены сайта могут устанавливать файлы cookie для клиента, действительные для всего домена. Это делает возможными атаки фиксации сеанса, если файлы cookie могут быть созданы субдоменами, которые не находятся под контролем доверенных лиц.

Технические детали ¶

Объект SessionStore ¶

Все классы, SessionStore доступные в Django, наследуются от SessionBase методов управления данными и реализуют их, в данном случае:

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

Расширение движков сессий на основе баз данных ¶

класс base_session. AbstractBaseSession ¶

Базовая абстрактная модель сеанса.

Первичный ключ. Само поле может содержать до 40 символов. Текущая реализация генерирует 32-символьную строку (случайную последовательность строчных цифр и букв ASCII).

Строка, содержащая закодированный и сериализованный словарь сеанса.

Дата / время, указывающие дату окончания сеанса.

Возвращает класс хранения сеанса для использования с этим шаблоном сеанса.

Возвращает декодированные данные сеанса.

Декодирование выполняется классом хранения сеанса.

Вы также можете настроить диспетчер моделей, унаследовав от BaseSessionManager :

класс base_session. BaseSessionManager ¶ encode ( session_dict ) ¶

Возвращает указанный словарь сеанса в виде закодированной и сериализованной строки.

Кодирование выполняется классом хранения сеанса, связанным с классом шаблона.

Сохраните данные сеанса, соответствующие указанному ключу сеанса, или удалите сеанс, если данные пусты.

Настройка классов SessionStore выполняется путем перегрузки методов и свойств, описанных ниже:

класс backends.db. SessionStore ¶

Реализация хранилища сессий на базе базы данных.

Переопределите этот метод, чтобы при необходимости возвращать настраиваемый шаблон сеанса.

Возвращает новый экземпляр объекта шаблона сеанса, который представляет текущее состояние сеанса.

Переопределив этот метод, вы можете изменить данные шаблона сеанса до их сохранения в базе данных.

класс backends.cached_db. SessionStore ¶

Реализация хранилища сеансов на основе базы данных и кеша.

Префикс, добавляемый к ключу сеанса для построения цепочки ключей кеша.

Пример ¶

В приведенном ниже примере показан настраиваемый механизм сеанса, управляемый базой данных, включая дополнительный столбец базы данных для хранения идентификатора учетной записи (и, таким образом, предоставляя возможность запрашивать базу данных для всех активные сеансы учетной записи):

Идентификаторы сеанса в URL ¶

Инфраструктура сеансов Django полностью основана на файлах cookie. Он не использует систему идентификаторов сеансов в URL-адресах, как это делает PHP. Это добровольное концептуальное решение. Этот метод искажает URL-адреса и делает ваш сайт уязвимым для кражи идентификатора сеанса через заголовок «Referer».

Источник

Функции обращения к сессиям

Если вы знакомы с обслуживанием сессий с помощью PHPLIB, вы заметите, что некоторые вопросы аналогичны поддержке сессий в PHP.

Посетителю вашего сайта присваивается уникальный id, так называемый session id. Он хранится в куке на стороне пользователя или вводится в URL.

Все зарегистрированные переменные сериализуются после окончания запроса. Зарегистрированные undefined-переменные маркируются как не определённые. При последующих запросах они не определяются модулем сессии, если только пользователь не определить их позднее.

Установки конфигурации track_vars и register_globals определяют, как переменные сессии хранятся и восстанавливаются.

();
// С PHP 4.3 и позже, Вы можете просто использовать представленный пример:
session_unregister ( ‘count’ );
?>

Пример 4. Регистрация сесии, когда register_globals включена

Есть два метода хранения session id:


Модель сессий поддерживает оба метода. Куки являются оптимальными, но, поскольку это ненадёжно (клиенты могут их не принимать), мы не можем полагаться на них. Второй метод внедряет session id непосредственно в URL.

Примечание: Директива arg_separator.output php.ini позволяет специализировать разделитель аргументов.

Следующие пример демонстрирует, как зарегистрировать переменную и как корректно связаться с другой страницей, используя SID.

Пример 5. Подсчёт количества входов отдельного пользователя

if (! session_is_registered ( ‘count’ )) <
session_register ( ‘count’ );
$count = 1 ;
> else <
$count ++;
>
?>

Примечание: Принимается, что не-относительные URL указывают на внешние сайты и, следовательно, не присоединяют SID, так как имеется риск утечки информации о SID на другой сервер.

Для реализации хранения в БД или другого метода вам понадобится использовать session_set_save_handler() для создания набора функций хранения уровня пользователя.

Рассмотрим конфигурационнык директивы по умолчанию:

Имя директивыЗначение по умолчаниюПримечания
session.save_path«»
session.name«PHPSESSID»
session.save_handler«files»
session.auto_start«0»
session.gc_probability«1»
session.gc_divisor«100»Доступна с PHP 4.3.2.
session.gc_maxlifetime«1440»
session.serialize_handler«php»
session.cookie_lifetime«0»
session.cookie_path«/»
session.cookie_domain«»
session.cookie_secure«»Доступна с PHP 4.0.4.
session.use_cookies«1»
session.use_only_cookies«0»Доступна с PHP 4.3.0.
session.referer_check«»
session.entropy_file«»
session.entropy_length«0»
session.cache_limiter«nocache»
session.cache_expire«180»
session.use_trans_sid«0»Доступна с PHP 4.0.3.
session.bug_compat_42«1»Доступна с PHP 4.3.0.
session.bug_compat_warn«1»Доступна с PHP 4.3.0.
session.hash_function«0»Доступна с PHP 5.0.0.
session.hash_bits_per_character«4»Доступна с PHP 5.0.0.
url_rewriter.tags«a=href,area=href,frame=src,form=,fieldset=»Доступна с PHP 4.0.4.

Если вы выставили этот набор в директории, доступной для всеобщего обозрения, такой как /tmp (по умолчанию), другие пользователи сервера смогут подключаться к сессиям, получив список файлов в этой директории.

session.auto_start специфицирует, стартует ли модуль сессий сессию автоматически при стартовом запросе. По умолчанию 0 (отключено).

session.gc_maxlifetime специфицирует количество секунд, после чего данные будут считаться ‘мусором’ и зачищаться.

session.entropy_length специфицирует количество байтов, которые будут прочитаны из файла специфицированного выше. По умолчанию 0 (отключено).

session.use_cookies специфицирует, будет ли модуль использовать куки для хранения session id на стороне клиента. По умолчанию 1 (включено).

session.use_only_cookies специфицирует, будет ли модуль использовать только куки для хранения session id на стороне клиента. По умолчанию 0 (отключено, для обратной совместимости). Включение этой установки предотвращает атаки при передаче session id в URL. Эта установка была добавлена в PHP 4.3.0.

session.cookie_domain специфицирует домен для установки в session_cookie. По умолчанию нет ничего.

url_rewriter.tags специфицирует, какие тэги html перезаписываются для включения session id, если прозрачная поддержка sid включена. По умолчанию a=href,area=href,frame=src,input=src,form=fakeentry

Примечание: Работа с сессиями была добавлена в PHP 4.0.

Источник

Работа с сессиями в PHP

Отредактировано: 04 Февраля 2019

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

Принцип работы сессий: сервер выдает браузеру уникальный идентификатор, и просит передавать его с каждым запросом. Передача происходит стандартными способами, либо через куки, либо через переменные POST/GET.

Идентификатор сессии — это обычная переменная, по умолчанию ее имя — PHPSESSID. Можно изменить директивой session.name в php.ini.

На сервере за передачу информации о сессиях отвечают две настройки в php.ini:

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

Если включена только вторая, то PHP дописывает к каждой относительной ссылке и к каждой форме передачу идентификатора сессии, примерно так:

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

Запись данных в сессию работает так:

Используем например так:

Удаление переменных из сессии:

Для закрытия сессии используется функция:

Для управления HTTP-заголовками отвечающими за кэш, используется функция session_cache_limiter(). Установка nocache, например, отменяет кэширование на стороне клиента.

Источник

You haven’t signed in, or your previous session has expired. Please sign in again — что делать?

Онлайн-магазин AliExpress продолжает предоставлять товары по низким ценам, несмотря на рост конкуренции со стороны других платформ. Появляются необычные функции, каждый день добавляются на виртуальные прилавки сотни тысяч новых дешёвых товаров. Но не всегда пользователям удаётся расплатиться за товар без проблем. В некоторых случаях при совершении оплаты появляется сообщение: « You haven’t signed in, or your previous session has expired. Please sign in again ». Что пользователю предпринять в данной ситуации — читайте далее.

session expired что значит. Смотреть фото session expired что значит. Смотреть картинку session expired что значит. Картинка про session expired что значит. Фото session expired что значит

Что означает ошибка «You haven’t signed in, or your previous session has expired. Please sign in again»

Этот текст с английского языка можно перевести так: « Вы не вошли в систему, или срок вашей сессии истёк. Пожалуйста, повторите авторизацию ». Но при покупке пользователи уже находятся в своих аккаунтах Алиэкспресс. Не понятно, что система магазина ещё от нас хочет. Оказывается, что магазин требует входа в Alipay. Эта так называемая буферная платёжная система. Которая хранит деньги со сделки между вами и продавцом до момента расчёта.

Алипей представляет собой местный сейф для виртуальных денег. Без неё не существовало бы и всего магазина Алиэкспресс. Так как нам (покупателям) приходилось бы платить прямо на банковский счёт продавцу. Таким образом отсутствовала бы такая функция, как « Возврат товара » и подобные. Поэтому существование системы Alipay имеет большое значение для всех сторон.

AliPay представляет собой ещё и популярную систему виртуальных денег в Китае. Кошелёк является аналогом WebMoney для стран СНГ. А также PayPal для жителей Европы и Америки. Китайцы могут использовать виртуальные деньги Alipay для расчёта за проезд в общественном транспорте, оплачивать продукты питания, делать покупки в магазинах. Как и другие системы, китайские виртуальные деньги пытаются стать интернациональными. И сегодня даже граждане России могут зарегистрировать собственный онлайн-кошелёк в Алипей.

Что делать, если возникает ошибка в AliExpress при оплате

Решается ошибка «You haven’t signed in, or your previous session has expired. Please sign in again» чаще всего регистрацией или авторизацией в Alipay. Надо ещё сказать, что данная денежная система для российских граждан не очень удобна. Так как вы столкнётесь с целым ворохом проблем при выводе средств с этого кошелька. Ну а пока давайте рассмотрим процесс авторизации для тех, кто уже имеет аккаунт в Алипей. Чтобы избавиться от ошибки, вам также необходимо отвязать свою банковскую карту и добавить новую.

Регистрация нового пользователя на AliPay

Процесс регистрации на Алипэй является стандартным для подобных систем.

Далее рассмотрим его для тех, кто не сталкивался ранее с такими службами:

Другие способы избавиться от ошибки «You haven’t signed in…»

Если вам показался процесс отвязки банковской карты слишком запутанным, вы можете попробовать решить ошибку другим путём. Для этого вам необходимо выйти из своего аккаунта на сайте магазина Алиэкспресс. Эта кнопка находится вверху справа.

После чего вам необходимо будет перезагрузить браузер и открыть сайт Алиэкспресс. Так, как вы уже удалили файлы куки, необходимо заново вводить регистрационные данные при входе в интернет магазин. Когда вы авторизуетесь, попробуйте снова совершить покупку. Чтобы проверить, появляется ли ошибка «You haven’t signed in, or your previous session has expired. Please sign in again».

Источник

Session Expired when call user Authenticate API WebService #29449

Comments

lecaobaophuc0912 commented Dec 12, 2018

Impacted versions: 12

Steps to reproduce:
Open browser in my odoo page.
Call Ajax with API authenticate:

I got session_id in result.
After then I use session_id to call API :

Current behavior:
I alway get error

Video/Screenshot link (optional):

The text was updated successfully, but these errors were encountered:

pedrobaeza commented Dec 12, 2018

AFAIK, you are not using a proper way for interacting with the server. A good idea can be to use an intermediate library for interacting like https://github.com/OCA/odoorpc, or at least, check how it’s done inside it.

lecaobaophuc0912 commented Dec 12, 2018

I have use a library in NPM https://www.npmjs.com/package/nativescript-odoo and it work all server and database use Odoo 11 but Odoo 12 it can’t work anything and i recieve error likely ajax in browser

pedrobaeza commented Dec 12, 2018

Sorry, but this is out of scope of Odoo itself. Internal things can change, and as this is not an official way of accessing Odoo (see https://www.odoo.com/documentation/12.0/webservices/odoo.html for the official one), you should adapt your code to the changes each version has. OdooRPC is working now with v12, so check how it’s done.

Closing this by the reasons above.

artaradteam commented Mar 7, 2019

Hi @LeCaoPhuc
I have same problem.
did you find any solution?

lecaobaophuc0912 commented Mar 7, 2019 •

reponse of get_session_info likely reponse of authenticate method expect session_id and that is all you need.
This solution can work from odoo 10, 11, 12 with me.

lecaobaophuc0912 commented Mar 9, 2019

Hi @artaradteam.
My ngnix config here:

artaradteam commented Mar 19, 2019

lecaobaophuc0912 commented Mar 21, 2019

chaise29 commented Mar 31, 2019

Not sure if it is specific to odoo v12, but authentication is actually made with the response header ‘set-cookie : session_id=xxxxxx’ that you get from the ‘/web/session/authenticate’ url request. The ‘session_id’ attribute that you get from the response body is somehow not correct.

So what you have to do in that case is to :

artaradteam commented Apr 6, 2019

Hi chaise29,
Thank you for answer, by this configuration it work on browser but when I generate apk and run it on my device,it does not work,
I think value of Access-Control-Allow-Origin in device is not http://localhost:8100.
did you have any idea?
thanks

chaise29 commented Apr 14, 2019 •

quanganh206 commented Jun 10, 2019

I do not think it is a good solution, actually it’s just work on browser. Even you accept cors with http://localhost android app still not working. And specially with iOS there is no way with ionic://localhost.

Jerther commented Nov 20, 2019

If that can be of any help to anyone, I just realized the JSONRPC mechanism has changed in 12.0, or at least the way we used to use it back in 8.0 has. In short, the session_id is not needed anymore, but the logged user ID ( uid ) has to be provided instead.

Here is the official documentation. It’s in Python but it’s fairly easy to translate to JS. I’ve been able to write a Google Apps Script that uses Odoo 12 JSONRPC which is hosted behind NGINX. I did not have to add any CORS specific config.

I hope that brings some light.

sherpya commented Nov 28, 2019

so what is the point of having a response with a bad session_id to an authenticate api call?

Jerther commented Nov 28, 2019

To my knowledge, I’d say there’s no point anymore. But let’s hear it from @pedrobaeza 😉

sherpya commented Nov 28, 2019 •

@Jerther also misleading better not to have such wrong value

lwl021051 commented Jan 7, 2020

I fix issue. The below is my steps.

step1:
ajax login the api: ‘https://your_url/web/session/authenticate’;

step2:
get the session id from response_header(NOT result session id);

step3:
ajax the api: ‘https://your_url/web/session/get_session_info’;
header set step2 response_header session id;

aliomattux commented Mar 21, 2021

I have a question about this, I have an Angular app which uses Json RPC. I noticed Pedro say this is not the officially supported way, but i’ve found that xmlrpc is not very popular or supported out of box with Angular, so it would be more of an uphill battle to implement it.

I have a similar scenario where I went from Odoo 8, but now 14. In my app, the login screen will call /web/session/authenticate. The response contains no session id, or any identifiable session variable. It does return user id. When I make a request to /web/session/get_session_info with a now null session id, I get the session expired message like above, but if I make again the call with no parameters at all, it will return the data and my user id. I can also make model calls.

From this behavior, it seems that once login is called, there is no need to supply user id or session. When user is done, call logout. A bit puzzled on if this is a security problem or what would happen if multiple users are using the app at the same time, how does it track. From what i’ve found, there is no documentation at all describing anything about json rpc even though it is the method used by the odoo app itself.

aliomattux commented Mar 21, 2021

It looks like Odoo server responds with a cookie that is associated automatically by the browser, and any further request to the same server automatically sends the cookie back containing the session id.

Источник

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *