Открыть список
Как стать автором
Обновить

Комментарии 45

На днях столкнулся с той же проблемой. В итоге, пришёл к третьему способу со скрытым iframe-ом.
Способ с редиректом плох тем, что IE издаёт щёлкающий звук при каждом редиректе, что в моём случае было неприемлемо, поскольку iframe-ов на странице может быть несколько.
Спасибо, интересная статья.

Уберите из названия ВКонтакте и Facebook. В посте нет почти ничего, связанного с социальными сетями. Переместите лучше в браузеры.
Спасибо за совет.
Переместил в «Браузеры».

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

а как эту проблему решают разработчики других популярных приложений? Возможно, эта проблема возникла у вас, потому что вы делаете что-то неправильно?
В том то и дело, что, как выяснилось в итоге, это нормальное поведение браузеров.
При установке галочки в такое положение (стоит в вышеперечисленных браузерах по дефолту) он перестаёт принимать кукисы от содержимого iframe'а (подразумевается, что содержимое принадлежит другому домену) до определённых действий пользователя внутри этого iframe (в частности до перехода по ссылке).

А решение проблемы и было в таком порядке:
1. в гугле быстрым поиском ничего не нашлось.
2. а как же тогда у других то работает?
3. ковыряли другие приложения, нашли одно из описанных в топике решений
4. решил изучить тему глубже, тщательно погуглил, посмотрел как у других, поэксперементировал и написал по результатам этот хабратопик
я имел в виду, что, возможно, для приложений фейсбука/вконтакте предполагается другой механизм поддержания сессии, не через куки. Например, при первом запросе идентификатор пользователя есть в урле, а во втором — он есть как минимум в рефёрере. Если же немного напрячься, то ещё при показе первой страницы можно во все ссылки и формы напихать тот же идентификатор, и вуаля! он есть у вас безо всяких кук.

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

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

Плюс, как выяснилось в итоге, большинство приложений пользуются именно предложенными в хабратопике способами.
ясно. Странно, что API платформ никак не решают эту проблему
можно хранить информацию в localStorage вместо куков, когда код полностью под вашим контролем, но когда надо использовать чужой код/приложения использующие куки, то приходится так извращаться
У меня в IFrame приложении пока такая задача как у Вас не стоит, но для идентификации пользователей на уже загруженной странице через JS можно навесить номера сессий на все ссылки внутри страницы, и они при клике уйдут на сервер как дополнительный GET-параметр.
Да, можно.
Но мы решили, что пусть уж извращение будет в одном месте, чем на каждой странице. =)
И для Вашего способа нам тоже пришлось бы больше переделывать…
Моё приложение работает уже давно, и ни я, ни кто-либо из пользователей ни разу с такой проблемой не столкнулся…
А ссылкой поделитесь? =)
Спасибо!

В Safari 5.0.3 (Win) приложение так и не установило ни одного cookies'а.
В Opera 11.00 (Linux) cookies устанавливаются, но не на первой странице.

Насколько я понял, у Вас приложение вообще не требовательно к cookies, и сессии при помощи них у вас не ведутся. Скорее всего именно из-за этого Вы не имели проблем.
Да, как выяснилось, в моей опере стоит «принимать все куки».

Рассматриваю вариант при старте делать AJAX запрос на другую страницу, которая будет исключительно ставить cookie. Может, пробовали?

В куки в игре хранится информация по части настроек, как положение и масштаб карты, список открытых вкладок и т.п.

Логин реализовал просто — из GET-параметров ID пользователя и ключ записывается в JS-переменные, а дальше всем страницам он передаётся, и на каждой код начинается с проверки пользователя:

if(md5($settings["id"].'_'.$_POST["user"].'_'.$settings["secret"])==$_POST["key"]){
Про способ с AJAX не уверен, что сработает.
Третий способ из топика для сервера и для пользователя выглядит практически так же, как если бы это был AJAX.
Да, через AJAX не работает.
Зато в Opera 11 (Linux) всё прекрасно ставится через JS даже с «принимать только с посещаемого узла». Интересно, это баг или фича?
Тут какой способ не попробуешь, везде думаешь, баг ли это или фича…

Я считаю, что нужно пользоваться, пока работает. Если вдруг пофиксят, то у нас в запасе ещё способы есть. =)

P.S. А Вы попробуйте ещё в Safari протестировать.
По поводу «принимать все куки» хотел сказать, что, по-моему(специально не проверял, но по косвенным наблюдениям это так), когда обновляете Opera с более старых версий, то новые дефолтовые настройки не применяются. Поэтому если ничего не меняли ранее, то останется «принимать все куки».
А вот при чистой установке по дефолту будет «только с посещаемого сайта».
В своё время столкнулся с такой проблемой под IE, тестируя уже разработанное приложение для Вконтакте. Решение нагуглил довольно быстро, но за пост отдельное спасибо. Помнится, тогда такая ситуация поставила меня в ступор минут так на 10.
Аналогично: пока не разобрались в теме, находились в ступоре и не могли понять, почему не работает.
Cookie вроде не нужны приложениям вконтакте, так как вконтакте передает ид пользователя и там есть вконтавтовское хранилище для данных.

А вообще, решение в браузерах бредовое — мало того, что 3-зя сторона может получить куки извращениями с отправкой формы, их банально можно получить добавлением скрипта на страницу, как это делает например Google Analitics (и который за такое поведение давно забанен в моей Опере).
Хорошая ссылка, спасибо.
Не против, если я её в «ссылки по теме» добавлю?
Ставьте конечно
Блин, ну почему нельзя было сделать нормально, для сайта куки свои, для айфрейма свои, и они никак не пересекаются :(
Являюсь разработчиком iframe приложений для ВКонтакте уже год.
С этой проблемой столкнулись давно, костыли все пробовали, но в итоге пришли к выводу, что в iframe приложениях лучше не использовать куки.

В основном куки нужны для авторизации, поэтому мы используем 100% рабочий метод — передаем параметры авторизации через URL.

Вот так это выглядит: vkontakte.ru/app1905375

— Небольшой оффтоп: вы используете ссылки в приложении? Если да, то скоро столкнетесь с проблемой, узнав что не одно iframe приложение ВКонтакте не может работать одинаково правильно во всех браузерах. За год разработчики ввели некоторые вещи, которые уменьшают возможность глюков, но до конца проблему не вылечили. Кнопки Назад и Вперед на данный момент вообще адекватно не работают, из-за проблем с методом onLocationChanged. Если будет время, напишу пост про это на хабре, может местные умельцы придумают более стабильный вариант.
Передавать сессию в URL — это либо через JS дописывать идентификатор, либо это же делать сразу же в html.
В одном случае извращения не меньшие, чем описанные в топике, в другом — надо заранее это продумывать, иначе потом нужны будут трудозатраты на поиск и замену всех ссылок.
Поэтому лично я считаю cookies'ы лучшим вариантом.

Ссылками пользуемся, но пока передача в parent не до конца проработана. Приём с onLocationChanged вроде бы работает. Кроссбраузерность проверим. =)

По поводу написания топика: было бы замечательно почитать, т.к. мы тоже используем/будем_использовать это.
> В одном случае извращения не меньшие, чем описанные в топике

Да, но это вариант «в лоб», который 100% работает.
А вот методы, описанные в топике, могут сломаться при очередной выходки браузера.

Но все равно спасибо, полезный материал.
* Начиная использовать P3P следует серьезно задуматься над тем что конкретно будет в заголовках и каковы будут последствия если содержимое не будет соответствовать действительности. А то подадут на вас в суд по, вроде как, пустячному поводу и имей потом гемморой.

Прикормить параною :)
Спасибо за решения.
Смущает только то, что метод для ИЕ очень сильно смахивает на использование уязвимости.
как я уже написал выше вместо куков имеет смысл использовать localStorage. Он не имеет таких ограничений и нормально работает в iframe. Хотя конечно оперировать им придется при помощи javascript и для старых версий IE делать P3P заголовки и пользовать куки.
Спасибо за решение. Данная проблема оказывается и была у нас в loginza (при авторизации через Вконтакте). Теперь исправим используя ваш метод.
Какой из трёх (точнее из двух, т.к. очевидно не первый) выберете? :)
Третий вариант не помог. Все равно в Safari странная ситуация с куки получается, настройки по умолчанию: принимать куки только с посещаемых сайтов.
Сначала подумал, что изменили что-то в новой версии, но сейчас обновился до 5.1 и посмотрел то приложение — работает.
Может что-то неверно делаете?
Оказалось дело в другом было, в сафари почему то при авторизации через вконтакте, не ставится кука vk_app_ на наш домен. В итоге перешли на oAuth сегодня.
Возник вопрос, а как выглядит страничка example.com/blank.html, внутри что-то есть у нее или она просто пустая?
Содержимое не имеет значения. В частности можно поместить пустую страницу
А вот в FF 10 кажется из этих вариантов ничего не работает =(
FF 10.0.2 полет нормальный
У меня не работает способ #3 в Safari 5.1.7 на маке. Пришлось перебрасывать родительский фрейм на страницу установки куки, а с нее — обратно в приложение (Facebook Page Tab App):

setcookie('cart_id', md5(uniqid(rand(), true)), time() + 604800);
header('Location: www.facebook.com/xxx');

Выглядит не очень, так как при первом просмотре идет заметный редирект на внешний сайт.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.