Поддерживаю расширение (LiveJournal Addons), в котором многое построено на Ajax-запросах. С недавнего времени пользователи стали жаловаться на неполадки самого загадочного свойства. Расширение пользуется авторизацией на сервере через cookies. Тесты показали, что при обычном открытии страниц cookies работают. Но Ajax-запросы возвращают такие ответы, будто cookies не верны или их нет. Один из пользователей нашёл причину.
В настройках третей версии Firefox добавилась новая опция на вкладке «Приватность»: «Принимать cookies со сторонних сайтов». Если галочка снята, расширение не работает правильно.
Я проверил отсылаемые на сайт заголовки при помощи Live HTTP Headers. Оказалось, что при обычном открытии страниц браузер отсылает серверу cookies с авторизацией, а при Ajax-запросах — не отсылает, не воспринимая их как родные для LiveJournal. Не отсылаются вообще никакие cookies, заголовок просто отсутствует.
Оказалось, что при запрете cookies со сторонних сайтов перестают работать и другие расширения (например, Google Reader Notifier, мониторящий известную rss-читалку через Ajax).
Кто-нибудь знаете, в чём причина такой странности, какова природа этой опции и как бороться с нелогичными последствиями?
можно вручную добавить в ajax-запрос заголовок с куками.
примерно так:
можно вручную добавить в ajax-запрос заголовок с куками.
А есть ли способ автоматически получить cookies, подходящие для запроса? Например, по location запрашиваемого документа?
homo_nudus
есть сервис для куков, из него можно. я сам пробовал как раз для такой ситуации, только куки передавал в post параметрах. на mdc легко можно найти 
Пример с MDC:
Код:
var ios = Components.classes["@mozilla.org/network/io-service;1"].getService(Components.interfaces.nsIIOService);
var uri = ios.newURI("http://www.livejournal.com/", null, null);
var cookieSvc = Components.classes["@mozilla.org/cookieService;1"].getService(Components.interfaces.nsICookieService);
var cookie = cookieSvc.getCookieString(uri, null);Почему-то в cookie оказывается только последнее cookie из шести, а этого не достаточно. Перечислители из интерфейса nsICookieManager работают только с указанием конкретных доменов разных уровней, а их автоматически не предскажешь. Поэтому проблема остаётся.
homo_nudus
хм. у меня не было таких проблем. может быть домен совпадает только у одного?
может быть домен совпадает только у одного?
В том то и дело что домен первого уровня совпадает у всех шести, у пяти совпадает домен полностью (к домену одной из них добавляется www). Но только последняя cookie включается в строку, получаемую из описанного алгоритма.
homo_nudus
я не понял, что ты хотел сказать, но попробуй убрать www 
В списке cookies, относящихся к сайту, есть шесть куков, то есть шесть пар "заголовок - значение" (смотрел в "Настройки - показать cookies - livejournal.com"). В свойстве "домен" для первой стоит ".www.livejournal.com", для остальных пяти значится ".livejournal.com".
При открытии страницы все они плюсуются и отсылаются серверу (смотрел в логах запроса при помощи Live HTTP Headers).
При Ajax-запросах и запрете куков для посторонних сайтов ни один из куков не отправляется.
При использовании nsICookieService, как описано выше, в результирующую строку попадает только последняя пара из шести.
Да, очень похоже. Причём соотношение host и пути для GET одно и то же при XMLHttpRequest и при обычном запросе, а поведение разное. Спасибо за ссылку. Будем надеяться, что исправят.
Насколько я понимаю, доступа к списку исключений из расширения нет, потому что он хранится в отдельном файле SQLite. Так что ничего, похоже, с этим не поделаешь, только пользователей предупреждать.
homo_nudus
Неплохо бы для начала подтвердить баг
А что для этого нужно? Аккаунт я там завёл, но не могу разобраться, как подтверждать. Vote? Или нужно откомментировать?
homo_nudus
Откомментировать.
Откомментировал, правда, с дурацкой ошибкой. Жаль, править комментарии нельзя.