Не работает авторизация и/или регистрация на сайте, часть 2
Снова простое решение иногда возникающей проблемы.
Думаю, что нужно по-умолчанию добавить в .htaccess редирект с домена с «www.» на без него т.к. если сайт был сконфигурирован (в конфиге записано) без указания «www», то при заходе пользователем на сайт с префиксом «www.», и, например, авторизации, посылается запрос на домен без «www» (т.к. в JS-массиве роутера запись для урлов аякса указывает на домен без «ввв», которая взята с конфига, естественно) т.е. фактически на другой домен, а политика безопасности браузера не разрешает такой кросс доменный запрос и блокирует его. В итоге для пользователя все выглядит весьма простым образом:
и, как всегда, юзер идет на сайт сообщества и публикует новый топик с вопросом, что после нажатия на кнопку авторизации ничего не происходит, только индикаторы загрузки крутятся без перерыва на обед.
Ему дают стандартный ответ — смотри логи и/или ответ Firebug.
Интересно и то, что может быть обратно пропорциональная ситуация: в конфиге сайт записан с «www», а пользователь открыл сайт без указания устаревшего префикса. И снова аякс не сработает.
Мало уловимый «баг» (если, конечно, его таковым можно вообще назвать) — много частых вопросов.
Поэтому, веб-мастера, которые выращивают ЛС у себя на сайтах, делайте редирект на тот домен, который у вас прописан в конфиге:
А как это сделать — уже писалось ранее:
Итак ЛС желательно размещать на домене без «www», т.к. он уж очень не любит этого — авторизация на сайте будет выполнятся либо на «www» либо на «без www», поэтому пользователи будут периодически слать вам (админу) письма о невозможности входа на сайт или периодического разлогинивания. Будьте бдительны — выключите дедушку «www» сразу.
Пожалуй, самый лучший вариант сделать это посредством модуля mod_rewrite вашего сервера, дописав в конец файла .htaccess, который находится в корне вашего сайта следующие строки:
где САЙТ — имя вашего сайта.
В каталоге модулей для Ливстрит есть плагин который делает тоже самое, но с точки зрения скорости работы (и затраты ресурсов сервера) — это не рационально.
Это кросспост из гида по лс.
UPD: Добавил пример:
UPD2: Код редиректа нужно вставлять сразу после директивы
т.к. в противном случае он не на всех страницах делал корректный редирект
Думаю, что нужно по-умолчанию добавить в .htaccess редирект с домена с «www.» на без него т.к. если сайт был сконфигурирован (в конфиге записано) без указания «www», то при заходе пользователем на сайт с префиксом «www.», и, например, авторизации, посылается запрос на домен без «www» (т.к. в JS-массиве роутера запись для урлов аякса указывает на домен без «ввв», которая взята с конфига, естественно) т.е. фактически на другой домен, а политика безопасности браузера не разрешает такой кросс доменный запрос и блокирует его. В итоге для пользователя все выглядит весьма простым образом:
и, как всегда, юзер идет на сайт сообщества и публикует новый топик с вопросом, что после нажатия на кнопку авторизации ничего не происходит, только индикаторы загрузки крутятся без перерыва на обед.
Ему дают стандартный ответ — смотри логи и/или ответ Firebug.
Интересно и то, что может быть обратно пропорциональная ситуация: в конфиге сайт записан с «www», а пользователь открыл сайт без указания устаревшего префикса. И снова аякс не сработает.
Мало уловимый «баг» (если, конечно, его таковым можно вообще назвать) — много частых вопросов.
Поэтому, веб-мастера, которые выращивают ЛС у себя на сайтах, делайте редирект на тот домен, который у вас прописан в конфиге:
$config['path']['root']['web'] = 'http://site.com';
А как это сделать — уже писалось ранее:
Итак ЛС желательно размещать на домене без «www», т.к. он уж очень не любит этого — авторизация на сайте будет выполнятся либо на «www» либо на «без www», поэтому пользователи будут периодически слать вам (админу) письма о невозможности входа на сайт или периодического разлогинивания. Будьте бдительны — выключите дедушку «www» сразу.
Пожалуй, самый лучший вариант сделать это посредством модуля mod_rewrite вашего сервера, дописав в конец файла .htaccess, который находится в корне вашего сайта следующие строки:
RewriteCond %{HTTP_HOST} ^www.САЙТ.com [NC] RewriteRule ^(.*)$ http://САЙТ.com/$1 [L,R=301]
где САЙТ — имя вашего сайта.
В каталоге модулей для Ливстрит есть плагин который делает тоже самое, но с точки зрения скорости работы (и затраты ресурсов сервера) — это не рационально.
Это кросспост из гида по лс.
UPD: Добавил пример:
AddDefaultCharset UTF-8 Options -Indexes RewriteEngine On #RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule ^(.*)$ ./index.php # Alternative rule #RewriteRule ^(.*)$ /index.php <Files "plugins.dat"> order allow,deny deny from all </Files> <Files ~ "\.tpl$"> Order allow,deny Deny from all </Files> #MOD by PSNet <Files "plugin.xml"> order allow,deny deny from all </Files> RewriteCond %{HTTP_HOST} ^www.livestreetguide.com [NC] RewriteRule ^(.*)$ http://livestreetguide.com/$1 [L,R=301]
UPD2: Код редиректа нужно вставлять сразу после директивы
RewriteEngine On
т.к. в противном случае он не на всех страницах делал корректный редирект
Наша команда seo4usa.net предлагает качественное продвижение англоязычных сайтов. Раскрутите свой сайт на новом рынке!
42 комментария
Решил проблему путем правки classes/modules/user/User.class.php, строка 1251
заменил ее на:
например, если авторизация через gmail с почты vasya.pupkin@gmail.com
в логине есть точка, поэтому дефолтовый паттерн не пропускает его
Я всегда добавляю в паттерн еще и точку
У меня в корне сайта нет файла .htaccess
На денвере нашел .htaccess с кодом
мне нужно подправить этот файл и добавить в корень сайта?
в конфиге прописано
Файл .htaccess почему то не отображается по FTP я его якобы добавил и заработало!
Алсо. А в таком случае ещё стоит учесть один момент. Точка в конце домена — прощай рабочая авторизация. ;)
Странный вы, об «ошибке» я вроде сообщил.
Или вы хотите чтобы я вам пересказал стандарты RFC касательно DNS, URL etc?
Так и быть. Точка в конце доменного имени указывает, что это FQDN. Если точки нет — значит имя относительное. Далее RFC указывает, что хост может быть только fqdn/ip, и больше ничего.
RFC 1034, 3.5 оглашает более подробное правило определения имени хоста, но о точке там ничего нет.
Браузеры позволяют зайти на сайт как с точкой, так и без неё.
Если клиент «откуда-то-там» придёт с таким хостом, и полезет в авторизацию, или ещё там куда — может огрести проблем, если мы не предусмотрим правило.
Как исправить? В nginx я предусмотрел у себя — простой if, в котором если происходит соответствие, клиенту отправляется 301 и редирект на правильное доменное имя. В apache, скорей всего тоже с реврайтами играть. Проверенного правила для апача не скажу, т.к у меня тупо нет где протестировать. А ставить только для этого — как-то не хочу.
Так, например, страницу блогов www.site.by/blogs/ перекидывает на site.by/index.php/,
а страницу блога www.site.by/blog/blogname/ перенаправляет на site.by/index.php/blogname/
Сейчас и с ней проблемы описанные выше.
livestreet.ru/blog/16131.html
Если, кто-то из гуру поможет, буду благодарен:
livestreet.ru/blog/questions/15999.html
Активные плагины: aceAdminPanel, AutoOpenID, Block content, Config Engine, Main preview topic, Static page, SEO, Simple template, Sitemap
С главной страницы Не работает кнопка «Войти». С любой другой страницы работает.
при отключении aceAdminPanel работает.
Естественно пробовал так в .htaccess
только Options -MultiViews, когда Options -Indexes (ошибка 404)не работают подпункты «Новые», «Обсуждаемые»,«Топ».
Хотя в целом и Options -Indexes ставил, одинаково.
далее конфиг локал $config['path']['root']['web'] = 'http://имя.юдомена';
просто конфиг $config['path']['root']['web'] = 'http://'.$_SERVER['HTTP_HOST'];
Имеется ошибка в каком ява скрипте:
На страницах где вход работает и при отключенном aceAdminPanel ее действительно нету.
Какой то имя.домена/templates/cache/ls-theme_street-spirit-master/de4a8a0b46d7797de30dcfc78111431e.js
Так понимаю это какой то кэш шаблона, попробовал удалить, создалось само по новой.
Ошибка в последней строке:
Сейчас конечно погуглю. Но в целом, логически, раз этот файл сам создается ошибка где то в другом месте.
По сути согласен, все можно настроить через конфиг, а у плагинов настройки и так остаются.
у той админки много багов, поэтому если есть возможность отказаться — сделайте это