Skip to content

FAQ

Jump to bottom
do- edited this page Jul 2, 2018 · 3 revisions

Table of Contents

Миграция с Eludia.pm

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

Как запускать Offline-скрипты?

Так же, как все остальные действия — через HTTP-запрос.

Например, если в Вашем приложении есть справочник организаций orgs, который требуется обновлять из внешнего источника, то нужно реализовать эту процедуру под именем do_import_orgs и далее инициировать, например, локально с Linux-сервера командой 

 echo '{}' | POST 'http://127.0.0.1/_back_slow/?type=orgs&action=import' -H 'Content-Type: application/json'

(либо при помощи cURL, wget или иного консольного клиента HTTP).

Пропись в cron

Если требуется повторять это действие, например, на 43-й минуте каждого часа, соответствующая строка crontab будет иметь вид 

 43 * * * * echo '{}' | POST 'http://127.0.0.1/_back_slow/?type=orgs&action=import' -H 'Content-Type: application/json' >> /var/projects/my_application/back/logs/error.log 2>&1

Обратим внимание на перенаправление STDOUT и STDERR: попытка запустить процедуру cron'ом запишется в тот же log, что и вся прочая отладочная информация данного приложения.

Аутентификация

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

 data => [
  {id => -1, fake => 0, id_voc_user_domain => 0, ext_id => -1, label => 'Системный процесс'},
 ]

и в таблице sessions: 

 data => [
  {id => 1, fake => 0, id_user => -1},
 ],

Осталось обеспечить распознавание системного пользователя в процедуре [handler]. Простейший вариант — считать системным пользователя, который обращается с локальной машины: 

	if ($ENV {REMOTE_ADDR} eq $ENV {SERVER_ADDR}) {
	
		$_REQUEST {sid} = 1;

		our $_USER = sql (users => -2);

	}
	else {

Использование более продвинутых схем (например, с аутентификацией по клиентскому сертификату) — на усмотрение разработчика.

Куда делась таблица log?

В Eludia.pm БД приложение содержит таблицу log (имя может быть переопределено, но наличие обязательно), куда пишется полный набор параметров каждого запроса на изменение данных (то есть с непустым параметром action).

Это полезный механизм, он не раз помогал найти причины сложных инцидентов и выправить данные, повторив операции с ранее введёнными параметрами, но при исправленной версии прикладного кода.

Однако при таком подходе возникает минимум 2 проблемы:

  • таблица в транзакционной реляционной БД (например, Oracle) плохо подходит для хранения неограниченно растущих редко используемых протоколов. Есть решения специально для data warehousing, но до их использования в Eludia.pm дело не дошло;
  • тот факт, что все параметры каждой активной операции фиксируются помимо воли разработчика (и он практически не может испортить эти данные) имеет досадный побочный эффект в плане безопасности.
Dia.pm параметры в БД не записывает, однако логирование данных приложения предусмотрено.

Для этого предполагается использовать фронтальный сервер (в норме — nginx). Поскольку данные (кроме конфиденциальных) с клиента передаются в телах POST-запросов в формате JSON, то достаточно включить запись этих тел в отдельный файл — и получается полноценная замена таблице log.

Проблема же безопасности решается путём передачи паролей и прочих секретных значений в нестандартных HTTP-заголовках X-Request-Param-${your_param_name} — они в log не попадают. Естественно, это должно быть обеспечено клиентским web-приложением: например, с использованием elu.js.

Полученные таким образом log-файлы можно просто хранить для последующего сканирования grep при необходимости, а можно периодически импортировать в специально для этого предназначенную БД (например, на основе ClickHouse), генерировать оттуда отчёты и т. д. Данная функциональность зависит от конкретного проекта и находится за рамками Dia.pm.

Clone this wiki locally