Я пишу веб-приложение Python / Django, которое использует OAuth (для TwitterAPI не то, чтобы это имело значение).
Я сохраняю идентификатор сеанса в своей функции входа в систему, а затем после использования OAuth дляполучить токен пользователя, я пытаюсь получить sessionID в моей функции обратного вызова.В этом случае функция обратного вызова всегда дает сбой (выдает исключение), поскольку не может найти токен OAuth в сеансе.С помощью отладчика я могу определить, что идентификатор сеанса, который использует сервер, неверен - он не совпадает с идентификатором сеанса, который был сохранен в функции входа в систему.Поэтому неудивительно, что жетонов Оаута там не было.Сеанс, который появляется в обратном вызове, был один и тот же каждый раз (пока я не попытался удалить его - см. «Вещи, которые я пробовал ниже»), и он начинался как старый сеанс с некоторыми данными из другого источника.Приложение django, запущенное на том же сервере, к которому я не прикасался пару недель.
Вот кикер: все, что я описал, является проблемой только на нашем производственном сервере и только при подключении к нему с моего компьютера.Позвольте мне уточнить: это происходит только с моим конкретным ноутбуком.Я могу подключиться к приложению просто отлично с чужого компьютера.Другие люди не могут подключиться со своими учетными записями на моем компьютере.Кроме того, я могу очень хорошо подключиться к приложению, когда оно работает на моем локальном хосте, используя встроенный веб-сервер django, но не на рабочем сервере.
Моя настройка: мой сервер и локальная коробка работают = Django1.2.0 и Python 2.6.5.Мой локальный компьютер работает под управлением Snow Leopard и веб-сервера Django, сервер работает под управлением Ubuntu, Apache2 и mod-wsgi.Для сессий я использую стандартную сессионную сессию Django (DB).
Вещи, которые я пробовал, безрезультатно:
вход в систему с другой учетной записью, включая новые учетные записи, которые никогда не подключались к этому приложениюдо Очистка файлов cookie, в режиме инкогнито, с использованием другого веб-браузера на моем компьютере.Каждый раз при проверке моих файлов cookie идентификатор сеанса соответствовал идентификатору сеанса в функции входа в систему и отличался от идентификатора сеанса в обратном вызове. удаление сеанса в базе данных, которая появляется в функции обратного вызова (та, которая оказалась старыми данными).Функция обратного вызова по-прежнему не работает, и идентификатор сеанса, который она, похоже, использует, теперь является новым , использующим другой бэкэнд сеанса (DB-кеш, плоский файл и т. Д.) перезапускает сервер, мой компьютер,и т. д.
Мой первый вопрос по StackOverflow, так что потерпите меня, если я не совсем следую местным соглашениям.Я просто в растерянности относительно того, что даже искать - что может вызвать сессию не работать на моем конкретном компьютере и (пока!) Только на моем конкретном компьютере?
РЕДАКТИРОВАТЬ: решил, через несколько часов после публикации этого вопроса, после нескольких дней борьбы с ним!
Проблема не имела никакого отношения к моему компьютеру и была вызвана человекомпечатать на нем!Подсознательно я набирал «www.our-domain.com», и все мои коллеги все время набирали «our-domain.com».У нас не было правил переписывания Apache, поэтому при входе в систему идентификатор сессии устанавливался в файле cookie с «www».как часть домена, но перенаправление для функции обратного вызова имело связанный URL без «www.», поэтому мой браузер использовал два разных куки, которые я почему-то не видел до сих пор (потому что то, как я искалкуки также включены в www!).Очень просто, и должен был подумать об этом раньше.Мораль истории: будьте осторожны с поддоменами во время сеансов.