События

Материал из ISPWiki

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

• (final="yes") Независимые, запускающиеся до или после выполнения функции и никак не влияющие на её результат. Зато, такие обработчики сами могут вызывать функции manager. Обработчик данного типа может быть только типа CGI.
• (before="yes") Запускаемые до выполнения функции. Такие события не могут сами обращаться к manager. Но зато xml, который они возвращают, будет объеденен с тем xml, который сформирует manager. Кроме того, если это событие вернет ошибку, обработчик функции manager вообще не будет вызван.
• (after="yes") Запускаемые после выполнения функции. В случае если это форма, то скрипт будет запускаться и при открытии формы, и при закрытии по кнопке ok. Узнать когда было запущено, можно по наличию параметра sok. Такие события тоже не могут сами обращаться к manager. Но зато xml, который они возвращают, будет объединен с тем xml, который сформирует manager. В отличие от предыдущего типа событий, они будут вызваны только если функция manager завершилась успешно.

При объединении xml, следущие теги имеют особое значение:

• error - означает, что произошла ошибка при обработке события. Никакие теги после этого тега обработаны не будут.
• redirect - перенаправление. Содержимое этого тега будет передано клиенту ввиде javascript. Используется при создании мастеров настройки - пошаговых интерфейсов, где одна формочка сменяет другую. Например: location='ispmgr?func=usrparam' приведет к открытию формочки с параметрами пользователя.
• ok - переопределяет значение тега ok. Если вы повесите этот тег на открытии формы, то форма не откроется, а зависнет.
• param - данные тэги будут проигнорированы.

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

Если обработчик имеет тип XML, то на входе он получает сформированный XML с описание форм, таблиц, и сообщений. На выходе он должен также отдать XML, которым будет полностью заменен тот XML, с которым работает manager. В самом простом случае, можно вернуть тот же XML, который был получен на входе.

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

Чтобы добавить свой обработчик событий, необходимо создать файл с именем ispmgr_mod_имя.xml и следующим содержанием:

<?xml version="1.0" encoding="UTF-8"?>
<mgrdata>
  <handler name="myhandler" type="cgi">
    <event after="yes">eventname</event>
  </handler>
</mgrdata>

и поместить его в /usr/local/ispmgr/etc/

myhandler - имя вашей программы, которая должна быть расположена в каталоге /usr/local/ispmgr/addon

eventname - имя события. Список возможных событий можно получить с помощью функции панели управления eventlist, например, используя mgrctl:

/usr/local/ispmgr/sbin/mgrctl eventlist

Пример

Предположим вы хотите, чтобы пользователь после выхода из панели попадал на вашу домашнюю страницу (например: ispsystem.com).

Для этого вам необходимо создать следующий XML-документ, описывающий ваш обработчик события logon:

<?xml version="1.0" encoding="UTF-8"?>
<mgrdata>
	<handler name="redirect" type="xml">
		<event after="yes">logon</event>
	</handler>
</mgrdata>

Затем создать сам обработчик addon/redirect:

#!/bin/sh
 
if [ $SESSION_LEVEL -ne 0 ]; then
	echo '<?xml version="1.0"?>'
	echo '<doc><redirect>location="http://ispsystem.com"</redirect></doc>'
else
	cat
fi