Вот тут нам на помощь и приходит noop(). Вызывая инициализацию объекта, в параметре, передающем функцию обратного вызова, мы указываем jQuery.noop(). Условия выполнены, а действие не обрабатывается. И все довольны.

В интернете можно найти много способов решения этой проблемы, я же для себя выбрал путь на основе JSON и объясню почему.

1. JSON — сериализированные данные, которые удобно читаются человеком.
2. JSON данные легко преобразуются в объекты.
3. Данные легко преобразуются в текст JSON.
4. jQuery прекрасно работает с JSON и AJAX
5. На основе JSON наиболее просто организовать API.
6. JSON расходует гораздо меньше трафика, чем, к примеру XML.

Этих шести пунктов мне оказалось более чем достаточно. Однако, я так и не смог найти нормального объяснения как должен работать кросс-доменная технология и JSON, и обратился на stackoverflow.

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

{"foo" : "bar"}

будет выглядеть таким образом:

callback({"foo" : "bar"});

где callback — имя функции, вызываемой в JavaScript на стороне клиента. В случае с jQuery имя этой функции автоматически добавляется в конец строки URL. Фактически при выполнении

$.getJSON("example.php");

URL приобретет вид example.php?=_random_name, где random_name — это функция, в аргумент которой должен быть передан JSON. Таким образом, корректно будет запрашивать скрипт, передавая ему имя этой функции в параметре.

$.getJSON("example.php?callback_name=?");

PHP должен добавить имя этой функции и в нее встроить данные.

<?php
$data=array("1","2");
$callback=$_REQUEST['callback_name'];
print("$callback(".json_encode($data)+");");
?>

Только таким образом удается передать данные кросс-доменно. На основе JSON/JSONP построены API различных онлайн-сервисов, например Flickr или Yahoo Finance. Впрочем, стоит отметить, что отправить запрос POST таким образом не удастся, для полноценного POST придуман другой метод.

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

На сайте производителя есть информация по базовой настройке сервера, я же расскажу как настроить сервер разработчика (development server) на базе ОС Ubuntu 9.10.

Идеология и безопасность.

Фактически Реалплексор это веб сервер, написанный на perl (к сожалению для меня). Он работает параллельно с Apache, ожидая соединения на свой порт, которые никогда (исключений и других правил не касаемся) не закроются. Apache работает над формированием содержимого вашего сайта, по умолчанию слушая порт 80 для входящих соединений.

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

Логично было бы подключаться к Реалплексору просто используя его порт, например так: http://localhost:8088. Однако, производители браузеров подготовили кучу подводных камней и мы сразу же наткнемся на один из них: http://localhost:80 и http://localhost:8088 находятся в разных контекстах безопасности и соединение не пройдет. Это одна из самых известных проблем в AJAX технологии на основе XMLHttpRequest.

К примеру, Firefox порадует нас ошибкой в консоли:

Ошибка: uncaught exception: Due to the standard XMLHttpRequest security policy,
hostname in URL passed toDklab_Realplexor (localhost:8088) must be equals to the
current host (localhost.com) or be its direct sub-domain.

Решение проблемы.

На помощь нам придет чудо-сервер nginx. Рассказ о достоинствах этого сервера — тема для отдельного поста. Нам же, nginx позволит обойти проблему нарушения правил безопасности. Дело в том, что браузер противится соединению по другому порту, однако совершенно не против соединения с поддоменом. Таким образом нам необходимо передать nginx управление соединением и разрулить эту ситуацию.

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

Необходимо настроить Apache на прослушивание не 80 порта, а 8080, для того чтобы освободить 80 для nginx.

Nginx будет рассматривать входящее подключение и в случае, если оно идет на поддомен, выделенный для сервера (пусть будет chat) он передаст соединение на localhost:8088, т.е. Реалплексеру. Иначе соединение уйдет к Apache на localhost:8080 если nginx не настроен иначе.

Специфика локалхоста.

Нельзя забывать, что мы работаем на локалхосте и что для нас хорошо, то немцу смерть на production сервере отвалится. Один из незаметных подводных камней это трактовка поддомена. По правилам HTTP в адресе вида chat.localhost нет поддомена, chat — это домен второго уровня, а не третьего. Поэтому нам необходимо сделать простую вещь: отредактировать файл /etc/hosts следующим образом:

127.0.0.1 chat.localhost.com
127.0.0.1 localhost.com

Таким образом выполняется требование системы безопасности по поддоменам выполняется. И мы спокойно работаем с нашим доменом localhost.com.

Настройка nginx, файл /usr/local/nginx/conf/nginx.conf:

server {
server_name  localhost.com; # Для главного сайта
listen       localhost.com:80; # Запрос, который получет nginx по 80 порту

location / {
proxy_pass http://127.0.0.1:8080; # Передаем обработку Apache
}
}

server {
server_name  chat.localhost.com; # Для поддомена
listen       chat.localhost.com:80; # На таком же порту

location / {
proxy_pass http://127.0.0.1:8088; # Запрос будет обрабатываться Реалплексором
}
}

Теперь необходимо перезагрузить все программы, участвующие в процессе.

sudo apache2ctl restart
sudo /usr/local/nginx/sbin/nginx -s reload
sudo service dklab_realplexor reload

Программный комплекс готов к работе.

Эпилог.

Справедливо заметить, что подобный подход может использоваться и на production-серверах. Использование nginx дает огромные перспективы по масштабированию приложения. Расход памяти составляет около 10 МБ на 1000 одновременных подключений для Реалплексора, а при грамотной настройке nginx на раздачу статики, полученный прирост производительности будет вполне ощутим.

Примеры кода доступны на сайте производителя.

Либо менеджер окон не поддерживает кнопку расчистки рабочего стола, либо менеджер окон не запущен вовсе.

Все приложения при этом выглядят без оконной рамки. Вылечить эту проблему  просто: нужно переустановить Metacity, стандартный оконный менеджер. Ctrl+Alt+F2 для входа в консоль.

sudo apt-get remove metacity
sudo apt-get install metacity
sudo /etc/init.d/gdm restart

После перезагрузки Gnome система примет прежний вид.

Некто запостил ссылочку на этот уютненький бложек в форум ModX-еров. Естественно, хомяки принялись всячески вербовать автора в свои ряды. Не знаю, рассчитывал ли автор на объективность в этом сообществе. Это ведь всё равно, что прийти к вегетарианцам, CRM-щикам или, например, на встречу работников сетевого маркетинга. Любое противоположное мнение вызывает у них адскую попаболь.

Хотелось бы прояснить маленькие детали, просто так, для галочки.

Мне действительно 20, ребята, и я действительно с 14 лет пишу программы. В 14 я продал первую свою разработку на C++. Мой первый язык был С++, а писал я в C++ Builder под Виндоус, сейчас даже смешно вспоминать эту среду, версия 5.0 была у меня первой. Спустя какое-то время я даже получил сертификат разработчика C++ Builder, наивно полагая, что он мне понадобится. Кстати могу дать пруф. Гордиться там особо не чем, сертификат локального масштаба, и я правда даже не знаю где он сейчас, но если кому-то так не верится, то покажу. Года два-три назад от программирования под операционные системы я полностью отошел, переключившись на веб.

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

Например, очень странно слушать человека (с таким опытом!), который говорит что:
1) в сниппете стоит инклуд и потом нужно искать файл, чтобы поменять код сниппета. Ну не делайте так – пишите код сниппета просто в окошко и не нужно будет искать никаких файлов.

Вы не понимаете опять (FUCK! FUCK! FUCK!). Писать код сниппета просто в окошко это феерический идиотизм. Интерпретируемый код должен быть в файле. Всегда. Не в базе данных, не на картинке, не в окошке. В файле. Дайте угадаю? Использовать include? Решение проблемы? Да. Дибильное? Бесспорно. Потому что, есть свод правил разработки, в том числе и под ModX. И если архитектура предусматривает хранение кода в БД, то он там должен быть, как бы это глупо не было. А из-за include нарушается это положение. Поэтому когда один программист делает так, другой сделает иначе, то третий просто сойдет с ума пытаясь после них это всё поддерживать. Это один из доводов только против такого способа.

2) у него проблема вывести тайтл. Разве сложно написать простенький сниппет, который будет выводить все что нужно?

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

Есть идеи по созданию идеальной системы – вперед! Делаем и пользуемся )

Не нравится как поет Тимати? Вперед! Иди попробуй сам спой как он? Не можешь? Тогда не говори, что Тимати — хуйло! Вы все только и можете, что обсирать Тимати, а ему похуй на вас всех, вы просто сами ничего не можете, и не добились того, чего добился он. Попробуйте спойте лучше, попробуйте быть хотя бы таким как он!!!11

Улавливаете аналогию?

Другой персонаж:

php я не знал (и не знаю до сих пор)

Тут я вообще в ступор стал. Ну не знаете, так чего же вы лезете в дискуссию? Я, как мне кажется, со стороны разработчика критику даю, а не со стороны секретарши. Если, вы идиот, и считаете, что

сообразить проинклудить код шаблона из файла и написать соответствующий код сниппета?

это адекватное решение задачи, то как же вы можете трезво давать оценку мне и моим доводам?

В общем, привет всем.

Поскольку я пользователь домашний, и использую Ubuntu, я расскажу как установить и настроить Nessus под этот дистрибутив. Стоит отметить, что на сайте разработчика доступна инструкция по установке, но она слишком запутана.

Скачайте debian пакет со страницы http://www.nessus.org/download/. Разработчик предоставляет очень много сборок для различных операционных систем. На сегодняшний день актуальная версия программы — 4.2.0. Nessus установится в директорию /opt/nessus.

Программа не имеет графического интерфейса в привычном его виде, Nessus управляется через веб-интерфейс. После установки и запуска демона сканера по IP-адресу вашего компьютера станет доступен веб-сервер, который и предоставит графический интерфейс пользователя на основе Flash. К слову, Teneble Network Security предоставляет и другое решение в виде отдельной программы-клиента, но она не так удобна как интерфейс разработанный на Flash. Однако прежде чем получить к нему доступ программу нужно подготовить соответствующим образом.

Первым делом нужно создать учетную запись пользователя Nessus. Делается это с помощью программы

/opt/nessus/sbin/nessus-adduser

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

Следующий этап — регистрация программы. Заполните поля на странице регистрации и вам бесплатно вышлют регистрационный код по электронной почте. Запустите программу, подставив ваш код

 /opt/nessus/bin/nessus-fetch --register XXXX-XXXX-XXXX-XXXX-XXXX

Это важный момент. После этого действия Nessus начнет скачивать свои плагины, без которых он бесполезен. Плагин Nessus — это набор правил и программных кодов, которые будут применяться для детектирования той или иной уязвимости. Первый раз придется немного подождать: плагинов великое множество. По завершению этого процесса Nessus становится полностью работоспособным.

Запуск сервера производится командой

/etc/init.d/nessusd start

Теперь можно открыть браузер и набрать адрес https://127.0.0.1:8834/. Порт 8834 — это порт, по умолчанию используемый сервером. Связь проходит по SSL-защищенному соединению, поэтому принимайте сертификат и в результате увидите приветственное окно Nessus.

Nessus готов к работе!

Все мы знаем какое говно фреймворк, предоставляемый ModX, а так же нам прекрасно известно какое говно шаблонизатор. Любой программист рано или поздно встретится с необходимостью MVC в своем проекте, для той или иной оптимизации процесса.

Лирическое отступление. Рачки и хомячки могут соснуть хуйца, потому как таких среди поклонников ModX over 9000, а вменяемых людей гораздо меньше. Почему-то хомячье страшно ведется на травлю и провокацию. Адекватный программист и ModX — очень редко встречающиеся вещи. Я таких людей знаю не больше 8-10.

Сегодня я расскажу как использовать возможности замечательного фреймворка CodeIgniter совместно с CMS ModX. Условно мы передадим ModX всю «статику»: страницы, заполняемые клиентом или контент-менеджером, а CodeIgniter оставим все динамическое содержимое и логику.

Для начала нужно скачать и установить CodeIgniter. Для того, чтобы привести адреса страниц в нормальный вид (ЧПУ) мы задействуем mod_rewrite, в файл .htaccess нужно добавить вот этот текст:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]
</IfModule>

Такая конфигурация позволит нам избавиться от некрасивых адресов и передать управление всеми страницами фреймворку CodeIgniter. Помимо этого необходимо также настроить CodeIgniter для корректной работы с mod_rewrite, сделав кое-какие изменения в конфигурационном файле. После всех настроек, убедившись в работоспособности CodeIgniter можно устанавливать ModX. Как это делается я пропускаю намеренно, в интернете полно руководств пропагандирующих установку этой CMS, поэтому я не стал вступать в ряды агитаторов. Будьте внимательны, ModX претендует на файл index.php. Переименуйте после копирования всех файлов, index.php в index.md.php.

Для чего это делается. При запросе без дополнительных параметров (example.com) будет вызван скрипт index.php который запускает CodeIgniter. Фреймворк обработает запрос и запустит контроллер, который указан таковым по умолчанию. В случае же запроса с параметром, например example.com/some/test/here также будет предпринята попытка запуска контроллера. Фактически мы передали приоритет обработки запросов фреймворку. Если фреймворк не обнаружит соответствующего контроллера по умолчанию CodeIgniter вызовет ошибку 404. Нам же необходимо, чтобы фреймворк передал запрос CMS, которая будет отвечать на все остальные запросы. Самым легким путем был бы простой redirect на index.php?q=query, однако это лишит систему дружественных путей в адресе и не очень-то обрадует поисковики (сеошники разорвут). Поэтому мы пойдем другим путем и напишем обработчик ошибок для CodeIgniter. Делается это расширением класса CI_Exceptions.

Создайте в папке system/application/libraries файл MY_Exceptions.php (префикс MY_ задается в конфигурационном файле, это обязательный момент, а не моя прихоть) и вставьте в него код:

<?php  if ( ! defined('BASEPATH')) exit('No direct script access allowed');
/**
* Класс MY_Exceptions.
* Заменяет метод класса CI_Exceptions show_404 на пользовательский.
* @author Баштанник А.С.
*/

class MY_Exceptions extends CI_Exceptions {

    /**
    * Обработчик ошибки 404.
    * @param $page String Не найденная страница.
    */
    function show_404($page = '')
    {    
        system('php -r \'$_REQUEST["q"]="'.$page.'"; include("../index.md.php");\'');
    }
}

?>

Это типичная структура пользовательского расширения CodeIgniter. Интересный момент здесь только в вызове функции system. С ее помощью мы вызываем php интерпретатор, CLI-версию, которой передаем код на выполнение. Поскольку ModX берет информацию о запрошенных страницах из элемента массива $_REQUEST (или $_GET, не суть важно) с индексом q, мы присваиваем ему значение запроса, вызвавшего в CodeIgniter 404 ошибку. После чего запускается ModX, и дальнейшая обработка данных передается скрипту index.md.php.

Какие остались подводные камни? Ну во-первых, конечно же алиасы дружественных интерфейсов. Если они совпадут в ModX с именами контроллеров в CodeIgniter мы никогда не проберемся к ним, т.к. контроллеры фреймворка обладают приоритетом по вызову. Во-вторых, доступ к директориям блокирован, то есть он перенаправляется на обработку запроса фреймворком и далее по схеме. Чтобы избежать вызова скриптов при обращении к некоторым директориям в .htaccess нужно добавить строку

RewriteRule ^(manager|assets|images|css|js) - [L]

где указаны в этом случае директории, к которым будет свободный доступ по запросу, например example.com/css вызовет обращение к папке, а не к контроллеру CodeIgniter.

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

Где и для чего это использовать читатель разберется сам. Скажу только, что проблем в этой связке нет никаких и мы наконец-то добились гибкости. Мы можем использовать либо умный и быстрый фреймворк в связке с MVC и отказаться от ModX, либо перенести на фреймворк только логику, оставив ModX отображение данных. Простор для действий. Поживем увидим!

P.S. Обращение к хомячкам. Дорогие хомячки! Официально посылаю вас в жопу, не желаю слышать ваше блаженное фапанье на самизнаетечтоX, не желая выслушивать ни малейшей критики. Хотите поспорить? Милости просим. Если у вас среди аргументов только «Сперва добейся», желаю доброй дороги.

В ModX, в коде модуля нельзя вставлять HTML в нормальном его виде. Хотите нормальный интерфейс модуля? Используйте print/echo!

Для того чтобы сделать такой замечательный, просто чудесный AJAX-интерфейс, без единой строчки PHP, который я прорабатывал два дня мне нужно использовать блять include. ModX предлагает мне сохранить в коде модуля вшивую строчку include, которую она потом засунет в Базу Данных. Кто тут про разделение сущностей говорил?

Это ли не пиздец? Чтобы вытащить графический интерфейс система обратится в БД, вызовет PHP код, который в свою очередь вытащит мой HTML, с прекрасным AJAX-интерфейсом.

Тест на логику, конечно же EPIC FAIL.