Comments 29
кстати у мобильного сафари на айфоне есть еще неприятная штука — до первого «поста» браузер не принимает никаких кук вообще, и точно также не работает аякс (даже не делает обращений)
А на айпеды это не распространяется? Не совсем понятно, как это ajax не работает до поста? Первый запрос в приложении должен быть POST а не GET или что имеется в виду?
на все распространяется, сафари под иос один
да, сафари дает работать с сервером только после того как сделать на него осмысленный пост. причем если на настольном сафари можно сделать скрытый фейковый пост через ручную форму (вместо пользователя) то на мобильном такое не катит
до первого такого взаимодействия с сайтом с него не принимаются куки а обращения к аяксу (я через jQuery только пробовал) оканчиваются ошибкой (на сервер не приходит ничего даже)
по крайней мере у меня так, может где-то чего недопонял, но сам столкнулся
да, сафари дает работать с сервером только после того как сделать на него осмысленный пост. причем если на настольном сафари можно сделать скрытый фейковый пост через ручную форму (вместо пользователя) то на мобильном такое не катит
до первого такого взаимодействия с сайтом с него не принимаются куки а обращения к аяксу (я через jQuery только пробовал) оканчиваются ошибкой (на сервер не приходит ничего даже)
по крайней мере у меня так, может где-то чего недопонял, но сам столкнулся
Я все еще не понимаю, что такое «осмысленный пост» и чем он отличается от ajax поста, сделанного через тот же jQuery. Приведите пример, а то у меня все работает, не могу понять проблему.
на странице форма с кнопкой сабмит и методом пост. после клика тот сайт на который ведет форма становится «нормальным», без ограничений. до этого поста аякс на домен куда эта форма ведет оканчивается ошибкой
у вас это может работает если вы на этот сайт как-либо до этого зашли что сафари пометил его как «нормальный»
у вас это может работает если вы на этот сайт как-либо до этого зашли что сафари пометил его как «нормальный»
Да нет, у меня вообще ни разу POST не происходит с полной перезагрузкой страницы. Login отправляется через AJAX POST с помощью jQuery. Если логин произошел, то дальше выполняю уже операции с сервером, требующие аутентификации. Предоставьте демо сюда, может чем помогу и я и люди.
Может Вы на iPhone пробуете? У меня только iPad3 и iPad2 под рукой.
подтверждаю. с айфоном хрень. если слать аякс запросы через jquery, на сервак они доходят как OPTIONS вместо GET или POST. при чем нативные через XMLHttpRequest доходят нормально.
Синхронизация сессионной переменной cookies и localStorage — не очень хорошая идея, потому что пользователь может отвалиться по таймауту.
Хочу немного внести ясности про «Псевдо-приложения» — это фактически закладка на страницу, вся механика используется Сафари (это про хранения куков и прочих)
FullScreen по разному работает на iPhone и iPad: у iPad он может быть только, если открыть через «псевдо-приложение». А так как это просто страница в Сафари, то можно воспользоваться всей мощью HTML5 (включая offline web app), единственное нужно не забывать про ограниченность пространства под хранение cookies и localstorage.
Про проблемы с кукисами: вы что то неправильно делаете, действительно кукисам нужно указывать срок годности, если вы не хотите их потерять после «выхода» из приложения или после «окончании» сессии (работает также как и Сафари). А самое главное уберите тег:
Хочу немного внести ясности про «Псевдо-приложения» — это фактически закладка на страницу, вся механика используется Сафари (это про хранения куков и прочих)
FullScreen по разному работает на iPhone и iPad: у iPad он может быть только, если открыть через «псевдо-приложение». А так как это просто страница в Сафари, то можно воспользоваться всей мощью HTML5 (включая offline web app), единственное нужно не забывать про ограниченность пространства под хранение cookies и localstorage.
Про проблемы с кукисами: вы что то неправильно делаете, действительно кукисам нужно указывать срок годности, если вы не хотите их потерять после «выхода» из приложения или после «окончании» сессии (работает также как и Сафари). А самое главное уберите тег:
<meta name="apple-mobile-web-app-capable" content="yes" />
Ясности не добавилось, «пользователь может отвалиться по таймауту» — это как? Имеется в виду, что сессия со стороны сервера прекратится или что?
Я как раз и пишу про отличия в механике хранения кукизов «псевдо-приложений» и обычных «закладок на страницу». Механика меняется при добавлении этого самого apple-mobile-web-app-capable.
И сессионные кукизы не имеют пол «Exires», я ссылку об этом прислал (см. ниже, нечаянно не туда постнул).
Я как раз и пишу про отличия в механике хранения кукизов «псевдо-приложений» и обычных «закладок на страницу». Механика меняется при добавлении этого самого apple-mobile-web-app-capable.
И сессионные кукизы не имеют пол «Exires», я ссылку об этом прислал (см. ниже, нечаянно не туда постнул).
Да, имеется в виду, что сессия прекратится на стороне сервера.
А какие цели вы ставите? Избавится от адресной строки?
Разницы в механике между «псевдо-приложением» и закладкой в сафари нет. Есть только дополнительные теги в коде страницы. Ведь, чтобы создать «псевдо-приложение» вам нужно вначале зайти на этот сайт из сафари.
Почитайте статьи как можно сделать fullscreen средствами javascript. На stackoverflow достаточно много об этом написано. Я изменю свое утверждение — «Можно получить fullscreen не используя apple-mobile-web-app-capable. И даже не используя apple-touch-fullscreen.» И как я сказал (или имел ввиду) куки режутся именно из-за этого тэга.
А какие цели вы ставите? Избавится от адресной строки?
Разницы в механике между «псевдо-приложением» и закладкой в сафари нет. Есть только дополнительные теги в коде страницы. Ведь, чтобы создать «псевдо-приложение» вам нужно вначале зайти на этот сайт из сафари.
Почитайте статьи как можно сделать fullscreen средствами javascript. На stackoverflow достаточно много об этом написано. Я изменю свое утверждение — «Можно получить fullscreen не используя apple-mobile-web-app-capable. И даже не используя apple-touch-fullscreen.» И как я сказал (или имел ввиду) куки режутся именно из-за этого тэга.
Ну если сервер удалит сессию, т.е. не будет признавать идентификатор сессии, то клиент об этом узнает по его ответам и должен перелогиниться.
Как «можно получить fullscreen не используя apple-mobile-web-app-capable». Ссылку в студию.
Нужно чтобы приложение работало как нативное, т.е. запускалось по иконке на рабочем столе, открывалось в fullscreen, не масштабировалось тачем. Я такого не нашел.
Как «можно получить fullscreen не используя apple-mobile-web-app-capable». Ссылку в студию.
Нужно чтобы приложение работало как нативное, т.е. запускалось по иконке на рабочем столе, открывалось в fullscreen, не масштабировалось тачем. Я такого не нашел.
Не обессудьте за грубость да поможет вам гугл
Также могу кинуть в личку ссылку на сайт, где это сделано.
Также могу кинуть в личку ссылку на сайт, где это сделано.
Там везде по apple-mobile-web-app-capable и еще про
window.scrollTo(0, 1); говорят, но я не нашел рабочего примера. Давайте точную ссылку, кусок кода или демонстранционный рабочий пример.Из кода, предоставленного GeorgeKoraff, выделена идея динамического добавления тегов, но кукизы все еще сбрасываются. Продолжаем эксперименты над альтернативными методами. А вот динамическая вставка тегов, может кто-то тоже ведет эксперименты и это пригодится:
AddMeta("apple-mobile-web-app-capable", "yes");
AddMeta("apple-mobile-web-app-status-bar-style", "black");
AddMeta("viewport", "width=device-width; initial-scale=1.0; minimum-scale=1.0; maximum-scale=1.0; user-scalable=no;");
function AddMeta(name, value) {
var meta = document.createElement('meta');
meta.name = name;
meta.content = value;
document.getElementsByTagName('head').item(0).appendChild(meta);
}
Тут мне в твиттер написали, чтобы я вас спросил — есть ли на странице тег (если нет, то возможно поэтому OPTIONS и отправляется)?
*тэг
<base>проясните связь тега base и OPTIONS запроса.
Лично я и сам не вкурил, посмотрим что человек, задавший вопрос, ответит.
Вот получил ответ:
OPTIONS отправляется при кросс-доменных запросах, поэтому браузеру нужно знать домен сайта до запроса.
И возможно браузер мог бы определить домен из тега base если по какой-то причине он не хранится с мета-данными ярлыка на homescreen
Кстати, я бы в случае OPTIONS запроса просто прологировал http заголовки, чтобы понять с какого домена запрос.
может у них ярлык для www.site.com, а запрос идет на site.com
OPTIONS отправляется при кросс-доменных запросах, поэтому браузеру нужно знать домен сайта до запроса.
И возможно браузер мог бы определить домен из тега base если по какой-то причине он не хранится с мета-данными ярлыка на homescreen
Кстати, я бы в случае OPTIONS запроса просто прологировал http заголовки, чтобы понять с какого домена запрос.
может у них ярлык для www.site.com, а запрос идет на site.com
Внимание: в статье появился UPD3, содержащий универсальное решение по адаптации в фулскрин режим обычных сайтов, которые содержат ссылки и перегружают страницы полностью, без AJAX.
Выложил библиотеку MarcusAurelius на Nuget.
Библиотека доступна тут nuget.org/packages/Mobilization.
А также легко устанавливается командой PM> Install-Package Mobilization в Nuget Package Manager в Visual Studio.
Библиотека доступна тут nuget.org/packages/Mobilization.
А также легко устанавливается командой PM> Install-Package Mobilization в Nuget Package Manager в Visual Studio.
Я понимаю, что поднимаю демона из могилы, но у меня есть несколько дополнений, которые я прочувствовал, когда делал Web App для KiDROM.RU:
1) запоминание текущего пути — это хорошо, но плохо работает со всем, что идёт не через ссылку (формы, например). В итоге: форму засабмитил, CurrentLocation != StoredLocation — редиректит на StoredLocation, который неправильный… В общем, было бы круто иметь базовый URL Web App (который был при сохранении), но я не знаю, как его получить, поэтому редирекчу на StoredLocation тогда и только тогда, когда CurrentLocation=/ и отличается от StoredLocation (как бы предполагая, но Web App сохраняют с корневой страницы). Если кто знает, как получить URL Web App — напишите!
2) то ли в PHP, то ли в Yii с какого-то момента для сессионных кук форcировали httpOnly=true — это значит, что они больше не видны в document.cookie. Тут варианта два: или в конфигах прописывать httpOnly=false, или делать свой get/set для кук и теребить их через ajax.
2.1) Yii при авторизации меняет SID — это нормально, такие моменты нужно учесть, чтобы сохранить возможность авторизироваться, и не сбрасывать новый правильный SID на тот, что в localStorage.
3) в алгоритме какая-то непонятная логика: если кука есть, сохраняем её в localStorage, если нет, только тогда ставим куку из LS. Суть в том, что при сбросе сессии (выключил/включил Web App) сразу будет новый SID, а в LS хранится старый SID. Кука есть = сохранить в LS новый SID, то есть никакого толка вообще. Короче, «else» лишний в коде.
4) ещё если делать для всех ссылок window.location = this.href, то будет выкидывать в Safari для энкоров на странице (href="#someID"), для таких случаев надо переделывать на window.location.hash = this.href.replace('#', '');
В целом, я пришёл к тому, что надо бы сделать со стороны сервера страничку, куда аяксом передавать SID из localStorage: если они совпадают, то вернуть false, если изменился, то вернуть новое значение в зависимости от того, какое из них (кука или localStorage) нужно использовать, и сохранить его в LS. При таком подходе можно сохранить httpOnly=true, и вообще не нужно ничего считывать из кук в JS, плюс получаем возможность контролировать какой именно SID поддерживать и сохранять везде (как раз тот случай, когда SID меняется правомерно, и отследить такие моменты со стороны сервера проще, чем из JS). Но, это задача на следующую неделю уже…
1) запоминание текущего пути — это хорошо, но плохо работает со всем, что идёт не через ссылку (формы, например). В итоге: форму засабмитил, CurrentLocation != StoredLocation — редиректит на StoredLocation, который неправильный… В общем, было бы круто иметь базовый URL Web App (который был при сохранении), но я не знаю, как его получить, поэтому редирекчу на StoredLocation тогда и только тогда, когда CurrentLocation=/ и отличается от StoredLocation (как бы предполагая, но Web App сохраняют с корневой страницы). Если кто знает, как получить URL Web App — напишите!
2) то ли в PHP, то ли в Yii с какого-то момента для сессионных кук форcировали httpOnly=true — это значит, что они больше не видны в document.cookie. Тут варианта два: или в конфигах прописывать httpOnly=false, или делать свой get/set для кук и теребить их через ajax.
2.1) Yii при авторизации меняет SID — это нормально, такие моменты нужно учесть, чтобы сохранить возможность авторизироваться, и не сбрасывать новый правильный SID на тот, что в localStorage.
3) в алгоритме какая-то непонятная логика: если кука есть, сохраняем её в localStorage, если нет, только тогда ставим куку из LS. Суть в том, что при сбросе сессии (выключил/включил Web App) сразу будет новый SID, а в LS хранится старый SID. Кука есть = сохранить в LS новый SID, то есть никакого толка вообще. Короче, «else» лишний в коде.
4) ещё если делать для всех ссылок window.location = this.href, то будет выкидывать в Safari для энкоров на странице (href="#someID"), для таких случаев надо переделывать на window.location.hash = this.href.replace('#', '');
В целом, я пришёл к тому, что надо бы сделать со стороны сервера страничку, куда аяксом передавать SID из localStorage: если они совпадают, то вернуть false, если изменился, то вернуть новое значение в зависимости от того, какое из них (кука или localStorage) нужно использовать, и сохранить его в LS. При таком подходе можно сохранить httpOnly=true, и вообще не нужно ничего считывать из кук в JS, плюс получаем возможность контролировать какой именно SID поддерживать и сохранять везде (как раз тот случай, когда SID меняется правомерно, и отследить такие моменты со стороны сервера проще, чем из JS). Но, это задача на следующую неделю уже…
Sign up to leave a comment.
Отличия в адаптации сайта и AJAX веб-приложения для iOS