Вопрос защиты информации и авторских прав интересовал давно, но сверх острой необходимости заняться этим вопросом видимо не было - раз не занялся, кроме как теоретических изысканий. Сейчас такая необходимость возникла - пришла очередь и до практических действий.

Немного теории, а вернее будет сказать, что формулировка собственных выводов, основанных вовсе не на ровном месте, все же будет уместно. Это выводы конечно собственные и не исключено, что некоторые их моменты будут не совпадать с общепринятым мнением, а может быть вовсе им противоречить.

Стоит отметить, что речь идет о Web-решениях, то есть об объектах, расположенных на сервере. Это скрипты, движки сайтов (что по сути тоже скрипты - многофайловые), шаблоны дизайна, различные библиотеки, просто фрагменты кода. Специфика интернет и менталитет жильцов зоны RU таковы, что оставленный без присмотра файл на сервере и имеющий хоть одну входящую ссылку, а иногда и не имеющий - через сутки может уже автору не принадлежать, а быть достоянием всей "паутинной" страны. Поэтому, если автор какого либо кодового решения, и это решение представляет какую-то реальную ценность, то это решение нужно защищать от не санкционированного посягательства. Конечно же Вы не обязаны это делать, если Вы Рокфеллер, раздающий жаренные каштаны и пятицентовики нищим, входя в парадный подъезд своей империи.

Теперь конкретнее - мысли, а не философское словоблудие.

Какие существуют основные способы защиты (будем говорить о скриптах и далее это и будем подразумевать), заслуживающие внимания, что бы быть упомянутыми?

Мое мнение такое: кодирование, привязка к домену, привязка к IP.

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

Привязка к домену. Это комплекс кодовых решений, когда защищенный скрипт может работать только на том домене, на котором ему разрешено работать. Что бы поселиться на другом домене ему нужна "прописка" - код доступа или иными словами лицензия для работы в этом домене.

Привязка к IP. Суть одна, что и привязка к домену, только скрипт работает и что-то выполняет при этом, отдавая данные браузеру, если браузер этот имеет определенный IP-адрес.

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

Продолжаем анализ...

Для этого проведем чистый эксперимент. Берем закрытый шифром файл широко известного движка, работа которого основана именно на лицензионной привязке к домену. Совершенно очевидно, что этот файл содержит фрагмент кода, осуществляющего проверку домена и его соответствие указанной в настройках сайта лицензии на этот домен. Обойдемся без названий файла, и тем более движка.

Файл закрыт кодером Zend. Специально обращаю внимание, что стоимость этого популярного ПО составляет 999$. Не каждый может позволить себе официально купить эту софтину. Вопрос нас интересует в общем то обратного порядка - нам нужно раскодировать файл. Идем за помощью к Google, который знает все. Google вежливо выдает нам по запросу десяток страниц с интересующими параметрами запроса поиска.

В результате дезендер был найден - доступ к исходному коду соответсвенно тоже.

Соображая немного в PHP не трудно понять, что в коде за что отвечает, забрать нужную функцию и получить из нее генератор лицензий.

Потратив несколько вечеров на пару с Google и пречитав кучу информации про все пользующиеся реальным спросом программы шифраторы, поэксперементировав с имеющимся собственным софтом и скачанным для такого случая из интернет, был сделан вовсе не утешительный вывод. Шифрование кода файлов реальной зашиты не дает, не то, что на 100 процентов, а не дает и близко к этому.

Окончательный вывод: использовать этот метод без совокупности с другими способами защиты не защищает Вашу интеллектуальную собственность должным образом и вовсе не важно сколь хороша программа и сколько она стоит.

Продолжение по мере написания...

Занимаясь изучением CMS обратил внимание на такой параметр, который непременно выпячивается в списке выполняемых функций движком как нечто необходимое и важное - это так называемый ЧПУ. По этому поводу возникла мысль, а так ли это важно и нужно на самом деле?

Из терминологии еще Советского Союза мне известно, что ЧПУ - это числовое программное управление металлообрабатывающих станков, но вебмастера не любят обычный человеческий язык и вместе со странным словом Юзер вошло в лексикон и выражение ЧПУ, что в переводе означает - человекопонятный URL. Оба слова вызывают сомнения адекватности того, кто первый их произнес...

Лично мне совершенно фиолетово, как выглядит ссылка в адресной строке - главное чтобы она вела туда куда нужно, а не на порно-сайт, если текст ссылки гласит, что я должен попасть на страницу с описанием скрипта, что часто, к сожалению бывает фактом.

И то, что роботы явно очень любят ЧПУ-шные сайты - миф. Еще большим мифом является то, что роботы идиоты.

Если страница имеет расширение HTML - это вовсе не означает, что робот примет этот факт за истину и будет считать, что это статичная страница. В чем собственно разница, как создана страница, написана она в Блокноте и положена на сервер или ее сгенерировал скрипт? Разницы в принципе нет никакой, если ваш контекст - это клон N-ой степени какой-нибудь идиотской статьи 1978 года издания и на всем сайте всего 2 строки авторского текста. Это первое.

Второе. Смотрим, что видит робот индексируя любую страницу сайта. Какие данные отдает сервер роботу для страницы, например этого сайта?

HTTP/1.1 200 OK

Date: Sun, 14 May 2009 15:21:06 GMT

Server: Apache/2.2.8

X-Powered-By: PHP/5.2.5

Vary: Accept-Encoding,User-Agent

Connection: close

Content-Type: text/html; charset=windows-1251

Покопавшись в этом же домене можно найти и статичную - например страницу error404.html

HTTP/1.1 200 OK

Date: Sun, 14 May 2009 15:27:34 GMT

Server: Apache/2.2.8

Last-Modified: Mon, 11 2009 15:14:35 GMT

ETag: "s57i-109-387675ba321"

Accept-Ranges: bytes

Content-Length: 911

Vary: Accept-Encoding,User-Agent

Connection: close

Content-Type: text/html

Ищем различия. X-Powered-By: PHP/5.2.5 - страница сгенерирована PHP-скриптом. Content-Length: - размер файла статичной страницы известен изначально, а размер динамической не известен - ее генерирует скрипт. ETag – уникальный системный идентификатор статичного файла.

Вывод. Единственный и пожалуй еще раз единственный плюс во всей этой мышиной возне с ЧПУ - это вопрос дополнительной безопасности - псевдостатичная страница имеет не реальный адрес. Только и всего.

Модули, стандарты.

Внимание этим двум понятиям было уделено не случайно.

Создавая новые шаблоны дизайна, отрабатывая иные кодовые решения каждый раз сталкиваешся с одним и тем же и каждый раз делаешь одну и ту же работу. Например, на всех практически сайтах присутствует форма поиска, верхнее горизонтальное меню навигации, используется один и тот же логотип. Возникает закономерный вопрос - зачем каждый раз собирать велосипед из запчастей?

Автор последовательно занялся вопросами модульной унификации. Созданы модули, которые непременно будут присутствовать на страницах шаблонов дизайна - это верхнее и боковые меню, шапка сайта, формы поиска, обратной связи и авторизации. Принцип преследовался один и тот-же - максимальная простота решения, совместимость для всех браузеров, красивый внешний вид блоков.

Для эксперимента была взята стандартная HTML-страница и все решения отрабатывались на ней - тщательно и ответственно. В результате удалось вдвое уменьшить размер файла стилей css и полностью исключить применение хаков. Описание стилей приведено так-же к логически понятному и легко настраиваемому в дальнейшем виду.

Все, что в дальнейшем будет создано автором - будет эту логику поддерживать. Автор создал для себя собственный логотип - в дальнейшем в составе всех авторских работ он будет присутствовать.

- так выглядит авторский логотип, а иконка favicon.ico так:

Что означают две буквы A L? Логика простая - это инициалы автора (имя и фамилия), а желто-зеленый цвет - авторское предпочтение и никакой марксистко-ленинской философии.

Создано большое количество новых авторских решений.

Новые серии шаблонов для популярных скриптов.

Новый движок CMS

Многое другое...

Следите за новостями...

Петь оду движку не буду - и так очевидно, что на данный момент это мой фаворит среди всех прочих CMS.

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

На этой странице и будут представлены шаблоны дизайна именно для Maxsite CMS (для удобства список будет формироваться чисто в хронологическом порядке).

1. Amalgams F5-MS-2 (Baikal)

2. Amalgams F5-MS-2 (Foliage)

3. Amalgams F5-MS-3 (Foliage)

Познакомившись с движком Maxsite CMS - делаю для него свой шаблон. Времени на это потрачено 2 часа. Конечно нужно учесть, что есть опыт создания шаблонов для WordPress, но для него за вечер уложится было нельзя - приходилось что-то подправлять и редактировать. Здесь же шаблон был сделан в обычном текстовом редакторе Notepad+ и выложен на сервер. Коректировка после этого была минимальная - дизайн сайта подключился коректно и без ошибок. Легкое изумление - такого еще не было. Вернее это второй случай в моей практике - первый был не далее как сегодня утром, когда установил сам движок Maxsite - он просто начал работать. Все просто, как лампочку включателем включить.

Очаровало в этом движке два основных момента:

1. Отличная функциональность движка - все логично, лаконично, есть все нужное.
2. Профессиональный дизайн как отображения самих страниц, так и административной панели. Глаза радуются, душа восхищается.

Окончательный вывод такой:

Бесспорно это лучший вариант движка CMS для построения блога, сайта любой практически направленности с учетом наличия плагинов (в коплекте дистрибуива).

Мне, как занимающемуся шаблонами дизайна, такой решение подходит на все 100 процентов.

Извини, WordPress, который я использовал до этого момента, но нашлась тебе замена.

Перевожу в ближайшее время свои ресурсы под опеку Maxsite CMS.

Думаю, что мнение мое не спонтанное, я как раз последние время занимался тестом множества скриптов CMS и объективизм суждения подтвержден практикой, а не дискуссионми амбициями.

Таков вывод и таковы планы из него следующие.