You can set the type of your output image to JPG, GIF or PNG format like this: image.php?image=1.jpg&type=png; If you don’t specify the type of the output image, the script will output the image in the original format image.php?image=1.jpg;

To add a watermark to image you heave to set 2 variables: watermark_text and watermark_color(optional).Black will be use if you do not set the watermark_color;
Example:
1) image.php?image=1.jpg&watermark_text=1234567890&watermark_color=fffff;
2) image.php?image=1.jpg&watermark_text=1234567890;

Resizing images:
a. Exact size:
Variables: w and h
Example: image.php?image=1.jpg&w=100&h=100
b. Maxim size:
Variable: maxim_size
Example: image.php?image=1.jpg&maxim_size=300
c. Percent:
Variable: percent
Example: image.php?image=1.jpg&percent=50
d. Square:
Variable: square
Example: image.php?image=1.jpg&square=100
I use this type of resizing for creating thumbnails that heave the same size

It for study…

it for work
resize-class

First step: Create a folder “wp_plugin” in the folder “plugins”

Second step: Create a file with the following code ajax.php

Go next step

Third step: Create a file with the following code plugin_example.php

It’s easy:)

P.S.: Пишу статью на английском т.к. сам не ищу помощи на русских сайтах, а если нахожу, то в основном все на английском :) Заранее извиняюсь за свой english.

Если у кого есть замечания и предложения, то готов выслушать.

Вот мои сорсы mini_email_reader

X9 особенно полезен для автоматических обменных пунктов, сайтов, выплачивающих “WM-бонусы” и других проектов, в которых посетитель должен видеть текущие денежные резервы сервиса.

Наш XML-запрос должен выглядеть так:
<w3s.request>
<reqn></reqn>
<wmid></wmid>
<sign></sign>
<getpurses>
<wmid></wmid>
</getpurses>
</w3s.request>

Что означают параметры:
reqn – номер запроса, всякий раз должен быть больше предыдущего (в рамках данного отдельно взятого интерфейса);
wmid – ваш WMID, которым подписывается запрос;
sign – подпись запроса, сформированная из параметров: getpurses\wmid+reqn;
getpurses\wmid – WMID, по кошелькам которого необходимо проверить балансы. Дело в том, что данный интерфейс поддерживает доверенности, т.е. вы можете проверить балансы на кошельках чужого WMID, если владелец этого WMID дал вам соответствующую доверенность на сайте security.webmoney.ru. Запрос в этом случае вы всё равно должны подписывать своим WMID, но в поле getpurses\wmid записать WMID проверяемый. В приведенном ниже примере функции мы будем проверять балансы на собственном WMID. Если же вы захотите проверить балансы по доверенности, вам нужно будет немного видоизменить функцию.

Формат ответа сервера WebMoney следующий:
<w3s.response>
<reqn></reqn>
<retval></retval>
<retdesc></retdesc>
<purses cnt=”n”>
<purse id=”n”>
<pursename></pursename>
<amount></amount>
</purse>
<purse>
…
</purse>
</purses>
</w3s.response>

Что нас интересует в ответе? Во-первых, поле <retval> (если оно равно 0, то балансы получены успешно, в противном случае retval будет содержать код ошибки, расшифровку которой нужно смотреть в поле <retdesc>). Во-вторых, поля <pursename> и <amount>, содержащие соответственно номера кошельков и их балансы.
Как вы уже поняли, запросить остаток по одному конкретному кошельку, к сожалению, нельзя. Ответ возвращает балансы сразу всех кошельков.

Приведем теперь полностью функцию, которая реализует работу с интерфейсом X9, и добавим её в wmxml.inc.php:

Разберём, что происходит в этой функции.
Функция не получает никаких входных параметров.
Генерируем уникальный номер запроса $reqn с помощью функции _GetReqn():

Получаем подпись XML-пакета с помощью функции _GetSign(). На вход функции подаём строку, полученную в результате склейки параметров, как это предусмотрено в описании интерфейса. Параметры должны склеиваться именно в таком порядке, как это указано ниже.

Отправляем запрос на сервер WebMoney и получаем от него ответ с помощью функции _GetAnswer(). На вход функции подаём URL интерфейса X9 из глобального массива $XML_addr, а также пакет XML-запроса, сформированный только что:

Для отладки и поиска ошибок может потребоваться прочитать XML-ответ “в чистом виде”. Тогда просто раскомментируйте следующую строку:

Вызовом функции simplexml_load_string() из библиотеки SimpleXML создаём на основе XML-ответа, полученного от WebMoney, объект. Параметры XML-ответа становятся свойствами объекта, и мы сможем легко получать к ним доступ.

Если $xmlres не создан, значит, мы по какой-то причине не получили ответ от WebMoney. Тогда прерываем работу функции:

Читаем следующие свойства объекта: retval (содержит результат выполнения запроса; если балансы успешно получены, то retval равен 0), retdesc (содержит расшифровку результата). Сохраняем эти переменные в массив $result.

Обратите внимание, что содержимое поля мы перекодировали из UTF-8 в Win1251. Дело в том, что XML-ответ от WebMoney приходит в кодировке Windows1251, но SimpleXML при помещении XML-данных в объект принудительно превратил их в Юникод. Такая вот у него особенность. А так как – это строка, и теоретически она может содержать русские символы, то при выемке её из объекта мы возвращаем ей “родную” кодировку. Хотя, в общем, это не обязательно и зависит от ваших нужд и задач.

Если retval равен 0, то можно перейти к сохранению балансов по кошелькам. Номера кошельков и их балансы содержатся внутри одинаковых блоков XML-ответа … в и соответственно. Пробегаем эти блоки в цикле и формируем ассоциативный массив, где ключами элементов делаем номера кошельков, а значениями элементов делаем соответствующие этим кошелькам балансы. Сформированный массив сохраняем внутрь элемента purses выходного массива $result:

На выходе функция _WMXML9() возвращает массив $result:

Чтобы было лучше понятно, ещё раз посмотрим на содержимое массива $result (его можно привести в читабельный вид с помощью функции print_r(), например):

Array (
[retval] => код_выполнения
[retdesc] => описание_результата
[purses] => Array (
[номер_кошелька] => баланс
[номер_кошелька] => баланс
[номер_кошелька] => баланс
…
)
)

Теперь осталось только проверить, как работает то, что мы написали. Создадим скрипт для тестов test.php:

Объектно-ориентированные программы более просты и мобильны, их легче модифицировать и сопровождать, чем их “традиционных” собратьев. Кроме того, похоже, сама идея объектной ориентированности при грамотном ее использовании позволяет программе быть даже более защищенной от различного рода ошибок, чем это задумывал программист в момент работы над ней. Однако ничего не дается даром: сами
идеи ООП довольно трудны для восприятия “с нуля”, поэтому до сих пор очень большое количество программ (различные системы Unix, Apache, Perl, да и сам PHP) все еще пишутся на старом добром “объектно-неориентированном” Си.

PHP до недавнего времени обеспечивал лишь некоторую поддержку ООП. Однако, после выхода PHP5 поддержка ООП в PHP стала практически полной.

Стратегию ООП лучше всего описать как смещение приоритетов в процессе программирования от функциональности приложения к структурам данных. Это позволяет программисту моделировать в создаваемых приложениях реальные объекты и ситуации. Технология ООП обладает тремя главными преимуществами:

* она проста для понимания: ООП позволяет мыслить категориями повседневных объектов;
* повышенно надежна и проста для сопровождения — правильное проектирование обеспечивает простоту расширения и модификации объектно-ориентированных программ. Модульная структура позволяет вносить независимые изменения в разные части программы, сводя к минимуму риск ошибок программирования;
* ускоряет цикл разработки — модульность и здесь играет важную роль, поскольку различные компоненты объектно-ориентированных программ можно легко использовать в других программах, что уменьшает избыточность кода и снижает риск внесения ошибок при копировании.

Специфика ООП заметно повышает эффективность труда программистов и позволяет им создавать более мощные, масштабируемые и эффективные приложения.

Объектно-ориентированное программирование основано на:

* Инкапсуляции;
* Полиморфизме;
* Наследовании.

Инкапсуляция

Инкапсуляция – это механизм, объединяющий данные и обрабатывающий их код как единое целое.

Многие преимущества ООП обусловлены одним из его фундаментальных принципов — инкапсуляцией. Инкапсуляцией называется включение различных мелких элементов в более крупный объект, в результате чего программист работает непосредственно с этим объектом. Это приводит к упрощению программы, поскольку из нее исключаются второстепенные детали.

Инкапсуляцию можно сравнить с работой автомобиля с точки зрения типичного водителя. Многие водители не разбираются в подробностях внутреннего устройства машины, но при этом управляют ею именно так, как было задумано. Пусть они не знают, как устроен двигатель, тормоз или рулевое управление, — существует специальный интерфейс, который автоматизирует и упрощает эти сложные операции. Сказанное также относится к инкапсуляции и ООП — многие подробности “внутреннего устройства” скрываются от пользователя, что позволяет ему сосредоточиться на решении конкретных задач. В ООП эта возможность обеспечивается классами, объектами и различными средствами выражения иерархических связей между ними.

Полиморфизм

Полиморфизм позволяет использовать одни и те же имена для похожих, но технически разных задач. Главным в полиморфизме является то, что он позволяет манипулировать объектами путем создания стандартных интерфейсов для схожих действий. Полиморфизм значительно облегчает написание сложных программ.

Наследование

Наследование позволяет одному объекту приобретать свойства другого объекта, не путайте с копированием объектов. При копировании создается точная копия объекта, а при наследовании точная копия дополняется уникальными свойствами, которые характерны только для производного объекта.

Классы и объекты в PHP

Класс – это базовое понятие в объектно-ориентированном программировании (ООП). Если сказать проще, то класс – это своеобразный тип переменной.

Экземпляр класса – это объект. Объект – это совокупность данных (свойств) и функций (методов) для их обработки. Данные и методы называются членами класса. Вообще, объектом является все то, что поддерживает инкапсуляцию.

Внутри объекта данные и код (члены класса) могут быть либо открыты, либо нет. Открытые данные и члены класса являются доступными для других частей программы, которые не являются частью объекта. А вот закрытые данные и члены класса доступны только внутри этого объекта.

Описание классов в PHP начинаются служебным словом class:

class Имя_класса {
// описание членов класса – данных и методов для их обработки
}

Для объявления объекта необходимо использовать оператор new:

Объект = new Имя_класса;

Данные описываются с помощью служебного слова var. Метод описывается так же, как и обыкновенная функция. Методу также можно передавать параметры.

Пример класса на PHP:

Доступ к класам и объектам в PHP

Мы рассмотрели, каким образом описываются классы и создаются объекты. Теперь нам необходимо получить доступ к членам класса, для этого в PHP предназначен оператор ->. Приведем пример:

Чтобы получить доступ к членам класса внутри класса, необходимо использовать указатель $this, которы всегда относится к текущему объекту. Модифицированный метод Getname():

Таким же образом, можно написать метод Setname():

Теперь для изменения имени можно использовать метод Setname():

А вот и полный листинг кода:

Указатель $this можно также использовать для доступа к методам, а не только для доступа к данным:

Инициализация объектов

Иногда возникает необходимость выполнить инициализацию объекта – присвоить его свойствам первоначальные значения. Предположим, имя класса Coor и он содержит два свойства:имя человека и город его проживания. Можно написать метод (функцию), который будет выполнять инициализацию объекта, например Init():

Главное не забыть вызвать функцию сразу после создания объекта, либо вызвать какой-нибудь метод между созданием (оператор new) объекта и его инициализацией (вызовом Init).

Для того, чтобы PHP знал, что определенный метод нужно вызывать автоматически при создании объекта, ему нужно дать имя такое же, как и у класса (Coor):

Метод, инициализирующий объект, называется конструктором. Однако, PHP не имеет деструкторов, поскольку ресурсы освобождаюся автоматически при завершении работы скриптов.

Наследование и полиморфизм классов в PHP

Наследование классов в PHP

Наследование – это не просто создание точной копии класса, а расширение уже существующего класса, чтобы потомок мог выполнять какие-нибудь новые, характерные только ему функции. Рассмотрим конкретный пример на PHP:

Ключевое слово extends (см. пример) говорит о том, что дочерний класс Child наследует все методы и свойства класса Parent. Родительский класс обычно называют базовым классом или суперклассом, а дочерний класс Child – производным или подклассом.

Полиморфизм классов в PHP

Полиморфизм – это свойства базового класса использовать функции производных классов. Практический пример, показывающий свойство класса – полиморфизм:

В рассмотренном примере функция base_funct() класса Base была перезаписана одноименной функцией класса Derivative. Функция, переопределенная таким образом, называется виртуальной.

Стерпев безобразие все же сделал, то что требовалось!

Во первых вставляем код в фаил wp-includes/script-loader.php

вместо :

В файле вставим формочку wp-admin/edit-page-form.php после  <h2><?php _e(‘Advanced Options’); ?></h2>

А так их можно отобразить:

Спасибо за внимание, чуть позже допишу эти таги и обязательно запостю вторую часть.

Есть одна замечательная функция add_filter с помощью которой можно делать чудеса! Мне приходилось на некоторых страницах/постах менять к примеру title или content

Делается это так (пример для постов и страниц):

Пишется функция с глобальной переменной $post в которой описывается что вы хотите сделать и вставляется в фильтер, к примеру возьмем основную часть контента
add_filter(‘the_content’,ваша функция) , так можно переоформить многие элементы wordpress

Актуально ли это сейчас не могу утверждать, но может пригодиться.

1. В файле wp-config.php, после всего кода добавить

2. В файле capabilities.php, после всего кода добавить

3. После 463 строки, в файле tdomf.php добавить

и сделать закрытие после описания функции, тоесть до
//////////////////////////////////
// Load the rest of the plugin! //
//////////////////////////////////

4. После
/////////////////////////
// Start/Init/Upgrade //
////////////////////////
Вставить:

и закрыть после описания функции, тоесть перед строкой: tdomf_db_create_tables();

5. В файле plugins/tdo-mini-forms/include/tdomf-form.php расскоментить строку 159 и в строке 157 вместо draft вписать publish

Первой заповедью веб-программиста, желающего написать более-менее защищенное веб-приложение, должно стать “Никогда не верь данным, присылаемым тебе пользователем”. Пользователи – это по определению такие злобные хакеры, которые только и ищут момента, как бы напихать в формы ввода всякую дрянь типа PHP, JavaScript, SSI, вызовов своих жутко хакерских скриптов и тому подобных ужасных вещей. Поэтому первое, что необходимо сделать – это жесточайшим образом отфильтровать все данные, присланные пользователем.

Допустим, у нас в гостевой книге существует 3 формы ввода: имя пользователя, его e-mail и само по себе тело сообщения. Прежде всего, ограничим количество данных, передаваемых из форм ввода чем-нибудь вроде:

На роль настоящей защиты, конечно, это претендовать не может – единственное назначение этого элемента – ограничить пользователя от случайного ввода имени длиннее 20-ти символов. А для того, чтобы у пользователя не возникло искушения скачать документ с формами ввода и подправить параметр maxlength, установим где-нибудь в самом начале скрипта, обрабатывающего данные, проверку переменной окружения web-сервера HTTP-REFERER:

Теперь, если данные переданы не из форм документа, находящегося на сервере www.myserver.com, хацкеру будет выдано деморализующее сообщение. На самом деле, и это тоже не может служить 100%-ой гарантией того, что данные ДЕЙСТВИТЕЛЬНО переданы из нашего документа. В конце концов, переменная HTTP_REFERER формируется браузером, и никто не может помешать хакеру подправить код браузера, или просто зайти телнетом на 80-ый порт и сформировать свой запрос. Так что подобная защита годится только от Ну Совсем Необразованных хакеров. Впрочем, по моим наблюдениям, около 80% процентов злоумышленников на этом этапе останавливаются и дальше не лезут – то ли IQ не позволяет, то ли просто лень. Лично я попросту вынес этот фрагмент кода в отдельный файл, и вызываю его отовсюду, откуда это возможно. Времени на обращение к переменной уходит немного – а береженого Бог бережет.

Следующим этапом станет пресловутая жесткая фильтрация переданных данных. Прежде всего, не будем доверять переменной maxlength в формах ввода и ручками порежем строку:

Не дадим пользователю использовать пустое поле имени – просто так, чтобы не давать писать анонимные сообщения:

Запретим пользователю использовать в своем имени любые символы, кроме букв русского и латинского алфавита, знака “_” (подчерк), пробела и цифр:

Я предпочитаю везде, где нужно что-нибудь более сложное, чем проверить наличие паттерна в строке или поменять один паттерн на другой, использовать Перл-совместимые регулярные выражения (Perl-compatible Regular Expressions). То же самое можно делать и используя стандартные PHP-шные ereg() и eregi(). Я не буду приводить здесь эти примеры – это достаточно подробно описано в мануале.

Для поля ввода адреса e-mail добавим в список разрешенных символов знаки “@” и “.”, иначе пользователь не сможет корректно ввести адрес. Зато уберем русские буквы и пробел:

Поле ввода текста мы не будем подвергать таким жестким репрессиям – перебирать все знаки препинания, которые можно использовать, попросту лень, поэтому ограничимся использованием функций nl2br() и htmlspecialchars() – это не даст врагу понатыкать в текст сообщения html-тегов. Некоторые разработчики, наверное, скажут: “а мы все-таки очень хотим, чтобы пользователи _могли_ вставлять теги”. Если сильно неймется – можно сделать некие тегозаменители, типа “текст, окруженный звездочками, будет высвечен bold’ом.”. Но никогда не следует разрешать пользователям использование тегов, подразумевающих подключение внешних ресурсов – от тривиального <img> до супернавороченного <bgsound>.

Как-то раз меня попросили потестировать html-чат. Первым же замеченным мной багом было именно разрешение вставки картинок. Учитывая еще пару особенностей строения чата, через несколько минут у меня был файл, в котором аккуратно были перечислены IP-адреса, имена и пароли всех присутствовавших в этот момент на чате пользователей. Как? Да очень просто – чату был послан тег <img src=http://myserver.com/myscript.pl>, в результате чего браузеры всех пользователей, присутствовавших в тот момент на чате, вызвали скрипт myscript.pl с хоста myserver.com. (там не было людей, сидевших под lynx’ом :-) ). А скрипт, перед тем как выдать location на картинку, свалил мне в лог-файл половину переменных окружения – в частности QUERY_STRING, REMOTE_ADDR и других. Для каждого пользователя. С вышеупомянутым результатом.

Посему мое мнение – да, разрешить вставку html-тегов в чатах, форумах и гостевых книгах – это красиво, но игра не стоит свеч – вряд ли пользователи пойдут к Вам на книгу или в чат, зная, что их IP может стать известным первому встречному хакеру. Да и не только IP – возможности javascript’a я перечислять не буду :-)

Для примитивной гостевой книги перечисленных средств хватит, чтобы сделать ее более-менее сложной для взлома. Однако для удобства, книги обычно содержат некоторые возможности для модерирования – как минимум, возможность удаления сообщений. Разрешенную, естественно, узкому (или не очень) кругу лиц. Посмотрим, что можно сделать здесь.

Допустим, вся система модерирования книги также состоит из двух частей – страницы со списком сообщений, где можно отмечать подлежащие удалению сообщения, и непосредственно скрипта, удаляющего сообщения. Назовем их соответственно admin1.php и admin2.php.

Простейший и надежнейший способ аутентикации пользователя – размещение скриптов в директории, защищенной файлом .htaccess. Для преодоления такой защиты нужно уже не приложение ломать, а web-сервер. Что несколько сложнее и уж, во всяком случае, не укладывается в рамки темы этой статьи. Однако не всегда этот способ пригоден к употреблению – иногда бывает надо проводить авторизацию средствами самого приложения.

Первый, самый простой способ – авторизация средствами HTTP – через код 401. При виде такого кода возврата, любой нормальный браузер высветит окошко авторизации и попросит ввести логин и пароль. А в дальнейшем браузер при получении кода 401 будет пытаться подсунуть web-серверу текущие для данного realm’а логин и пароль, и только в случае неудачи потребует повторной авторизации. Пример кода для вывода требования на такую авторизацию есть во всех хрестоматиях и мануалах:

Разместим этот кусочек кода в начале скрипта admin1.php. После его выполнения, у нас будут две установленные переменные $PHP_AUTH_USER и PHP_AUTH_PW, в которых соответственно будут лежать имя и пароль, введенные пользователем. Их можно, к примеру, проверить по SQL-базе:

*** Внимание!!!***

В приведенном ниже фрагменте кода сознательно допущена серьезная ошибка в безопасности. Попытайтесь найти ее самостоятельно.

Упомянутая ошибка, между прочим, очень распространена среди начинающих и невнимательных программистов. Когда-то я сам поймался на эту удочку – по счастью, особого вреда это не принесло, не считая оставленных хакером в новостной ленте нескольких нецензурных фраз.

Итак, раскрываю секрет: допустим, хакер вводит заведомо несуществующее имя пользователя и пустой пароль. При этом в результате выборки из базы переменная $rpassword принимает пустое значение. А алгоритм шифрования паролей при помощи функции СУБД MySQL Password(), так же, впрочем, как и стандартный алгоритм Unix, при попытке шифрования пустого пароля возвращает пустое значение. В итоге – $password == $rpassword, условие выполняется и взломщик получает доступ к защищенной части приложения. Лечится это либо запрещением пустых паролей, либо, на мой взгляд, более правильный путь – вставкой следующего фрагмента кода:

То есть – проверкой наличия одного и только одного пользователя в базе. Ни больше, ни меньше.

Точно такую же проверку на авторизацию стоит встроить и в скрипт admin2.php. По идее, если пользователь хороший человек – то он приходит к admin2.php через admin1.php, а значит, уже является авторизованным и никаких повторных вопросов ему не будет – браузер втихомолку передаст пароль. Если же нет – ну, тогда и поругаться не грех. Скажем, вывести ту же фразу “hacker? he-he…”.

К сожалению, не всегда удается воспользоваться алгоритмом авторизации через код 401 и приходится выполнять ее только средствами приложения. В общем случае модель такой авторизации будет следующей:

Пользователь один раз авторизуется при помощи веб-формы и скрипта, который проверяет правильность имени и пароля.
Остальные скрипты защищенной части приложения каким-нибудь образом проверяют факт авторизованности пользователя.
Такая модель называется сессионной – после прохождения авторизации открывается так называемая “сессия”, в течение которой пользователь имеет доступ к защищенной части системы. Сессия закрылась – доступ закрывается. На этом принципе, в частности, строится большинство www-чатов: пользователь может получить доступ к чату только после того, как пройдет процедуру входа. Основная сложность данной схемы заключается в том, что все скрипты защищенной части приложения каким-то образом должны знать о том, что пользователь, посылающий данные, успешно авторизовался.

Рассмотрим несколько вариантов, как это можно сделать:

После авторизации все скрипты защищенной части вызываются с неким флажком вида adminmode=1. (Не надо смеяться – я сам такое видел).

Ясно, что любой, кому известен флажок adminmode, может сам сформировать URL и зайти в режиме администрирования. Кроме того – нет возможности отличить одного пользователя от другого.

Скрипт авторизации может каким-нибудь образом передать имя пользователя другим скриптам. Распространено во многих www-чатах – для того, чтобы отличить, где чье сообщение идет, рядом с формой типа text для ввода сообщения, пристраивается форма типа hidden, где указывается имя пользователя. Тоже ненадежно, потому что хакер может скачать документ с формой к себе на диск и поменять значение формы hidden. Некоторую пользу здесь может принести вышеупомянутая проверка HTTP_REFERER – но, как я уже говорил, никаких гарантий она не дает.

Определение пользователя по IP-адресу. В этом случае, после прохождения авторизации, где-нибудь в локальной базе данных (sql, dbm, да хоть в txt-файле) сохраняется текущий IP пользователя, а все скрипты защищенной части смотрят в переменную REMOTE_ADDR и проверяют, есть ли такой адрес в базе. Если есть – значит, авторизация была, если нет – “hacker? he-he…” :-)

Это более надежный способ – не пройти авторизацию и получить доступ удастся лишь в том случае, если с того же IP сидит другой пользователь, успешно авторизовавшийся. Однако, учитывая распространенность прокси-серверов и IP-Masquerad’инга – это вполне реально.

Единственным, известным мне простым и достаточно надежным способом верификации личности пользователя является авторизация при помощи random uid. Рассмотрим ее более подробно.

После авторизации пользователя скрипт, проведший авторизацию, генерирует достаточно длинное случайное число:

Это число он:

а) заносит в локальный список авторизовавшихся пользователей;
б) Выдает пользователю.

Пользователь при каждом запросе, помимо другой информации (сообщение в чате, или список сообщений в гостевой книге), отправляет серверу свой uid. При этом в документе с формами ввода будет присутствовать, наряду с другими формами, тег вида:

<input type=hidden name=uid value=1234567890>

Форма uid невидима для пользователя, но она передается скрипту защищенной части приложения. Тот сличает переданный ему uid с uid’ом, хранящимся в локальной базе и либо выполняет свою функцию, либо… “hacker? he-he…”.

Единственное, что необходимо сделать при такой организации – периодически чистить локальный список uid’ов и/или сделать для пользователя кнопку “выход”, при нажатии на которую локальный uid пользователя сотрется из базы на сервере – сессия закрыта.

Некоторые программисты используют в качестве uid не “одноразовое” динамически генерирующееся число, а пароль пользователя. Это допустимо, но это является “дурным тоном”, поскольку пароль пользователя обычно не меняется от сессии к сессии, а значит – хакер сможет сам открывать сессии. Та же самая модель может быть использована везде, где требуется идентификация пользователя – в чатах, веб-конференциях, электронных магазинах.

В заключение стоит упомянуть и о такой полезной вещи, как ведение логов. Если в каждую из описанных процедур встроить возможность занесения события в лог-файл с указанием IP-адреса потенциального злоумышленника – то в случае реальной атаки вычислить хакера будет гораздо проще, поскольку хакеры обычно пробуют последовательно усложняющиеся атаки. Для определения IP-адреса желательно использовать не только стандартную переменную REMOTE_ADDR, но и менее известную HTTP_X_FORWARDED_FOR, которая позволяет определить IP пользователя, находящегося за прокси-сервером. Естественно – если прокси это позволяет.

При ведении лог-файлов, необходимо помнить, что доступ к ним должен быть только у Вас. Лучше всего, если они будут расположены за пределами дерева каталогов, доступного через WWW. Если нет такой возможности – создайте отдельный каталог для лог-файлов и закройте туда доступ при помощи .htaccess (Deny from all).

Я буду очень признателен, если кто-нибудь из программистов поделится своими, не описанными здесь методами обеспечения безопасности при разработке приложений для Web.

Очень удобный онлайн сервис по адресу http://www.regexpal.com/ не требует перезагрузки страницы для проверки регулярного выражения, написан полностью на javascript. Планрую на своем сайте создать подобный онлайн сервис.

Еще один неплохой сервис проверки, но минус его в том, что необходимо перегружать страницу, а плюс в том, что он выводит результаты, что очень удобно при работе.Плюс есть шпаргалка, но к сожалению она не полная :( http://regexpr.ru/

Пример написанных и оттестеных регулярных выражений, написанных мною, которые я использовал при написании на PHP. В данном случае нужно было парсить всю страницу и добавлять клинкам строку.

Разбить на предложения по спец символам