Ошибка: строки не равны, хотя равны! Подскажите пожалуйста почему?
Всем доброго ... Столкнулся с такой проблемой. Хочу match'ем разбивать uri и затем проверять команды. С латиницей проблем никаких. С кириллицей начинаются проблемы :(
$str[$request:uri]$str2[^taint[uri][/новости]]^if($str eq $str2){
Строки равны
}{
Строки не равны $str2}
Строки с кириллицей всегда "не равны" почему-то, хотя если вводим латиницей - строки равны. При этом визуально (в браузере) строки равны.
Например, для раздела Новости: /новости К парсеру приходит: /%D0%BD%D0%BE%D0%B2%D0%BE%D1%81%D1%82%D0%B8 Чтобы не заменять по таблице или не использовать mod_rewrite (пока просто не знаком с ним) хотел перекодировать с помощью taint, т.е. привести к общему виду. Но похоже на то, что парсер пачкает только непосредственно перед выдачей браузеру :(
Можно ли средствами самого Парсера как-нибудь провести сравнение строк?
Решение сводится к замене человеческого текста на тот, что приходит :) Работает без мод-рерайта через 404. Беспокоит только одно - под UNIX системами строка будет приходить такой же? Т.е. не придётся переписывать ?
$str[$request:uri]$str2[^taint[uri][/%D0%BD%D0%BE%D0%B2%D0%BE%D1%81%D1%82%D0%B8]]^if($str eq $str2){
Строки равны
}{
Строки не равны $str2}
Решение подходит для статичных ссылок, но не для тех, что будут формироваться по данным из бд :( , т.к. из полей формы приходит "беспроцентный UTF". Проход с заменой по таблице - слишком медленное занятие (если будет большое число посетителей).
Спасибо! Я вчера сразу же почитал и попробовал mod_rewrite, но под Win есть какая-то проблема с этим самым преобразованием и в параметры переходят либо отдельные символы, либо вообще ничего, а точнее строка вида ???N?N?? в поле qtail. Чуть ниже я писал об этом. G_Z тоже сталкивался с подобным. Надеюсь, что он нашёл выход и подскажет :) Похоже, что под Unix не должно быть этой проблемы.
З.Ы.: mod_rewrite отличная штука :) Маленькая строчка, а позволила отказаться от обработки через 404 (хотя по-идее тоже самое делает) и избавиться от проблем с формами (не нужно явно указывать кто будет обрабатывать форму).
да, G_Z сталкивался. и по его просьбе я сталкивался. у меня сработал найденный им-же workaround, заключающийся в добавлении одного ключика.
P.S. возможно проблема в чём-либо другом, например в неверно заданных кодировках, и это вылезает когда вы начинаете работать с form. вы всё равно столкнётесь с этой проблемой, только чуть позже.
Везде советуют их проверять. Все файлы в UTF-8. request и response - UTF-8 БД - UTF-8 Короче, говоря - тотальный UTF-8 AddDefaultCharset UTF-8 не помогает.
RewriteRule ^(.*)$ index.html?test=%{REQUEST_URI} [L] строка искажена, но RewriteRule ^(.*)$ index.html?test=%{THE_REQUEST} [L] тут видно нормальную строку, но есть лишние данные :(
В том то и дело, что разницы нет. Проблема такая же как и у G_Z - кириллица в строке приходит в виде ??N????N?? . Ключи просмотрел и все перепробовал :) Ничего не помогает. Пока только одно решение - идти на таран и разбирать THE_REQUEST (будет максимально кроссбраузерно и кроссплатформенно :)
Ответ | редирект на один файл | русские символы в URL
во-первых: вообще вы пишете не правильное правило - оно у вас "зацикливается", независимо от флага [L]. вам нужно отменить обработку правил на сам физический файл:
# отменяем редирект для файлов, содержащих символ подчеркивания
RewriteRule ^_ - [L]# все запросы редиректим на файл _index.html, расположенный в корне
RewriteRule (.*) /_index.html?request=$1[L]
во-вторых: как вам и писал G_Z, чтобы передать не-ASCII символы (к коим относятся и символы русского языка) следует в правилах задать флаг [B]. то есть конечный .htaccess у вас будет содержать примерно следующие строки:
# отменяем редирект для файлов, содержащих символ подчеркивания
RewriteRule ^_ - [L]# все запросы редиректим на файл _index.html, расположенный в корне, и разрешаем использовать русские символы в строке запроса
RewriteRule (.*) /_index.html?request=$1[L,B]
но есть одно "но" - не все Апачи поддерживают данный флаг. вам следует для начала проверить, работает ли он у вашего хостера, чтобы использовать его в дальнейшем.
Доброго ... onlyyours Спасибо! Но ... (чтобы было понятнее) 1. С mod_rewrite столкнулся сегодня ночью :) 2. Прежде, чем задавать любые вопросы на форумах (любых), я читаю и эксперементирую. Когда мозг ломается (не хватка знаний, сложная задача, не выполнимая задача) я начинаю спрашивать. 3. Следствие п. 2 :) Мишин и G_Z'а стёб, в данном случае, не уместен и прошёл мимо. Ибо ещё до вопроса были попытки прописать . 4. До хостера ещё далеко. Сейчас пытаюсь на Дэнвере. Почему? Убого? Есть виртуалка. Стоит FreeBSD. Но там пока разбираюсь с ZFS :) В планах VDS-> выделенный сервер. Ранее никогда ничего не администрировал. Т.е. поток информации сейчас огромный :) Общий план: 4.1. Разработка структуры БД - готово 4.2. Написание кода на Парсере - в разработке 4.3. Установка и тесты на локальной машине через виртуальные машины - частично выполнена установка 4.4. Установка и тесты на реальном VDS. 4.5. Запуск проекта :) 5. Похоже придётся раз и на всегда разобраться с Регэкспом, т.к. условности условностей до меня доходят, как ... Самое главное - что значит зацикливается? Вроде бы L означает, что после проверки правила, мы никуда больше не идём, т.е. не смотрим другие правила рерайта (их и нет). Зачем оно может просматривать снова и снова строку? Там (на сколько я понимаю) прописано, что всё, что с точкой кидать на index.html. Точка у нас в любом случае будет. Видимо где-то не понимаю. 6. Мне проще и понятнее написать (без алгоритмов под рукой) на чистом АСМе с минимумом сис калов написать НоутПад. Абстракция это хорошо, но не всегда. Иногда она излишне абстрактна :) 7. Ключ B не работает, точнее вываливает ошибку (как и писал Denwer (Apache/2.2.4 (Win32))). Его сразу и пробовал. Можно добить виртуалку, но тогда весь план рушится :) Последовательность изменяется. 8. В приведённом мною примере с THE_REQUEST есть преимущество :) Хоть и не красиво, но будет работать, правда с нагрузкой на Парсер. От мод-рерайта нам требуется только первая ступень защиты и передача запроса на index.html (жаль, что нормально только через заголовки). Понятно, что спецификации и т.п., но на дворе уже 21 век :) Пора работать с локальными кодировками без танцев. Заключение :) : Т.к. решения проблемы на сей момент так и не придумано, пошел (как и планировал) разбирать чистый запрос (там пару пробелов отбросить и усё). [b]onlyyours Ваш пример (даже без B) кидает в 500 :(
Чем же я так мог задеть Вас? Лично у меня сложилось впечатление, что ни Вы ни Миша не прочитали всё, что я написал. Возможно сумбурно, возможно много, возможно криво, но написал. Я написал, что прошёл по Вашим стопам (советам), прошерстил Интернет и т.п. После этого Вы и Миша даёте советы, которые бы дал Капитан Очевидность :) Ну если уж так обидел, то извините. Просто в любом случае - проблема осталась проблемой, вопросы остались вопросами :(
[Tue Sep 28 21:08:37 2010] [error] [client 127.0.0.1] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer: [Tue Sep 28 21:08:37 2010] [error] [client 127.0.0.1] Request exceeded the limit of 10 internal redirects due to probable configuration error. Use 'LimitInternalRecursion' to increase the limit if necessary. Use 'LogLevel debug' to get a backtrace., referer:
Из-за ограничения на длину - продолжение в следующем сообщении
Убран слэш перед индексом + первый ключ заменён. Если я правильно понял, то после [L] остальные правила не обрабатываются, что и приводит к ошибкам. $1 всегда равно REQUEST_URI в моих тестах, поэтому поставил THE_REQUEST. Зацикливается, как я понял, - значит пробегает по всему каталогу (по всем файлам), а первая директива позволяет не делать этого, а обращаться сразу же к файлам начинающимся с подчёркивания? так?
RewriteCond %{REQUEST_FILENAME} !-f - будет вызывать рекурсию вот вам 2 варианта развития событий:
1. алгоритм работы: проверяем наличие папки, если нет - обрабатываем редирект, иначе загружаем индексный файл заданной директории.
RewriteEngine On
# проверяем на наличие директории
RewriteCond %{REQUEST_FILENAME} !-d
# если директории нет - редиректим на корневой index.html
RewriteRule ^(.*)/$ /index.html?request=$1/ [L,QSA]# обработчик 404 ошибки
ErrorDocument 404 /404.html
2. здесь проверку на наличие директории придется делать в коде, если вам это понадобится.
RewriteEngine On
# отменяем редирект для файлов, содержащих символ подчеркивания
RewriteRule ^_ - [L]# все запросы редиректим на файл _index.html, расположенный в корне
RewriteRule (.*) /_index.html?request=$1[L,QSA]
заменяйте в блоке, где у вас идут директивы модуля mod_rewrite udp: пожалуйста, разберитесь в том что я вам написал, прежде чем просто копировать к себе
Лично у меня сложилось впечатление, что ни Вы ни Миша не прочитали всё, что я написал.
да, я всё не читал и не пытался во всё вникать.
- зачем вникать, если вы изначально пытаетесь идти неправильным путём (использовать $request:uri, который не перекодируется)?
- сложно вникать в десяток сообщений (ага, редактирование своих сообщений отменили), в которых отсутствуют очевидно необходимые подробности (OS, версия Apache)
- вы не поверите, но ответы капитана очевидности пользуются наибольшим спросом. чтобы взять не думая то, что уже было описано в куче мест, но ещё написано в ответ на вопрос и пользоваться. я, правда, очень стараюсь так не отвечать.
Спасибо! Чувствую, что проблем с кодировкой это всё равно не решит. 1. Попробовал свой кривой способ (через split) - работает. 2. Есть подозрение, что передачу запроса через поле формы нужно делать в контексте сервера, т.е. в httpd.conf. Судя по тому, что я прочитал, строки на входах в контексте сервера и в контексте каталога могут различаться. Завтра ещё немного помучаюсь :)
Ещё раз и подробно + решение проблемы для Win и Denwer 3
ОС: Windows Версии ПО: denwer 3 apache 2.2.4
Задача: Передавать в URL символы кириллицы в формате UTF-8 для разбора и поиска в БД (тэги).
Проблема: $request:uri $env:QUERY_STRING Приходят в формате %xx и сравнение со строкой из БД (и в тексте скрипта) в формате UTF не возможно, т.к. строки будут не равны.
Некоторые варианты решения проблемы: 1. Самый простой способ (но не подходящий для меня из-за используемых версий ПО) - использовать mod_rewrite с ключом B, как предлагают Misha v.3 и G_Z. Ключ B появился в 2.2.7, в моём случае 2.2.4, поэтому выдаётся ошибка и в логах появляется запись, что ключ B не опознан. Передача строки запроса идёт через $form. 2. Кривоватый, но работоспособный. Передача строки запроса идёт также через $form, но в качестве параметра используем %{THE_REQUEST} - "сырой" запрос. Однако строка с этим запросом будет иметь вид: GET /статьи HTTP/1.1, т.е. содержать лишнюю информацию и требует работы топором (split). После чего, получаем табличку cmd. cmd.1 содержит искомую строку запроса в формате UTF.
Т.к. у меня будет всего один обработчик - index.html, то буду ещё и делить на POST и GET, которые можно брать либо из $env:REQUEST_METHOD либо из разбитой строки (индекс 0).
Возможно есть и другие варианты передачи "сырой" строки запроса. Буду рад, если кто-то поделится. Для юникс системы разбиение не потребуется, т.к. там уже будет работать ключ [B], хотя нужно будет ещё посмотреть, как он работает :)
Неа :) Есть проблема - должно быть решение в данных условиях :) Т.к. опять нужно читать и искать "...Как там у нас избы строятся ...", проще и интереснее решить первую задачу.
bug report Чтобы не отвечать отдельно на "ага, редактирование своих сообщений отменили" отвечу здесь (меньше ответов - проще читать :) 1. Редактирование своих сообщений работает не понятно (лично для меня). Было бы логично, если на сообщение ответили, поэтому его замараживаем. НО есть свои сообщения без ответов на них и нет кнопки "Изменить". Думал, дата влияет, ан нет. В некоторых старых сообщениях есть таки заветная кнопочка "Изменить". 2. Если есть возможность, то посмотрите содержимое БД вот по этому сообщению
Там я написал
ключ [B]
без экранирования тэгами code, поэтому сообщение обрезается при выводе. Т.е. воспринимается, как открытый и не закрытый тэг и сообщение ломается, но в БД лежит целёхонькое. Увидел и понял это сегодня, т.к. опять обрезанным выдалось сообщение выше, но успел исправить.
Это конечно не баг репорт, но желательно что-то с этим сделать :)
Спасибо Вам, Добрый человек :) !!! Я даже смотрел в эту сторону. Иногда лучше не думать, а пробовать :)
Тут встаёт ещё один вопрос :) Что быстрее? Откинуть split'oм или перекодировать внутренней функцией? mod_rewrite будет использоваться, просто планировался к изучению немного позже, но получилось вот так.
А решение отличное, особенно, если mod_rewrite не планируется использовать.
уважаемый Petr_04, вы вообще понимаете что несете и пишете?
в вашем .htaccess 3 ошибки как минимум: 1. обращение к корню и обработчик 404 ошибки у вас ссылаются на один файл. 2. зачем вы набубенили 2 проверки, сначала на наличие директории, затем на наличие файла - это понятно только для высших и неземных цивилизаций. и это будет являться последствием 3 ошибки, написанной ниже 3. при обращении к директории (если она существует): а) у вас в любом случае появятся экранированные русские символы б) даже при существовании этой папки и индексного файла в ней, апач криво выдаст содержимое директории (независимо от того, включена ли у вас опция Options -Indexes). если у вас не будут существовать директории как "на всякий случай", то на кой вы сделали 2 первых директивы для проверки?
зачем вы написали "лишние" директивы <IfModule> для проверки на наличие модуля mod_rewrite - тоже не совсем понятно. Без этого модуля у вас один фиг сайт не будет нормально функционировать, а точней вообще не будет.
небольшой деклеймер - слова, написаные мной ниже не претендуют на истину в последней инстанции, это лишь мои наблюдения и выводы. я считаю, что использование русских символов на данный момент является крайне безобразным, так как строка запроса будет состоять из 2 языков: на половину английской и на половину русской (а_тут_мы_заговорили_по-русски). предполагаю, что вы загорелись этой бессмысленой идеей увидев ее на Википедии. еще такая мелочь - побезаботьтесь о своих пользователях, которым придется переключать клавиатуру, когда они будут набирать ваш адрес. благодарю за внимание.
Прежде чем пользовать этот способ, разберитесь, какие могут быть проблемы. Суть проблем: разные браузеры по-разному кодируют url при отправке запроса. Например, если вбить руками ссылку тест в адресную строку, то IE отдаст в win-1251, а Chrome в utf-8. А т.к. в парсере всё считается за utf (в вашем примере), то будут фатальные ошибки при работе с query строковыми методами (match, split и т.д.).
В части url до /? этих проблем не будет, как ни странно. (тест/) всё ок.
Поэтому, все ссылки на сайте советую формировать таким образом, чтобы любые query-параметры были заэскейплены (taint[uri]).
split очень быстрый метод.
mod_rewrite всё равно придётся использовать, если хотите иметь один обработчик на весь сайт (index.html в вашем примере).
Огромное спасибо за обстоятельное и развёрнутое сообщение! Без всякой иронии! Вы немного недопоняли мою задачу. А у меня не хватает знаний, чтобы чётко прописать правила. Просто так работает, как мне нужно :) Сразу же отвечу про википедию и кириллицу - нет. Я прочитал про ЧПУ в Ководстве и видел на нескольких ресурсах реализацию ЧПУ+кириллица, но она там криво реализована (расписывать не буду, а то много там).
Ещё уточню структуру: / index.html /css /js /images Всё! Больше ничего не будет. Все, абсолютно ВСЕ запросы идут на index.html. В подкаталогах не будет индексов. Я, наверное, ещё и 403 повешу на index.html :) , чтобы совсем весело было некоторым (я отдельных будущих посетителей). Правила с !-f и !-d я примерно понимаю (если файл не существует, то применить правило и с каталогом тоже самое), что мне и нужно. Стили слетают и т.п., если не использовать эти ключи совместно (ещё раз позже проверю).
Уже не помню, но натыкался на то, что правило в определённых случаях (символ & дописать по-моему) не срабатывает и выдаётся 404 ошибка. Тут преимущество mod_rewrite даёт о себе знать, т.к. в строке с THE_REQUEST вся часть, включая &, отбросится. И это правильно, ибо нефиг писать в строке запроса всякую дрянь :)
<IfModule ... Тут у меня жёсткое не понимание :) Спасибо, уберу.
...на половину английской и на половину русской Не вижу никаких неудобств, скорее наоборот. Вводить руками никто и ничего не будет. А если захочет, то пожалуйста. Строка запроса будет строиться, как и рекомендуется - логично и красиво. Например, xxx.com/tags/камень. Можно удалить слово камень и получим список наиболее популярных тэгов по определённым параметрам. Можно удалить камень и руками прописать тэг и он обработается, а не выдаст 404 или "Извините, что-то мы такого у себя не находим".
Основную озабоченность на данный момент вызывает моё понимание функционирования mod_rewrite и правил :)
^.*$ - начало строки, далее любое кол-во любых символов, конец строки. Т.е. весь запрос любого вида мы преобразуем. Дальше строка, которую приставляем к www.xxx.com/ и флаг L - пройтись по строке один раз.
Если я правильно понял и написал это правило, то всё отлично :)
Ещё раз спасибо за участие в проблеме неразумных (я про себя) :)
Есть проблема - должно быть решение в данных условиях :)
странный у вас подход. ведь на хостинге (*nix) все будет нормально работать, сл-но все эти извращения нафиг не нужны и будут лишь затруднять понимание и жрать память/время.
1. редактировать можно только свои сообщения и только до тех пор, пока на них нет ответа. указанное вами сообщение не ваше, а какого-то анонима, который ввёл такое-же имя :) [имя серенькое, см. FAQ по форуму] 2. да, баг. как-нить надо будет поправить.
Стили слетают и т.п., если не использовать эти ключи совместно вы совершенно правы. написал про это поторопившись. у меня несколько иной алгоритм для изображений/стилей/скриптов: я отменяю редиректы для заданных папок и определенных типов файлов. вы не рассматриваете случаи, когда вам может понадобится отобразить страницу, которая находится в директории, а не в бд?
в любом случае у вас 404 ошибка ссылается на тоже самое, на что будет ссылаться главная страница сайта.
...на половину английской и на половину русской Не вижу никаких неудобств, скорее наоборот. дело ваше.
Спасибо! IE отдаст в win-1251, а Chrome в utf-8 Как-то не подумал об этом. Проверил и в результате, если после ? дописать любой символ кириллицы (хоть название переменной, хоть значение) вываливается 500. В логе апача: (22)Invalid argument: utf8 to ucs2 conversion failed on this string: REDIRECT_QUERY_STRING=\xf2\xe5\xf1\xf2
Переменные в явном виде через строку запроса передаваться не будут, точнее будут в виде /xxx/xxx/xxx/xxx, поэтому этой проблемы и не заметил бы. Теперь буду знать и тем более ничего подобного через URL не буду передавать :)
split очень быстрый метод. Я так и думал. По-идее, он блоками должен оперировать, а перекодирование через байты или группы байт.
Ещё раз спасибо. Пойду дальше писать, а то 2 дня с одной проблемой убил :)
Спасибо. Значит более или менее правильно правила написал.
вы не рассматриваете случаи, когда вам может понадобится отобразить страницу, которая находится в директории Всё пока только на уровне идей и фантазий, поэтому сложно сказать. В планах - всё через index.html. На бумажке прикинул варианты - вроде бы пока всё должно получиться :)
в любом случае у вас 404 ошибка ссылается на тоже самое, на что будет ссылаться главная страница сайта
Тут ситуация схожа с кириллицей в URLах. Просто пользователь никогда не увидит 404 ошибки :) Для того, кто придёт с другого сайта будет выведена главная страница и может быть мы сможем заинтересовать его и он останется. А если бы он увидел "не найдено" или "не существует" (особенно, если с поисковика пришёл), да ещё и пустую страницу (навигация и сообщение), то 99%, что он просто закроект окно/вкладку и пойдёт дальше искать, т.е. мы его (пользователя) потеряли :)
Есть одна маленькая неприятность при этом: xxx.com/articles/1234 - даже, если путь не существует (ошибка в 1 символе) и пользователю показана главная страница, то в URLе эта строка так и останется, что может привести в некоторое замешательство.
Короче говоря, пытаюсь сделать работу пользователя с сайтом максимально мягкой и прозрачной :)
сообщение не ваше, а какого-то анонима, который ввёл такое-же имя :) [имя серенькое, см. FAQ по форуму] Честно говоря, не заметил, что тощее и серое имя :) Просто сидел под 3-мя браузерами пока тестировал (FF, Chrome, IE6) и мог не с того окна написать. Жаль, что это не баг, а фича :) Получается, что кто угодно может писать от вашего имени или имени PAFa. Я бы всё же это к багам или большому при большому неудобству отнёс :) Хотя для диверсий это удобно :)
Всем доброго ... Для входа на сайт использую отличнейший класс auth от Misha v.3 (огромное ему спасибо) :) Вход осуществляется на отдельной странице (дизайн не позволяет разместить вместе с другими элементами). Чтобы вход можно было осуществить с любой страницы и вернуться назад родил 2 варианта: 1. Вариант Добавил в форму $env:HTTP_REFERER
FF и Хром нормально воспринимают адреса с кирилицей и возвращают назад, но вот Ослик выдаёт либо квадратики, либо крякозябры (как при просмотре UTF строк в 1251) либо вообще непонятно что. Танцы с taint/untaint результатов не дают :(
2. Вариант Вводим переменную, которой присваиваем путь при обращении к любым страницам, кроме логин/логаута. Всё вроде бы хорошо, пока не заходим на страницу логина. Переменная почему-то обнуляется :( Присвоение стоит только в одном месте.
Как видно из кода, присвоение идёт всего в одном месте и при переходе на страницу /login не должна изменяться $ref_comands, но она почему-то обнуляется :(
Подскажите неразумному, что делаю не так и куда двигаться дальше :)
Заранее благодарю!
3. Вариант Сейчас посмотрю, как там модальными окнами делают вход. Вроде бы адрес при этом остаётся темже и тогда рефреш с пустой строкой обновит ту же страницу.
Но вот проблемы с Вариантом 2 что-то не дают покоя :)
З.Ы.: refresh и location ведут себя одинаково, т.е. проблема и там и там.
G_Z с ключем В есть/были проблемы. До 2.2.12 был баг, когда не все символы перекодировались. Встречал и свежие записи с недовольством (англ у меня слабоват, поэтому не опишу точно и адреса не сохранил). На форумах некоторых буржуйских хостеров попадались вопросы про ключ В и хостеры настоятельно НЕ рекомендовали его использовать, хотя это возможно сейчас и не актуально, но меня заставляет задуматься :)
... а не плодить еще одну ветку в безмерно разросшемся треде.
По сути вопроса. Понять, что вы пытаетесь делать, и какой при этом руководствуетесь логикой, почти невозможно поэтому опишу на пальцах простой алгоритм.
1. Если к нам пришел незалогиненый пользователь, то выводим ему на любой странице форму для логина с экшном на какой-нибудь /login. При этом никаких рефереров в поле не запихиваем. 2. Если нам постят форму на /login ("пост формы" лучше проверять по наличию в form какого-нибудь стандартного поля, например "dosend", ибо нам абсолютно все равно каким методом пришла форма на самом деле), то пробуем залогинить юзера. Если все прошло успешно, то редиректим пользователя на страницу из HTTP_REFERER, но при двух условиях: во-первых пришол он к нам с нашего домена (регуляркой проверить не сложно), во-вторых пришел не со страницы /login. Если одно из условий не выполняется, то просто редиректим в корень сайта. 3. Если пользователь залогинен и пришел на /login, то можем спокойно его отридеректить все в тот же корень.
p.s. Настоятельно рекомендую перестать "играться" с taint'ами - Парсер сам прекрасно знает, что надо делать в 99% случаев. Т.е. в вашем коде ^untaint[html] вобще не имеет смысла - это то преобразование, которое парсер сделает автоматически, а про ^taint[as-is][$form:return_url] надо забыть как про страшный сон - вы просто отключили весь защитный механизм, а это может привести к плохим последствиям.
1. Про таинт/унтаинт понял. Просто дошел до ручки и начал с ними играться :) 2. Дизайн не позволяет держать постоянно в каком-либо удобном месте (шапка, боксик слева/справа и как можно выше) форму логина/логаута, поэтому есть в главном меню ссылка "ВХОД" ведущая на страницу xxx.com/login. Пользователь(зарегистрированный допустим) ходит бродит и решает оставить комментарий, но для этого ему нужно войти. Чтобы не заставлять его снова топать (искать) на ту страницу, с которой он перешёл на login я должен сделать авторедирект после удачного логина. 3. Зачем проверять HTTP_REFERER? Все формы будут защищены от спама (что-нить вроде капчи). От ботов буду отбиваться средствами ОС и/или Апача. 4. ^untaint[html] - ну это вопрос больше к Мише. Я ему, как отцу родному, доверяю :) Раз он так сделал, значит была необходимость :)
Меня больше беспокоит обнуление переменной (пустой становится), хотя пустой она не должна быть.
И ещё, большинство непонятностей в моём коде/способах вытекают из этой длинной ветки :)
Если пользователь хочет ввести комментарий и незалогинен, то просто выведите поля для авторизации в саму форму коментирования.
Меня больше беспокоит обнуление переменной (пустой становится), хотя пустой она не должна быть.
Вы приводите какие-то совсем несвязанные куски кода, но исходя из: Вводим переменную, которой присваиваем путь при обращении к любым страницам, кроме логин/логаута. Всё вроде бы хорошо, пока не заходим на страницу логина. Складывается ощущение, что вы сами переменную и не присваиваете. Или вы рассчитываете, что состояние перменной сохранится каким-то магическим образом между вызовами разных страниц?
p.s. Про таинт можете не верить, но лучше разобраться с этим механизмом, а не слепо доверять авторитетам. Общее правило - нигде не ставить taint/untaint, пока нет четкого понимания, что без этого оператора не обойтись.
p.p.s. И ещё, большинство непонятностей в моём коде/способах вытекают из этой длинной ветки :) Они никак из ветки не вытекают. У вас сейчас совершенно отдельная проблема, которая связана с попыткой придумать какие-то очень сложные алгоритмы вместо того, чтобы разобраться с тем как устроен веб. :)
Хм... видимо я не правильно понимал, как работает Парсер :)
Спасибо, в голове проясняется (я надеюсь). 1. поток (Парсера) создаётся каждый раз для обработки каждого запроса? и по выполнению завершается? поэтому мы теряем все переменные? Если так, то её по-идее нужно хранить тогда либо в файле, либо в БД :( да ещё и с данными пользователя (сессия). 2. С логином не так просто, хотя и просто. Мне нужно с любой страницы. Понятно, что можно было бы в определённых местах выводить, но это снижает удобство для пользователя. 3. Я и не говорю - верю/не верю. Я знал, что такое таинт/унтаинт. Посмотрел форму. Пока ничего предосудительного не заметил :) Было бы замечательно, если бы Михаил прокомментировал этот момент.
Ещё раз спасибо! Пойду модальные окна прикручивать.
Дополнение: Проблемы с редиректом возникают опять из-за использования не латинских символов xxx.com/tags/что-то
Т.к. jQuery в любом случае будет интенсивно использоваться, то попробовал сделать логин с помощью модальных окон. Всё очень легко делается и работает во всех браузерах.
9 IE хоть и обещают с поддержкой CSS3, но текущая бета работает точно также, как и IE6. Нужно будет делать проверку браузера и вывешивать сообщение: "Вы используете кривой барузер. Пожалуйста установите нормальный - ...." :)))))
С проверкой на POST и GET я, похоже, погорячился. Особой необходимости в этом нет. На первый взгляд есть, но редирект + снова проверка = никакого выигрыша. Как результат, на сей момент убрал эту проверку :)
Целостной картины у меня пока нет, поэтому и "глупые вопросы и решения". Всё будет меняться по мере реализации.