Комментарии 16
Заметил, что первый пример от Mike Stenhouse давит Ctrl/Shift + Click по ссылке. Правильно ли лишать пользователя привычных действий, тем более, что не дают открыть ссылки, которые и будут в букмарке.
я тоже догодался использовать window.location.hash, жалко что только сейчас нашёл пост об этом :-)
но может возникнуть проблема следующего характера: на страницу можно попасть только после авторизации (сейчас я не рассматриваю возможность опции "запомнить меня на 14 дней", когда авторизация делается фоном). то есть, как только я вбил в адрес "аджаксовый линк", меня редиректят на логин - где хэш теряется из адреса... и после авторизации меня отправляют на линк без "#...". я не нашёл выход. если только в куки сохранять и после редиректа доставать... есть соображания по этому поводу?
но может возникнуть проблема следующего характера: на страницу можно попасть только после авторизации (сейчас я не рассматриваю возможность опции "запомнить меня на 14 дней", когда авторизация делается фоном). то есть, как только я вбил в адрес "аджаксовый линк", меня редиректят на логин - где хэш теряется из адреса... и после авторизации меня отправляют на линк без "#...". я не нашёл выход. если только в куки сохранять и после редиректа доставать... есть соображания по этому поводу?
хм, ну можно при авторизации использовать скрытое поле формы
и после ajax-авторизации открывать нужную страницу (выставляя на сервере значение javascript-переменной в нужное значение). Я правильно понял проблему?
Имхо, cookie тоже хороши, но они чуток сужают область совместимости
<input type="hidden" name="ajax_bookmark" value="document.location.hash"/>и после ajax-авторизации открывать нужную страницу (выставляя на сервере значение javascript-переменной в нужное значение). Я правильно понял проблему?
Имхо, cookie тоже хороши, но они чуток сужают область совместимости
да, вполне. но вот только редирект я делаю через header и пользователь попадает уже на другую страницу, где линк потерян.
надо пересмотреть редирект может...
надо пересмотреть редирект может...
как вариант: добавлять при редиректе переменную с нужным значением. Главное, чтобы этот якорь (anchor), во-первых, попадал на сервер (через форму, например), а во-вторых, попадал с сервера на клиент. Если нужно его перекидывать между страницами на сервере — это всегда можно сделать, и сделать просто.
Просто cookie еще и уязвимы прилично. Т.е. если у пользователя ее украдут, то может быть вариант с несанкционированным доступом (понятно, что лучше всегда на сервере права дополнительно проверять, чем просто по cookie куда-то переходить, но безопасность лишней оказаться не может :)
Просто cookie еще и уязвимы прилично. Т.е. если у пользователя ее украдут, то может быть вариант с несанкционированным доступом (понятно, что лучше всегда на сервере права дополнительно проверять, чем просто по cookie куда-то переходить, но безопасность лишней оказаться не может :)
про куки полностью согласен, безопастность важнее.
я про другое, в куки сохранить линк с хэшем, который хотел пользователь открыть, а потом достать его.
у не нашёл в массиве $_SERVER (пхп) элемент, который бы кеш этот видел, получается, что это идёт на уровне браузера только.
кстати, ФФ нормально работает с этим и Опера (могу ошибаться, точно не помню) - при редиректе на страницу авторизации, хеш остаётся, следовательно, последующий редирект будет успешным, пользователь попадёт куда он хотел и аджакс ему будет. а вот ИЕ, ослина, хавает хэш :-(
я про другое, в куки сохранить линк с хэшем, который хотел пользователь открыть, а потом достать его.
у не нашёл в массиве $_SERVER (пхп) элемент, который бы кеш этот видел, получается, что это идёт на уровне браузера только.
кстати, ФФ нормально работает с этим и Опера (могу ошибаться, точно не помню) - при редиректе на страницу авторизации, хеш остаётся, следовательно, последующий редирект будет успешным, пользователь попадёт куда он хотел и аджакс ему будет. а вот ИЕ, ослина, хавает хэш :-(
хеш-то понятно только на уровне клиента. Я почему про форму и написал — чтобы он на сервер попадал. А дальше — делаем, что хотим. Т.е. дальнейший редирект после авторизации я бы делал уже используя внутренний вызов AJAX (при загрузке страницы прописать загрузку нужного компонента), а хеш просто не трогать (по идее, он должен выставиться после загрузки этого самого компонента).
т.е. схема такая:
(1) клиент отправляет запрос на страницу (с хешом, хеш не отправляется на сервер) серверу
->
(2) сервер понимает, что пользователь не авторизован, и выдает ему страницу с формой авторизации
->
(3) JS (на клиенте) «понимает», что это страница авторизации, и записывает в спрятанное поле формы значение
->
(4) пользователь отправляет форму со всеми данными на сервер
->
(5) сервер получает данные, авторизовывает пользователя, смотрит значение скрытого поля и редиректит на нужную страницу (с параметром ajax_onload=HASH)
->
(6) сервер грузит страницу, на которую средиректили, и добавляет в код страницы загрузку нужного компонента (значение переменной ajax_onload)
->
(7) JS на клиенте после загрузки страницы грузит этот компонент и меняет document.location.hash на нужный
->
(THE END) все радуются?
я правильно все описал?
т.е. схема такая:
(1) клиент отправляет запрос на страницу (с хешом, хеш не отправляется на сервер) серверу
->
(2) сервер понимает, что пользователь не авторизован, и выдает ему страницу с формой авторизации
->
(3) JS (на клиенте) «понимает», что это страница авторизации, и записывает в спрятанное поле формы значение
document.location.hash->
(4) пользователь отправляет форму со всеми данными на сервер
->
(5) сервер получает данные, авторизовывает пользователя, смотрит значение скрытого поля и редиректит на нужную страницу (с параметром ajax_onload=HASH)
->
(6) сервер грузит страницу, на которую средиректили, и добавляет в код страницы загрузку нужного компонента (значение переменной ajax_onload)
->
(7) JS на клиенте после загрузки страницы грузит этот компонент и меняет document.location.hash на нужный
->
(THE END) все радуются?
я правильно все описал?
вышли зачётку :) я всё понял ещё в начале.
но я всё равно склоняюсь к мысли перенаправления пользователя. так визуальнее понятнее, что происходит. да и авторизация может быть сложная (сам процесс). я кстати, что-то не встречал такого способа в сети, неужели никто не может это организовать? думаю, тут сложнее всё.
но я всё равно склоняюсь к мысли перенаправления пользователя. так визуальнее понятнее, что происходит. да и авторизация может быть сложная (сам процесс). я кстати, что-то не встречал такого способа в сети, неужели никто не может это организовать? думаю, тут сложнее всё.
Как вариант могу предложить не использовать специальный URL для страницы авторизации. Вместо отдельной страницы можно выводить форму авторизации (если юзер не авторизован) по тому же самому урлу, что и контент. А если авторизован - то выводить контент. При этом URL[hash] будет доступен в рамках этой же страницы, и вы сможете отправить запрос (POST/GET) на необходимый адрес с учетом window.location.hash
Если сайт хочет предоставить доступ к своим ресурсам через закладки, дать возможность пользователям обмениваться url ведущими на конкретные ресурсы - значит он должен предоставить способ загрузить любой ресурс методом GET. Если он хочет, чтобы поисковики находили и индексировали эти ресурсы, значит он должен для этого использовать url без всяких якорей (ведь якорь считается ссылкой на раздел внутри текущей страницы, и поисковики врядли различают url отличающиеся только якорем).
Имея такие url без якорей для каждого ресурса, нужно все ссылки на странице задавать через эти url (в href). А для добавления AJAX вешать на эти ссылки дополнительно к href перехват onClick и выполнение AJAX с добавлением к текущей url якоря (как описано в статье) вместо перехода по url указанной в href.
Что мы имеем в результате. Роботы поисковиков (и браузеры без javascript) будут иметь возможность работать с сайтом, получая доступ ко всем ресурсам по уникальным url без якорей. Браузеры с javascript будут работать с сайтом через одну url (для каждой группы вертикальных ссылок) плюс якоря. Эти ссылки можно будет помещать в закладки и посылать другим пользователям - у которых тоже есть поддержка javascript. При этом, благодаря наличию у каждой ссылки обычного href без якорей и javascript, с этими ссылками должны работать все варианты их использования: открыть в новом окне, скопировать url в буфер обмена, Ctrl/Shift+click, etc.
Но, в принципе, есть в этом всём что-то нездоровое. Фактически этот подход ведёт к поддержке двух версий сайта - у одной навигация через href и без якорей, у другой через javascript и якоря. Плюс есть такой нюанс, что гугл может решить что его дурят, и забанить сайт (ведь юзер кликая по ссылкам на этом сайте будет попадать не туда, куда гугл).
С моей точки зрения гораздо правильнее решать описанную в статье проблему принципиально иначе: не создавая её вообще! Не нужно совать AJAX во все дырки, нужно понимать, где его стоит использовать, а где - нет. Неплохой пример - сам хабр. И AJAX есть, и никаких проблем с поисковиками, закладками, Ctrl/Shift-кликами... и якоря используются по прямому назначению - для ссылкок на конкретные разделы (комментарии) внутри страницы.
Имея такие url без якорей для каждого ресурса, нужно все ссылки на странице задавать через эти url (в href). А для добавления AJAX вешать на эти ссылки дополнительно к href перехват onClick и выполнение AJAX с добавлением к текущей url якоря (как описано в статье) вместо перехода по url указанной в href.
Что мы имеем в результате. Роботы поисковиков (и браузеры без javascript) будут иметь возможность работать с сайтом, получая доступ ко всем ресурсам по уникальным url без якорей. Браузеры с javascript будут работать с сайтом через одну url (для каждой группы вертикальных ссылок) плюс якоря. Эти ссылки можно будет помещать в закладки и посылать другим пользователям - у которых тоже есть поддержка javascript. При этом, благодаря наличию у каждой ссылки обычного href без якорей и javascript, с этими ссылками должны работать все варианты их использования: открыть в новом окне, скопировать url в буфер обмена, Ctrl/Shift+click, etc.
Но, в принципе, есть в этом всём что-то нездоровое. Фактически этот подход ведёт к поддержке двух версий сайта - у одной навигация через href и без якорей, у другой через javascript и якоря. Плюс есть такой нюанс, что гугл может решить что его дурят, и забанить сайт (ведь юзер кликая по ссылкам на этом сайте будет попадать не туда, куда гугл).
С моей точки зрения гораздо правильнее решать описанную в статье проблему принципиально иначе: не создавая её вообще! Не нужно совать AJAX во все дырки, нужно понимать, где его стоит использовать, а где - нет. Неплохой пример - сам хабр. И AJAX есть, и никаких проблем с поисковиками, закладками, Ctrl/Shift-кликами... и якоря используются по прямому назначению - для ссылкок на конкретные разделы (комментарии) внутри страницы.
описанный подход (хотя его использование я считаю спорным) можно посмотреть здесь.
Я согласен, что правильная работа с AJAX ведет к двойному программированию, но, имхо, это плата за пользовательское удобство
Я согласен, что правильная работа с AJAX ведет к двойному программированию, но, имхо, это плата за пользовательское удобство
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практический AJAX: что делать с закладками