Ну, если страницы идут именно вида /?1234 - делаем так:
1. Заставляем индексный файл обрабатываться из PHP (переименовываем в index.php или добавляем нужный хандлер)
2. В индексном файле делаем проверку, какую душе угодно, например:
if (!preg_match("/^\/index\.php|\/$/", $_SERVER['REQUEST_URI'])) { header("HTTP/1.1 404 Not Found"); echo "Вы нетуда попали"; // HTML-код сообщения об ошибке} else { echo "Привет"; //Отдаем нормальную страницу}
Что тут нужно понимать: в $_SERVER['REQUEST_URI'] лежит строка с запрошенным у сервера документом. На регулярных выражениях мы ее проверяем на допустимость. В данном случае мы отдаем 404, если только файл не запросили как '/index.php' или как '/'. Т.е. запрос вида 'index.php?var=val' будет считаться некорректным и получит 404.
Это самый простой вариант.
Спасибо всем, я "морально удовлетворен". А то уж испугался, что и вправду что-то серьезное пропустил. Жаль только, что возмутитель моего спокойствия не появился. Ну да ладно, вроде и так все уяснили.
Зачем нужно - дело второе =)
Там шла речь о том, что технически возможно хранить в коннект.пхп
$connect = mysql_pconnect('localhost', 'user', 'password');
вместо "password" некий хеш от "password". При этом с возможностью нормально подключиться.
Нужно, например, на случай, если вдруг неправильно настроили сервер и файл подключения (самая образцево-дурацкая ситуация - это .inc) отдался кому-то в плейнтексте. Если там незашифрованный пароль - наиблее предсказуемое развитие ситуации - находим phpMyadmin, лезем туда и грохаем все нафиг.
Вопрос, собсно, обращаю к тем личностям, которые говорили, что "хранение паролей в зашифрованном виде - это азы", в том числе паролей к БД. Интересует решение для самого обыкновенного никс-хостинга, с PHP, MySQL и более безникому.
Создал тему Хранение хеша паролей к БД. Предлагаю все, что не относится к случаю DM и относится к обозначенной проблеме с паролями, писать туда. Т.к. следить за двумя топиками в одной ветке (причем, топик про ДМ мне более неинтересен) несколько напряжно.
Господа, а не пора ли тему закрыть? Топикстартер забанен, разработчик webcat тут видимо больше не появится. И в чем смысл дальше драться, пытаясь выдать за факты информацию, в любом случае поступившую от заинтересованных сторон? Можно каждому для себя сделать выводы и успокоиться. Я вот, например, уже сделал.
А тему про хранение паролей БД в хеше можно выделить в отдельную - действительно интересный вопрос.
Конкретно против этих помогает проверка юзер-агента.
if (!empty($_SERVER['HTTP_USER_AGENT'])) {// отправляем форму}
Ну, от меня отстали через 3 дня, когда я, собсно, сделал такую проверку. До этого нагадили в комментах 4 мега.
Какой ЗоЗПП? Вы че? Детский сад...
Это точно о вас?
А вам не кажется, что об этом надо было раньше думать? А был ли мальчик?
Уважаемые господа! Плиз, покажите мне способ хранения паролей к БД в зашифрованном виде? Может я действительно чего не понимаю.
mysql_pconnect('localhost', 'user', md5_decode('encodedpass'));
Что являет собой ф-ция md5_decode()? Если используется свой алгоритм, он наверно тоже где-то хранится? И получив доступ к коду файла с подключением, я могу и этот алгоритм изучить? В чем тогда смысл?
Я к тому, что гарантия защиты пароля - это правильная настройка сервера, который просто не должен отдать текст файла с паролем. Я ни разу не видел, чтоб пароли к бд хранились в зашифрованном виде, и вообще не представляю, как это можно реализовать. А это все-таки более ценная информация, чем доступ к админке.
Единственное, чего я не понимаю, почему все-таки разработчики выбрали столь экзотическое (хотя, широко поддерживаемое) расширение?
mustafa, а я могу апач настроить так, что он и .php будет плейнтекстом отдавать. И чего?
Касательно закона о защите прав потребителей - поинтересуйтесь на http://www.potrebitel.net/forum/ чего Вы можете добиться в этой ситуации. Что-то мне подсказывает, что без чека - ничего. Так что не вижу смысла в браваде про Вашу подкованность в юриспруденции.
Если вдруг Вы про меня - хочу подчеркнуть: конкретно этих разработчиков я не защищаю. Их бизнес, их проблемы, пусть сами защищаются. А вот когда проблемы с обратной совместимостью PHP5 (которые действительно есть) Вы сваливаете на программистов вообще, при этом начиная хамить, а когда Вам явно указывают, что Вы не правы - даже не извиняетесь - я это воспринимаю как личное оскорбление, т.к. свои скрипты (хоть и не на массовую продажу) на пятый PHP еще не перевел и это представляет для меня определенную головную боль. Выходит, я криволапый "самоучка-програмёр"? Ведь должен же вебскрипт работать на кофеварке, оснащенной микропроцессором, если за эту "софтвару" заплатили больше 3 "вебманя"?
Пытаюсь поставить себя на место продавца. Мне кажется, что если человек боится потерять 10 баксов, это явно говорит о том, что он не готов к долгосрочному сотрудничеству, а может и вообще неплатежеспособен. Т.к. кто покупает ссылки помногу и давно, как мне кажется, предпочитают иначе тратить время и силы, и волнуются из-за сумм другого порядка. Возможно я не прав.
Добавлю: правда, разумеется, покупать сразу на большую сумму у неизвестного продавца, наверно не стоит. Купите пробную партию, посмотрите на результат, и дальше делайте выводы.
В яндексе - так же (только вместо звездочки на конце - путь). Т.е.
#link="www.domain.ru/doc.html"
