Мы будем Вам признательны, если Вы поддержите проект Open SLAED и используя Ваши возможности, разместите наш пресс-релиз на страницах своих сайтов, проектов, форумов, блогов. Текст пресс-релиза, возможно, видоизменить под Ваш формат, не искажая смысл. Пресс-релиз можно взять на данной странице.
Еще одна обработка скрипта из серии модулей с использованием флэш-плейера. В нем можно проигрывать файлы в формате FLV (Flash Video)
Реализованы следующие возможности:
1. Добавление текста на страницу модуля, который редактируется в админке с возможностью использования html редактора
2. Автоматическое сканирование директории с видео и создание плейлиста (внимание! при сохранении плей-листа для его корректного отображения на сайте, нужно удалить все строки (не путать с , они должны остаться) и знаки "-".
3. Возможность добавить скрипт в блок
4. Комментарии пользователей
5. Индивидуальная конфигурация скрипта для модуля, блока и радио
Очередное продолжение серии Who's Online.
Что из себя представляет данный блок! Это:
---------------------------
От лица пользователя:
---------------------------
На подобие блока login.php, аватар не показывается, а пишется просто: "Вы зашли как: ваш_ник".
Далее и самое главное, часть "Личные сообщения" убрана!, скорее не убрана а кординально переделана! Тоесть После слов: "Вы зашли как: ваш_ник" идёт надпись не "Личные сообщения" с лампочками Новых и Доставляются, а надпись: "Сейчас на сайте" и дальше как обычно. Вы спросите зачем я так сделал, объясняю:
Зачем же тупо смотреть на напись "Личные сообщения" и на 2 мегающие зелёные лампочки, когда можно сэкономить много место!!! А теперь самое главное=) Теперь когда вам приходит личное сообщение под фразой "Вы зашли как: ваш_ник" появляется строчка: "Вам сообщение: 1/2/3/и тд."(это строчка теперь является ссылкой на ваши личные сообщения)+ ко всему приятный мужской голос говорит по англиски что вам пришло личное сообщение (Сразу слышно и понятно)!!! Голос можно заменить на свою фразу заменив файл "james_kirk.wav" в папке useronline на свой. (Было переделано с postnuke).
-----------------
От лица гостя:
-----------------
Фраза: "Рады вас видеть гость" убрана, заместо неё сразу как в login.php два поля: логин и пароль. Кнопка "Вход" теперь выровнена по правому краю для красоты. Убрана лишняя "hr" линия! Файл преднозначен для систем со встроенным форум PHPBB.
Готова к выходу новая версия SLAED CMS 2.5 Lite. Данная версия является на сегодняшний день самой стабильной и безопасной версией серии Lite. При работе над ней были учтены все актуальные и возможные методы нападений, как правило, это связанно с участившейся последнее время спамерской активностью в сети интернета. Была полностью переписана система генерации секретного кода и метода его проверки. Таким образом, исключена возможность его манипуляции и подделки. С детальными изменениями можно ознакомиться при подробном просмотре.
Модифицирована функция генерации секретного кода, после чего исключена возможность его обхода для многократной отправки сообщений, а так же подключение скриптов производящие отправку в автоматическом режиме.
Модификация подверглась функция добавление комментариев системы. В случае разрешения комментировать анонимным пользователям, в качестве защиты от роботов, спамеров добавлена проверка графического секретного кода.
Модифицирован модуль добавление новостей системы. Добавлена проверка на анонимного пользователя, в случае если пользователь не зарегистрирован, производится проверка графического секретного кода, что в свою очередь исключает добавление новостей спамерскими роботами.
В модуле добавления новостей установлено использование дополнительных полей, так же как и в панели администратора версии 2.4 Lite.
Исправлена ошибка, связанная с добавлением новостей в модуле Add_News.
Исправлена ошибка проявлявшаяся в браузере Mozilla Firefox. В комментариях при нажатии на имя, имя не переносилось в поле комментария.
В панели безопасности системы при просмотре логов ошибка и нападений исправлена ошибка в их отображении. Ошибка была связанна с функцией фильтрации кода защиты.
Модифицирован модуль обратной связи, исключено зафлуживание почтового ящика автоматическими программами или скриптами.
Модификациям подвергся модуль пользователя, при включённом секретном коде исключена возможность входа и регистрации автоматических программ регистрации и роботов.
Модифицирован модуль вопросов и ответом, для анонимных посетителей при отправки вопроса принудительно выводится проверка графического кода, что в свою очередь защищает модуль от спамеров.
В соответствии с новой функцией генерации секретного кода, откорректированы блоки, в которых предоставляется возможность входа в систему как зарегистрированного пользователя.
Модификации подверглись функции основного файла администратора, который используются для входа в систему.
Модифицированы участки стилей темы оформления, используемые как в панели администратора, так и в пользовательской части.
Модификации подвергся модуль рекомендаций. Добавлен секретный код в случае использования модуля анонимными пользователями.
Модифицирован фильтр засветления отключенных модулей в панели администратора системы.
Скачать новую версию возможно начиная с 03.09.2007 в файловом архиве нашего проекта.
В серии статей "Ten Security Checks for PHP" кратко рассматриваются 10 наиболее часто совершаемых PHP программистами ошибок, приводящих к проблемам с безопасностью скриптов.
Избегайте использования переменных сформированных на основании данных пользователя в функции включения файла (include, require) или доступа к файлу (readfile, fopen, file). Например: include($lib_dir . "functions.inc"); include($page); переменные $lib_dir и $page перед этим нужно проверить либо на предмет наличия запрещенных символов, либо сопоставить с заранее определенным массивом допустимых значений.
if (!(eregi("^[a-z_./]*$", $page) && !eregi("..", $page))) {
die("Invalid request");
}
Необходимо экранировать опасные символы ( и ') в переменных участвующих в SQL запросах. Например, злоумышленник может передать переменную вида "password=a%27+OR+1%3Di%271" которая будет использована в SQL запросе как "Password='a' or 1='1'". Решение: включить magic_quotes_gpc в php.ini или экранировать переменные самостоятельно через addslashes();
Никогда не нужно доверять глобальным переменным, при включенном в php.ini режиме register_globals злоумышленник может подменить значение глобальной переменной. Используйте ассоциативные массивы $HTTP_GET_VARS и $HTTP_POST_VARS с выключенным register_globals и в начале скрипта явно инициализируйте все глобальные переменные.
Определяйте местонахождение закаченного файла только через is_uploaded_file() или используя move_uploaded_file(), но не доверяйте глобальной переменной с путем к закаченному файлу, значение которой злоумышленник может подменить.
Используйте функции htmlspecialchars(), htmlentities() для экранирования HTML тэгов присутствующих в данных полученных от пользователя.
Защищайте библиотеки функций от просмотра их исходных текстов пользователем (расширения .inc, .class). Решение: снабжайте библиотеки расширением .php, помещайте в закрытую директорию или настройте хэндлер для парсинга расширения файлов с вашими библиотеками.
Помещайте файлы данных вне дерева файловой системы доступной через web (уровнем ниже htdocs, или "document root") или защищайте директории через .htaccess.
mod_php запускайте в режиме safe_mode.
Проверяйте наличие запрещенных символов в переменные используемых в функциях eval, preg_replace, exec, passthru, system, popen, ``.
При использовании не mod_php, а CGI варианта php.cgi не забывайте, что через php.cgi можно получить доступ к любому файлу в директориях защищенных через .htaccess, так как доступ в этом случае ограничен только для прямых запросов, но не для запросов через CGI скрипт php.cgi.
В этой публикации мы затронем те директивы, которые не успели охватить в предыдущих частях. Эти директивы не поддаются определению на уровне директорий. Это означает то, что вы должны иметь доступ к файлу конфигурации веб сервера Apache (httpd.conf).
Обычно такой доступ имеют пользователи «root» или администратор сервера.
Если вы хотите вести логи всех операций, выполненных с помощью mod_rewrite, можно активировать это с помощью следующей записи:
Эту строку нужно вписать в «Раздел 2: Конфигурация основного сервера» в файле httpd.conf, а не в .htaccess!
Все манипуляции, произведенные mod_rewrite будут записываться в этот файл. Имя лог файла может быть любым. Вы можете указать абсолютный или относительный (относительно ServerRoot) путь к файлу.
Если вы хотите вести разные лог файлы для различных виртуальных хостов, то нужно ввести изменения в «Раздел 3: Виртуальные сервера», например так:
RewriteLogLevel может быть определен в пределах диапазона от 1 до 8. Обычно достаточно первого уровня. Более высокие уровни используются для деббагинга.
Другая директива, которая является очень удобной в целях клоакинга – это так называемая карта перезаписи. Это – файлы, содержащие пары ключ/значение, обычно в формате текстового файла:
Ключи, как вы видите, имена хостов или IP адреса. В этом простеньком примере значение всегда одно – «spider». Естественно, в реальном файле значения будут другие. Эта директива может быть записана в второй («Конфигурация основного сервера») или третий («Виртуальные сервера») раздел файла httpd.conf:
«Карта перезаписи» возымеет эффект на весь сервер.
Также, в файл .htaccess записывается:
Данные условия будут производить системную проверку: произведен ли запрос поисковиком. С этой целью производится поиск по файлу spiderspy.txt. Если ключ найден, будет возвращено значение «spider», а «условие» будет являться истинным.
Затем выполняется первый RewriteRule. Это означает то, что запрашиваемая «.htm» страница будет отдана поисковику. Переменная $1 равна части в круглых скобках «^(. *).htm$», то есть имя файла останется тем же самым.
Если же URL вызван обычным посетителем, то применяется второе «правило»: пользователь будет перенаправлен на страницу «index.html».
Поскольку «.htm» страницы будут читаться только «пауками», они могут быть оптимизированы соответственно для поисковых серверов. Вы можете также использовать файл в формате «dbm» вместо обычного текстового файла. Бинарный формат данных позволяет ускорить поиск, который является особенно важным, если вы работаете с очень большими списками поисковиков. Пример, данный выше, предлагает простые функциональные возможности клоакинга. Все обычные посетители будут всегда переадресовываться к странице «index.html» и не будет вестись никаких логов файлов вне логов mod_rewrite.
Можно заменить несколько строчек кода php (perl и т.д.) в ваших приложениях, используя всего одну-две строки mod_rewrite. Последний пример проиллюстрирует это более подробно.
Цель – показать посетителям «фото дня». Посетитель, кликнувший по ссылке http://yoursite.com/pic.html увидит лучшую фотографию или картинку дня, и так каждый день. Мы будем работать с серверными переменными: TIME_MON, TIME_DAY
Поместим в файл .htaccess одну единственную строку:
Запрашиваемый URL будет перезаписан, например: pic-08-28.html, pic-08-29.html, pic-08-30.html и так далее.
Теперь, все что вы должны сделать – это единожды загрузить файлы с соответсвующими именами и забыть о ежедневном обновлении ссылки. Переменные времени также могут использоваться для другой периодичности.
Это был последний пример в серии публикаций о замечательном модуле mod_rewrite. Естественно невозможно было затронуть все нюансы, директивы, переменные и т.д. в данной публикации, целью было другое – дать общее представление и понимание основ, и так сказать «ввести в курс дела».
Вы наверняка встречали в сети термин «mod_rewrite». Для наших читателей, которые не до конца знакомы с этим модулем веб сервера Apache, а также для тех, кто вообще первый раз об этом слышит – постараюсь рассказать в этой публикации (в нескольких частях) подробнее о данном модуле.
Модуль mod_rewrite является программным модулем веб сервера Apache (обратите внимание, что он не будет выполняться под другими веб серверами!). Его первичная функция - манипуляция действий с URL. Модуль очень универсален и разносторонен, поэтому я постараюсь показать здесь множество реальных примеров.
Mod_rewrite является замечательным модулем, который предоставляет «основанный на правилах механизм динамического изменения запрашиваемых URL-ов». Это действительно мощный инструмент, и поэтому, его знание принципиально важно, если вы хотите стать подлинным веб мастером или веб программистом. Не столько принципиально, будете ли вы использовать его в своей работе, сколько важно то, что вы знаете, что он может делать, и сможете поведать об этом своему боссу, когда появится желание сделать что-нибудь странное с веб сервером.
Однако нужно быть очень осторожным и даже дотошным при работе с этим модулем! Некоторые ошибки, которые Вы способны допустить, могут привести к логической петле, причиняя непрекращающуюся 100%-ую загрузку ценрального процессора (CPU).
Чтобы не казаться пространным в рассуждениях, приведу некоторые очень простые примеры.
Прежде, чем мы сможем приступить к работе, Вы должны будете проверить, установлен ли модуль на вашем веб сервере или нет.
Есть несколько способов проверить это:
1. Спросить вашего системного администратора - знает ли он (или она) о наличии этого модуля на веб сервере. Они действительно должны знать, но как показывает практика – попадаются и не очень сведующие сисадмины ...
2. Не напрягайте других: если Вы используете ваш веб сервер с сотнями других доменов, ваши действия могут разбудить некоторых спящих собак, поскольку использование mod_rewrite будет всегда влечь за собой некоторую увеличенную загрузку ценрального процессора.
3. Проверить ваш файл конфигурации Apache (httpd.conf), если Вы имеете к нему доступ. Один из возможных стандартных путей может быть: /etc/httpd/httpd.conf
Однако, ваш путь может очевидно отличаться от этого. Проверить работу вашего сервера с ниже приведенными примерами. Если сервер работает без ошибок – mod_rewrite действительно установлен на вашей системе. Если нет, Вы получите следующее сообщение при запросе любой web-страницы с вашего сервера: «Внутренняя ошибка сервера» Также, Вы увидите такую запись в файле «error.log»: «Invalid command 'RewriteEngine', perhaps mis-spelled or defined by a module not included in the server configuration».
Теперь давайте копнем поглубже и посмотрим первый практический примерчик.
Предположим, что Вы будете использовать mod_rewrite только для вашего собственного сайта, то есть не как обобщенную перекрестную установку сервера.
Для нашего примера потребуется использование файла .htaccess. Для работы этого метода, Вы должны загрузить файл под названием «.htaccess» (пожалуйста, обратите внимание на точку в начале имени файла!) в папку сервера, с которой Вы будете работать. Это можно сделать через telnet или ftp. (Предупреждение: .htaccess должен быть загружен в «режиме ASCII», то есть не в бинарном режиме!)
Если у Вас уже имеется файл «.htaccess», например со следующими записями:
то просто добавьте снизу наш образец кода к уже существующему (Важно: редактируйте ваш файл .htaccess в ASCII-редакторе типа Notepad).
Первые две записи запустят сам модуль:
Совет: запись «RewriteEngine off» отменит все последующие команды. Это - очень полезная особенность: вместо необходимости комментировать все последующие строки – все, что Вы должны сделать, это установить «off».
Если ваш системный администратор запрещает Вам использование «Options +FollowSymlinks», Вы не сможете ограничить использование mod_rewrite для отдельных каталогов, вместо этого изменения будут действовать на весь сервер.
Следующая необходимая запись - это:
«/» является корневым (основным) URL. Если у Вас какой-то другой URL, Вы можете указать это в данной директиве, однако «/» – обычно эквивалентно адресу «http://домен.ру».
А теперь, господа, перейдем к более интересным записям!
Предположим, что вы хотите защитить от несанкционированного доступа ваш файл .htaccess. На некоторых серверах Вы можете легко читать этот файл просто вводя URL следующего формата в поле адреса вашего браузера: http://www.domain.com/.htaccess – серьезное упущение защиты, так как содержание вашего .htaccess может показать важную информацию об установках и настройках вашего сайта человеку, знающему как эти знания применить против вас.
Чтобы блокировать этот доступ, запишем следующее:
Это правило переводится так:
Если кто-то пробует обращаться к файлу .htaccess, система должна произвести код ошибки «HTTP response of 403» или «403 Forbidden - You don't have permission to access /.htaccess on this server».
Конструкция ^.htaccess$ в этом регулярном выражении означает:
^ – якорь начала строки
$ – якорь конца строки
. – в регулярных выражениях точка «.» обозначает мета-символ и должна быть защищена обратным слэшем (backslash), если Вы все-таки хотите использовать именно фактическую точку.
Имя файла должно быть расположено точно между начальным и конечным якорем. Это будет гарантировать то, что только это определенное имя файла и никакое другое, сгенерирует код ошибки.
[F] – специальный «запрещающий» флажок (forbidden).
В этом примере, файл ".htaccess" теперь будет состоять из таких строк:
Если мы добавим наш код (в примерах) к существовавшему ранее файлу «.htaccess», то получим следующую конструкцию:
Это введение затрагивает лишь основы, требуемые для того, чтобы работать с модулем mod_rewrite. Во второй части этой обучающей серии статей постараюсь объяснить использование различных условий в конфигурировании модуля.
Ссылка по теме: URL Rewriting Engine
Автор статьи: Denveroid
Источник: sitemaker.ru
Еще одна обработка скрипта из серии модулей с использованием флэш-плейера. В нем можно проигрывать файлы в формате FLV (Flash Video)
