Комментарии 16
Заметил, что первый пример от Mike Stenhouse давит Ctrl/Shift + Click по ссылке. Правильно ли лишать пользователя привычных действий, тем более, что не дают открыть ссылки, которые и будут в букмарке.
0
я тоже догодался использовать window.location.hash, жалко что только сейчас нашёл пост об этом :-)
но может возникнуть проблема следующего характера: на страницу можно попасть только после авторизации (сейчас я не рассматриваю возможность опции "запомнить меня на 14 дней", когда авторизация делается фоном). то есть, как только я вбил в адрес "аджаксовый линк", меня редиректят на логин - где хэш теряется из адреса... и после авторизации меня отправляют на линк без "#...". я не нашёл выход. если только в куки сохранять и после редиректа доставать... есть соображания по этому поводу?
но может возникнуть проблема следующего характера: на страницу можно попасть только после авторизации (сейчас я не рассматриваю возможность опции "запомнить меня на 14 дней", когда авторизация делается фоном). то есть, как только я вбил в адрес "аджаксовый линк", меня редиректят на логин - где хэш теряется из адреса... и после авторизации меня отправляют на линк без "#...". я не нашёл выход. если только в куки сохранять и после редиректа доставать... есть соображания по этому поводу?
0
хм, ну можно при авторизации использовать скрытое поле формы
и после ajax-авторизации открывать нужную страницу (выставляя на сервере значение javascript-переменной в нужное значение). Я правильно понял проблему?
Имхо, cookie тоже хороши, но они чуток сужают область совместимости
<input type="hidden" name="ajax_bookmark" value="document.location.hash"/>
и после ajax-авторизации открывать нужную страницу (выставляя на сервере значение javascript-переменной в нужное значение). Я правильно понял проблему?
Имхо, cookie тоже хороши, но они чуток сужают область совместимости
0
да, вполне. но вот только редирект я делаю через header и пользователь попадает уже на другую страницу, где линк потерян.
надо пересмотреть редирект может...
надо пересмотреть редирект может...
0
как вариант: добавлять при редиректе переменную с нужным значением. Главное, чтобы этот якорь (anchor), во-первых, попадал на сервер (через форму, например), а во-вторых, попадал с сервера на клиент. Если нужно его перекидывать между страницами на сервере — это всегда можно сделать, и сделать просто.
Просто cookie еще и уязвимы прилично. Т.е. если у пользователя ее украдут, то может быть вариант с несанкционированным доступом (понятно, что лучше всегда на сервере права дополнительно проверять, чем просто по cookie куда-то переходить, но безопасность лишней оказаться не может :)
Просто cookie еще и уязвимы прилично. Т.е. если у пользователя ее украдут, то может быть вариант с несанкционированным доступом (понятно, что лучше всегда на сервере права дополнительно проверять, чем просто по cookie куда-то переходить, но безопасность лишней оказаться не может :)
0
про куки полностью согласен, безопастность важнее.
я про другое, в куки сохранить линк с хэшем, который хотел пользователь открыть, а потом достать его.
у не нашёл в массиве $_SERVER (пхп) элемент, который бы кеш этот видел, получается, что это идёт на уровне браузера только.
кстати, ФФ нормально работает с этим и Опера (могу ошибаться, точно не помню) - при редиректе на страницу авторизации, хеш остаётся, следовательно, последующий редирект будет успешным, пользователь попадёт куда он хотел и аджакс ему будет. а вот ИЕ, ослина, хавает хэш :-(
я про другое, в куки сохранить линк с хэшем, который хотел пользователь открыть, а потом достать его.
у не нашёл в массиве $_SERVER (пхп) элемент, который бы кеш этот видел, получается, что это идёт на уровне браузера только.
кстати, ФФ нормально работает с этим и Опера (могу ошибаться, точно не помню) - при редиректе на страницу авторизации, хеш остаётся, следовательно, последующий редирект будет успешным, пользователь попадёт куда он хотел и аджакс ему будет. а вот ИЕ, ослина, хавает хэш :-(
0
хеш-то понятно только на уровне клиента. Я почему про форму и написал — чтобы он на сервер попадал. А дальше — делаем, что хотим. Т.е. дальнейший редирект после авторизации я бы делал уже используя внутренний вызов 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) все радуются?
я правильно все описал?
0
вышли зачётку :) я всё понял ещё в начале.
но я всё равно склоняюсь к мысли перенаправления пользователя. так визуальнее понятнее, что происходит. да и авторизация может быть сложная (сам процесс). я кстати, что-то не встречал такого способа в сети, неужели никто не может это организовать? думаю, тут сложнее всё.
но я всё равно склоняюсь к мысли перенаправления пользователя. так визуальнее понятнее, что происходит. да и авторизация может быть сложная (сам процесс). я кстати, что-то не встречал такого способа в сети, неужели никто не может это организовать? думаю, тут сложнее всё.
0
Как вариант могу предложить не использовать специальный URL для страницы авторизации. Вместо отдельной страницы можно выводить форму авторизации (если юзер не авторизован) по тому же самому урлу, что и контент. А если авторизован - то выводить контент. При этом URL[hash] будет доступен в рамках этой же страницы, и вы сможете отправить запрос (POST/GET) на необходимый адрес с учетом window.location.hash
0
Если сайт хочет предоставить доступ к своим ресурсам через закладки, дать возможность пользователям обмениваться 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-кликами... и якоря используются по прямому назначению - для ссылкок на конкретные разделы (комментарии) внутри страницы.
+1
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практический AJAX: что делать с закладками