О ПОСЛЕДНИХ ИСПРАВЛЕНИЯХ И ДОПОЛНЕНИЯХ В WEB ИРБИС

Введена поддержка актуализации при выполнении команды R - запись в БД.
(В версии WEB ИРБИС64 актуализация записи поддерживалась)
Поддерживается (как и в WEB ИРБИС64 5.2) скрипт-защита.
Исправлена ошибка в раскраске найденых терминов.
Эта ошибка была и в WEB ИРБИС64 5.2
Исправлены ошибки форматирования группы записей, которые могли приводить к зависаниям шлюза (только в WEB ИРБИС32).

(Спасибо Кириллу Соколинскому - Северо-Западный государственный заочный технический университет)

На ftp.gpntb.ru/pub/irbis выложен файл upgrade_web32_52.zip с исправленой версией шлюза WEB ИРБИС32.


Исправлена ошибка (только в WEB ИРБИС32) в файле \frames_r\ibis\main\search_search.frm
(режим экспорта найденной порции записей из текущей БД отличной от IBIS)

строку:<input type="hidden" name="I21DBN" value="IBIS"> необходимо заменить на 2-ве строки:

<!FORMAT='<input type=','"','hidden','"',' name=','"','I21DBN','"','value=','"',v2221,'">'>

<!FORMAT='<input type=','"','hidden','"',' name=','"','P21DBN','"','value=','"',v3331,'">'>

(Спасибо Светлане Калюжной ЦНБ Владивостока)


В версию WEB ИРБИС32 6.1 добавлены форматы из WEB ИРБИС64
1 показа и поиска новых поступлений
2 меню в виде списка БД
3 меню выбора вида словаря и алфавита для быстрого доступа

Добавлены краткие описания видов поиска для читателей

Версию WEB ИРБИС 6.1 можно получить через группу договоров
924 90 42

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

1. НЕРАБОТОСПОСОБНОСТЬ ОГРАНИЧИТЕЛЯ <.> В ГИПЕРССЫЛКАХ (ЗАПРОСАХ ПО МЕТОДУ GET). Это было главной неожиданностью, в особенности потому, что в формах(POST) они продолжали работать. Конечно, возможность использовать двойные кавычки вместо <.> полезна. Тем не менее, можно привести 6 причин по которым отсутствие у кавычек альтернатив приводит к серьёзным проблемам.

А) Двойные кавычки являются ограничителями литералов в ИРБИС скрипте. Наложение литералов и ограничителей требует переделки форматов.
Пример неработоспособной ссылки:

<!FORMAT='<a href="/cgi-bin/irbis32r/cgiirbis_32.exe?
C21COM=F&I21DBNAM=PODB&I21DBN=PODB&Z21ID=',v5,
'&S21ALL=("ZI=',f(mfn,0,0),'"+"ZP=',f(mfn,0,0),'"+"ZO=',f(mfn,0,0),'"+"ZV=',
f(mfn,0,0),'"+"ZF=',f(mfn,0,0),'")', '&MODE=L', '&MFN=',f(mfn,0,0), '&S21FMT=fullwebrP', '">'>

Б) Двойные кавычки стандартными являются ограничителями в ссылках. Т. е. <a href="/cgi-bin/irbis32r/cgiirbis_32.exe?C21COM=F&I21DBNAM=PODB&S21ALL=("DP=2005'')"> работать не будет. Механический подход к замене <.> на “ приведёт к ошибкам.

В) Двойные кавычки используются в Java Script. Здесь ситуация даже хуже чем в случае со ссылками. Достаточно представить себе случаи динамической генерации кода гиперссылки... Можно привести в качестве примера динамически генерируемый алфавит - очень распространённое и оправданное решение.

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

Д) Двойные кавычки и апострофы очень плохо смотрятся вместе, а в форматах такая комбинация является весьма распространённой.

Ж) В большинстве гиперссылок версии 2005.2 сохранились <.>!



Отправка отредактированного (13-04-06 03:10)

2. ИЗМЕНЕНИЯ В РАБОТЕ ФУНКЦИИ &UF('+3S. В русском языке есть два вопроса, характеризующих результаты поиска: ЧТО и СКОЛЬКО. Если соотнести их с функциями ИРБИС, то можно сказать, что на вопрос СКОЛЬКО отвечает функция &unifor('J'), которая возвращает количество ссылок на термин, а на вопрос ЧТО - функция &unifor('D'), которая возвращает результат поиска по термину.

Функция &uf('+3S несомненно отвечает на вопрос ЧТО и, следовательно, должна возвращать при неудачном поиске NULL. Так, собственно и было вплоть до новой версии, где она начала возвращать "0" уже в форме символа.

Так вот, логическая некорректность этого столь же очевидна, как и ответа на бытовой вопрос: «Что нашел в библиотеке?» -- «Ноль».

Впрочем, надо заметить, что никакого существенного значения эти изменения в работе функции не имеют. Только пользователи новой версии, при неудачном поиске, будут видеть в нижней части своего окна цифру «0», а опытным ирбисоводам придётся корректировать код.

3. НЕКОРРЕКТНЫЕ HTTP ЗАГОЛОВКИ. Константин Олегович, поверьте, что не может быть такого HTTP заголовка, как Content-Encoding: WINDOWS-1251! Я уже писал о том, что некоторые версии IE 6 реагируют на него подписанием. Сюда нужно вписывать метод сжатия!
Приведу выдержку из спецификации HTTP/1.1:

entity-body := Content-Encoding( Content-Type( data ) )

Content-Type specifies the media type of the underlying data.
Content-Encoding may be used to indicate any additional content
codings applied to the data, usually for the purpose of data
compression, that are a property of the requested resource. There is
no default encoding.

3.5 Content Codings
Content coding values indicate an encoding transformation that has
been or can be applied to an entity. Content codings are primarily
used to allow a document to be compressed or otherwise usefully
transformed without losing the identity of its underlying media type
and without loss of information. Frequently, the entity is stored in
coded form, transmitted directly, and only decoded by the recipient.
content-coding = token
All content-coding values are case-insensitive. HTTP/1.1 uses
content-coding values in the Accept-Encoding (section 14.3) and
Content-Encoding (section 14.12) header fields. Although the value
describes the content-coding, what is more important is that it
indicates what decoding mechanism will be required to remove the
encoding.
The Internet Assigned Numbers Authority (IANA) acts as a registry for
content-coding value tokens. Initially, the registry contains the
following tokens:
gzip An encoding format produced by the file compression program "gzip"
(GNU zip) as described in RFC 1952 [25]. This format is a Lempel-
Ziv coding (LZ77) with a 32 bit CRC.
compress
The encoding format produced by the common UNIX file compression
program "compress". This format is an adaptive Lempel-Ziv-Welch
coding (LZW).

Encoding действительно не причем - убрал его
С ограничителем <.> ошибок не наблюдаю - возможно проблема в кодироке термина запроса

На ftp.gpntb.ru/pub/irbis обновлен файл upgrade_web32_52.zip с исправленой версией шлюза WEB ИРБИС32.

Функция &uf('+3S немного расширена и исправлена:

+3S<dbn>,NDOcs,<"termin">,<@имяформата|формат>

Теперь если NDOcs=0 то возвращается ТОЛЬКО количество найденных
Неважно задан формат или нет
Это применяется в многобазовом поиске - search_mnu.pft
Если NDOcs > 0 в случае 0 результата поиска вернется пустота

КОД ФОРМАТА search_mnu.pft
----------------------------------------
&uf('+1W2#',v1009)
&uf('+1W3#',v2226),
&uf('+1W4#',v2221),
&uf('+1W5#',&uf('+3E',v2225)),
&uf('+1W6#',v3331),
if p(v2224) then &uf('+1W7#',v2224) else &uf('+1W7#20') fi,


&uf('+1W8#'),
(if &uf('+5Tdbn_web.mnu')<>'' then
if &uf('+1R6')= &uf('+5Tdbn_web.mnu')
then
else
&uf('+1W9#',&uf('+3S',&uf('+5Tdbn_web.mnu'),',0,','|',&uf('+1R3'),'|',',')),
if val(&uf('+1R9'))>0 then
&uf('+1W8#1'),break,fi,
fi
else break fi),


if &uf('+1R8')<>'' then
'<table border=0 cellpadding=0 cellspacing=2 bgcolor=#FFFFFF width=100%>',
'<TR>',
'<TD VALIGN=TOP class=inp1><center>',
'Поискать то же самое в базе данных:',
'</center><td>',
(if &uf('+5Tdbn_web.mnu')<>'' then
if &uf('+1R6') = &uf('+5Tdbn_web.mnu')
then
else
&uf('+1W9#',&uf('+3S',&uf('+5Tdbn_web.mnu'),',0,','|',&uf('+1R3'),'|',',')),
if val(&uf('+1R9'))>0 then
'<TD VALIGN=TOP>',
'<div align=','"','center','"',' class=','"','sub1','"',' onMouseMove=this.className=','"','sub2','"',' onmouseout=this.className=','"','sub1','"', '>',
if &uf('+1R6')=&uf('G1_',&uf('+1R4'))
then &uf('+1W1#',&uf('+5Tdbn_web.mnu')),
else
if (&uf('G1_',&uf('+1R4'))='_EX') or (&uf('G1_',&uf('+1R4'))='_PROF')
then &uf('+1W1#',S(&uf('+5Tdbn_web.mnu'),&uf('G1_',&uf('+1R4')))),
else &uf('+1W1#',&uf('G1_',&uf('+1R4'))),
fi,
fi,
'<a href=','"','/cgi/irbis32r/cgiirbis_32.exe?C21COM=S&I21DBN=',&uf('+1R1'),'&P21DBN=',&uf('+5Tdbn_web.mnu'),'&S21FMT=',&uf('+1R2'),'&S21ALL=',&uf('+3E',&uf('+3U',&uf('+1R3'))),'&Z21ID=',&uf('+1R5'),'&S21STN=1','&S21REF=10','&S21CNR=',&uf('+1R7'),'">',
if &uf('+5Fdbn_web.mnu')<>'' then &uf('+5Fdbn_web.mnu') else &uf('+5Tdbn_web.mnu') fi,
' (',&uf('+1R9'),')',
'</a>','</div></td>',
fi,
fi
else break fi),


'</tr></table>',
fi

&uf('+1W1#')
&uf('+1W2#')
&uf('+1W3#'),
&uf('+1W4#'),
&uf('+1W5#'),
&uf('+1W6#'),
&uf('+1W7#'),

В обновлённой версии никаких проблем с ограничителем <.> нет. Проблема со знаком + в запросах. Та же самая ошибка присутствовала в 2005.1, но 2005.2 она была устранена. В гиперссылках + воспринимается системой только в URI кодировке. Это доставляет массу неприятностей.

Хочу обратить внимание, что моя система полностью под WIN:
FRAMES_CHAR_SET=WINDOWS-1251
QUERY_CHAR_SET=WINDOWS-1251
Как это работает в UTF-8 я не знаю.

Пожалуйста, проведите откат функций кодировки к состоянию предыдущей редакции. Всё, связанное с кодировкой работало в ней вполне удовлетворительно.

Проблемы возникали только с функцией &uf('+3S, которая не воспринимала запросы с кириллическими терминами, и выходной кодировкой <!FORMAT.

С <!FORMAT ничего особенно неприятного не происходило; только без ! он возвращал результат в UTF-8, что было не вполне логично. Конечно, в дальнейшем было бы неплохо добавить алгоритм, по которому при
FRAMES_CHAR_SET=WINDOWS-1251
результат расформатирования вообще бы не перекодировался, ни с !, ни без него, но всё это пустяки.


> С ограничителем <.> ошибок не наблюдаю - возможно проблема в кодироке термина запроса

Согласитесь, что если термин в этой кодировке воспринимался в первой редакции 2005.1, то должен был бы восприниматься и во второй.



Отправка отредактированного (13-04-06 14:41)

>В гиперссылках + воспринимается системой только в URI кодировке. >Это доставляет массу неприятностей.

Дело в поведении Browser
+ перекодируется при передаче по GET из формы в пробел и ничего с этим сделать нельзя
Таким образом следует поддерживать принятые правила передачи спец символов
Форматы перекодировки &uf(+3E - &uf(+3D теперь работают с учетом этого факта
То есть допустимыми символами являются
const ValidURLChars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';
Тогда как раньше этот список был
const ValidURLChars = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789$-_@.&+-!*"''(),;/#?:';

Эта проблема не только 32 но и 64 ИРБИС и мне пришлось менять все форматы где формировались запросы по ИЛИ (например в навигаторе по УДК это ссылки смотри также) чтобы в любой момент можно было не зависеть от вида запроса из формы при передаче параметров из ссылок в форму и обратно

Константин Сбойчаков писал(а):

> >В гиперссылках + воспринимается системой только в URI
> кодировке. >Это доставляет массу неприятностей.
>
> Дело в поведении Browser
> + перекодируется при передаче по GET из формы в пробел и
> ничего с этим сделать нельзя

Если дело в браузере, то ПОЧЕМУ В ПРОШЛОЙ РЕДАКЦИИ 2005.2 ССЫЛКИ РАБОТАЛИ, А В ЭТОЙ - НЕТ? Ещё раз подчёркиваю, что речь идёт о работе с WIN кодировкой. Я провёл эксперименты с профессиональным поиском, применяя оператор «+». Поиск абсолютно нормально функционирует как с методом POST, так и c методом GET. Без всяких дополнительных функций перекодировки. Это проверено в 2 браузерах и работает как со старой, так и с новой редакцией 2005.2. Результаты эксперимента прямо противоречит вашему утверждению, согласно которому профессиональный поиск с методом GET (или, говоря иначе, поиск по запросам с «+») вообще работать не может.

Запрос (<.>K=arg1$<.>)+(<.>K=arg2<.>)
выглядит вот так при передаче из формы по методы GET:
%28%3C.%3EK%3Darg1%24%3C.%3E%29%2B%28%3C.%3EK%3Darg2%3C.%3E%29
И вот так, будучи написанным в гиперссылке:
%28%3C.%3EK=arg1%24%3C.%3E%29+%28%3C.%3EK=arg2%3C.%3E%29

Вывод 1. При работе с формой браузер автоматически перекодирует «+» в URI, а при работе с гиперссылками осуществляется только частичная перекодировка.
Вывод 2. При использовании метода GET происходит перекодировка «+» не в пробел - %20, а в %2B.
Вывод 3. Все проблемы, связанные с перекодировкой и обусловленные особенностями работы браузера могут быть только побочным следствием использования UTF-8. Применение кодировки WIN-1251 позволяет их избежать, при использовании алгоритма первой редакции 2005.2.
Вывод 4. То, как будет обрабатываться строка запроса зависит от WEB IRBIS, а не от браузера.

Ещё раз повторяю: необходимо или вернуть применявшийся в старой редакции 2005.2 алгоритм обработки параметров, или предусмотреть его использование его только при установленной WIN кодировке.



Отправка отредактированного (13-04-06 19:18)

А К Т У А Л И З А Ц И Я____Н Е____Р А Б О Т А Е Т! ! !

Согласно информации Администратора, в базе нет ни одной неактуализированной записи, но в словарях изменения не отображаются! После создания словаря заново всё приходит в норму. WEB отображает информацию с учётом последних дополнений. . . Я корректировал пути, закидывал FST во все папки; ничего не помогало. 1_R21IFP=1, всё что можно проверено.. .

Я был готов ко всему, но . . .

Уважаемые коллеги - владельцы WEB 32! Большая просьба, протестируйте, пожалуйста, работоспособность актуализации!



Отправка отредактированного (14-04-06 12:05)

файловая система на серваке наверное NTFS. Советую капнуть в этом направлении. У меня такая де истерика в свое время была. Решилось выдачей прав на изменение.

Я тестирую не на сервере, а на домашней машине с FAT.
Сомнения рассеиваются. Актуализация действительно не работает.



Отправка отредактированного (14-04-06 12:08)

Все проще - второпях как следует не проверил и вот
Ошибка!!!!!!!
в чтении файла isisuсw.tab приводила к неверной перекодировке символов в верхний регистр.
Возьмите обновление еще раз - все проверено в отладке - термины добавляются в словарь через fst из БД.

Уфф!!! Заработало...

СКРИПТ-ЗАЩИТА. (тем, кому это понятие ничего не говорит, советую просмотреть форум «Проблема безопасности в WEB IRBIS, или Жизнь на пороховой бочке»). Поскольку я не располагаю никакой документацией на эту функцию, мне сложно выносить какие-то окончательные суждения. Всё сказанное ниже является только результатом эксперимента.

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

PARNAME30=R21MFN
PARTAG30=6666

И в CGIflc.pft прописал:
if p(v6666) then else '1' fi,

Если бы поле 6666 что-то содержало, то должно было быть выведено сообщение об ошибке и команда записи не была бы выполнена. Увы, при записи, поле не получало никакого значения. Ситуацию изменило добавление конкретного префикса, используемого при записи:

PARNAME30=P_R21MFN

Вывод: контроль возможен только за содержанием тех параметров записи, которые были зарегистрированы в INI файле. Таким образом, если вы записываете в запись 20 полей, то должны создать в INI файле около 60 новых параметров.

Можно ли будет контролировать запись после создания 60 параметров? Конечно нет: ведь хакер может просто изменить префикс параметров и это сделает возможным использование 61, 62, 63-го и так далее параметров, не учтённых в ИНИ! Таким образом, если защита будет использовать указанный подход, то она абсолютно бессмысленна! Получается, что я даром написал трёхстраничное сообщение по поводу представления параметров сложной структуры в ветке «Безопасность WEB IRBIS... ». . .

Часть 2. Впрочем, если предположить, что WEB IRBIS будет работать так как он должен работать, то защиту всё-таки можно организовать. Как мы знаем, скрипт способен создавать параметры, которые в дальнейшем будут использоваться CGI. Фактически все параметры, за исключением тех, которые содержат записываемые данные(эти можно просто переименовать) могут генерироваться скриптом.

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

[RDR_REC]
FRAMES=C:\irbis\web\frames_r\RDR\
RecUpdateFrames=header_z.frm,Mode_select.frm,RESULT,final.frm,footer_z.frm
DBName=RDR

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

Допустимо предположить, что можно сделать запись безопасной, динамически определяя параметры записи в скрипте. Тем не менее, мои эксперименты показали, что этот способ не функционирует.

Создаём в CGIflc.pft строку:
'I21DBN=RDR_PASSWORD'

При отсутствии(а лучше бы даже при наличии) параметра с именем базы, она должна была динамиечески создавать его, но этого не происходит. На самом деле создаётся не ПАРАМЕТР, который определяет работу модуля, а лишь МОДЕЛЬНОЕ ПОЛЕ v1, которое никак на функционирование модуля не влияет! В сущности, с не меньшим успехом можно передавать и изменять значения полей и в любом другом формате. Для это не требуется ФЛК, выполняемый перед до начала выполнения команды!

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

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

Чтобы обеспечить работоспособность скрипта защиты нужно сделать хотя бы одну из двух вещей:
1. Предусмотреть ЗАМЕЩЕНИЕ ПАРАМЕТРОВ, переданных пользователем на параметры, сгенерированные в скрипте.
2. Обеспечить доступ скрипту ко всем сложным полям, отвечающим за запись.

PS
Уважаемые коллеги! Если у вас используется база читателей и хотя бы одна база открыта на запись, и вы уверены в своей безопасности, полагая, что всё, здесь написанное вас не касается, то я готов доказать вам, что вы ошибаетесь. Только оставьте адрес своего каталога. ;)

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

Что же можно сделать если все-таки решиться открыть бд на запись из Интернета?
Во-первых, определить набор БД, куда будет идти запись (для ИРБИС в случае удаленного заказа это БД RQST -Если туда накинуть мусора плохого ничего не будет).
Нельзя открывать на запись Каталоги - если необходимо все-таки внедрить режим удаленной записи - создайте отдельную БД специально для этой цели.
Во-вторых, с помощью скрипт-защиты можно запретить чтение информации из RDR (или другой БД типа RDR так как сейчас можно в WEB ИРБИС использовать любое имя БД для авторизации в отличие от Ирбис Читателя).
Режим записи работает только под авторизацией.
Как запретить чтение из RDR?
Проверять I21DBN P21DBN и затребованные форматы и команды и отсекать лишние.

Есть возможность работать в скрипт-защите с IP адресом клиента
URLTag=1100

Действительно скрипт-защита работает с виртуальными полями а не с параметрами запроса - это неудобство можно преодолеть если ввести какие-то соглашения о соответствиии неучтенных в ИНИ параметров и меток виртуальных полей
Допустим скидывать дополнительные параметры в повторение поля 9999 или начиная с какой-то метки - я пока не знаю что тут сделать

Скрипт-защита работает так - если первый символ 0 или формат вернул пустоту - значит сработала защита - во всех остальных случаях - все нормально
Пришел параметр I21DBN если он неверный можно его тут же заменить

if v2221<>'IBIS' then 'I21DBN=IBIS'/'P21DBN=IBIS' else '1' fi
Так что сайт будет стоять все время на стандартном поиске в БД IBIS

Впрочем так как эта тема пока остается не совсем ясной
Принимаю к рассмотрению любые предложения

Константин Сбойчаков писал(а):

> Пришел параметр I21DBN если он неверный можно его тут же
> заменить
>
> if v2221<>'IBIS' then 'I21DBN=IBIS'/'P21DBN=IBIS' else '1'
> fi

В том то и дело, что приведённый пример у меня не работает.
Запись в первой строчке CGI:

'I21DBN=NWPIB'

ничего не меняет. База продолжает изменяться.

Если бы он работал, это было бы очень хорошо. Кстати, хотелось бы узнать, почему в новой версии вы изменили метки модельных полей?

> Логическая защита на уровне скрипта никогда не может гарантировать уровень конфеденциальности, который дает система.

Эта проблема на протяжении нескольких месяцев обсуждалась в ветке «Безопасность WEB. . . » затем на закрытом форуме, доступ к которому вы получили. Совместными усилиями были определены базовые средства защиты. Было доказано, что необходимый уровень безопасности достижим ЭЛЕМЕНТАРНЫМИ средствами, которые, к сожалению, могут быть реализованы только в CGI.

Теперь я ещё раз попробую подробно расписать способ защиты, который кажется мне самым простым и универсальным.

ЗАМЕНА ПЕРЕДАВАЕМЫХ ПАРАМЕТРОВ
Забудем о том, что параметры записи не доступны из скрипта. Ведь он может формировать их самостоятельно!

В INI файле регистрируем параметры

PARNAME27=MODE
PARTAG27=10
PARNAME28=REC_STR
PARTAG28=20

Допустим, мы пишем в базу только в двух случаях: при подписке на рассылку и при заказе на удалённую доставку. В первом случае MODE будет принимать значение 1, во втором - 2. Что касается параметра REC_STR, то в него будут записываться те значения, которые вводит пользователь.

В скрипте защиты CGIflc.pft пишем следующее:

If v10=’1’ then
'I21DBN=RDR_PASSORD', /* Этот псевдоним базы данных не известен пользователю
'C21COM=R',
'MODE=1'
'P_R21MFN=0'
'P_R21IFP=1'
'P_R21UPD=1'
'P_R21NUM1=4000'
‘P_R21VOL1_1=’,v20
else
[случай записи 2]
fi,


Таким образом, через CGI мы определяем практически все параметры записи, скрывая их от пользователя. В данном случае, секретным параметром является I21DBN=RDR_PASSORD.

Если пользователь тоже передал какие-то свои значения R21NUM1, то они должны УДАЛЯТЬСЯ и ЗАМЕНЯТЬСЯ на те, которые были сформированы скриптом.

Впрочем, необходимо предусмотреть и случай, когда параметры скрипта добавляются к параметрам пользователя. Для этого ЗАМЕНЯЮЩИЕ параметры можно записывать в неизменной форме, а к ДОПОЛНЯЮЩИМ - прибавлять особый префикс. Амперсанд(&), например.
Т. е. дополняющий параметр будет выглядеть:
'&P_R21NUM1=4000'

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

В чем же тут защита?
Любой запрос типа &MODE=1&S21STR=ЧТО УГОДНО
будет писать в "секретную" базу данных

>Если пользователь тоже передал какие-то свои значения R21NUM1, то они должны УДАЛЯТЬСЯ и ЗАМЕНЯТЬСЯ на те, которые были сформированы скриптом.

Так сейчас так и есть - но это касается только параметров перечисленных в ини


Мне кажется в шлюзе нужно контролировать только параметры доступа а контроль содержания полей можно передать autoin.gbl
(Кстати autoin.gbl пока не поддерживается в шлюзе - это тоже требует времени)
Еще вариант - можно разрешить(через ини) только одну запись (один R21MFN) и брать параметры записи из скрипта -
даже можно отсечь дополнительные (неучтенные) поля пользуясь свойствами команды записи - если встретится 0 метка - чтение полей прекращается
Поставив в скрипт R21NUM10=0 мы получим возможность записывать только 9 полей

Константин Сбойчаков писал(а):

> В чем же тут защита?
> Любой запрос типа &MODE=1&S21STR=ЧТО УГОДНО
> будет писать в "секретную" базу данных

1. Поскольку название базы неизвестно пользователю, он не сможет, самостоятельно осуществить запись. Он будет он знать, куда это можно сделать.

2. Что угодно будет записано только в то поле(подполе), которое будет ОПРЕДЕЛЕНО в СКРИПТЕ, и только в ту запись, которая будет ОПРЕДЕЛЕНА В СКРИПТЕ. (например, я хочу писать постоянные запросы в запись пользователя базы RDR, а не куда-то ещё)

Таким образом, запись будет осуществляться только «всем пакетом» с параметрами скрипта, или вообще никак, поскольку пользователю псевдоним открытой базы неизвестен.

Это все можно сделать
Но я-то думал что RDR и все другие БД кроме специальной будут закрыты на запись правами шлюза

> >Если пользователь тоже передал какие-то свои значения
> R21NUM1, то они должны УДАЛЯТЬСЯ и ЗАМЕНЯТЬСЯ на те, которые
> были сформированы скриптом.
>
> Так сейчас так и есть - но это касается только параметров
> перечисленных в ини

ЗАМЕНА ПАРАМЕТРОВ ПОЛЬЗОВАТЕЛЯ НА ПАРАМЕТРЫ СКРИПТА, ДАЖЕ ЕСЛИ ОНИ ПЕРЕЧИСЛЕНЫ В INI НЕ РАБОТАЕТ. Я выше я привёл пример с 'I21DBN=NWPIB'.

> Мне кажется в шлюзе нужно контролировать только параметры
> доступа а контроль содержания полей можно передать autoin.gbl
> (Кстати autoin.gbl пока не поддерживается в шлюзе - это тоже
> требует времени)

Насколько я знаю, Wcglobal.exe имеет достаточно простой набор параметров.

> Еще вариант - можно разрешить(через ини) только одну запись
> (один R21MFN) и брать параметры записи из скрипта -
> даже можно отсечь дополнительные (неучтенные) поля пользуясь
> свойствами команды записи - если встретится 0 метка - чтение
> полей прекращается
> Поставив в скрипт R21NUM10=0 мы получим возможность
> записывать только 9 полей


Во- вторых, чтобы разрешить запись хотя бы в 10 полей, каждое из которых будет иметь 5 подполей, в INI файле потребуется зарегистрировать 50 параметров, соответствующих уникальным меткам. Это допустимое, но некрасивое решение.

Константин Сбойчаков писал(а):

> Это все можно сделать
> Но я-то думал что RDR и все другие БД кроме специальной будут
> закрыты на запись правами шлюза

Если вы это сделаете, то будет прекрасно.

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

ПРОВЕРКА ПЕРЕДАННЫХ ПОЛЬЗОВАТЕЛЕМ ПАРАМЕТРОВ ЗАПИСИ

Один из вариантов решения этой задачи был настолько подробно расписан мной в ветке «Безопасность Web. . .», что я не буду на нём останавливаться и рассмотрю другой подход.

__Введение__

Параметры записи в ИРБИС имеют сложную иерархическую структуру. Это обеспечивает возможность одновременной записи в несколько номеров, несколько полей и подполей.
Графически её можно представить следующим образом:

1_R21MFN
___1_R21NUM1
______1_R21VOL1_1
______1_R21VOL1_2
______1_R21VOL1_3
___1_R21NUM2
______1_R21VOL2_1
______1_R21VOL2_2
______1_R21VOL2_3

2_R21MFN
___2_R21NUM1
______2_R21VOL1_1
______2_R21VOL1_2
______2_R21VOL1_3
___2_R21NUM2
______2_R21VOL2_1
______2_R21VOL2_2
______2_R21VOL2_3

R21MFN - опрееделяет MFN записи
R21NUM - номер поля
R21VOL - значение подполя. (метку подполя я для простоты опустил)

>Если бы он работал, это было бы очень хорошо. Кстати, хотелось бы узнать, почему в новой версии вы изменили метки модельных полей?

Потому-что основой является дистрибутив WEB ИРБИС64
С незначительными изменениями набор фреймов и форматов подходит и к WEB ИРБИС32
Метки я поменял в WEB ИРБИС64 раньше чтобы они не мешались с полями RDR и Каталога - теперь обновился WEB ИРБИС32

Действительно я пока тестировал скрипт на WEB ИРБИС64 там происходит замена параметров и все работает как я написал выше
Видимо есть все-таки разница в работе алгоритмов (хоть код и переноситься но...)

__Способ представления__

Отразить трёхуровневую иерархию в полях ИРБИС крайне сложно, поэтому можно использовать принципы построения реляционных баз данных.

В ИНИ файле создаём параметры без префиксной и суффиксной части:
PARNAME27=R21MFN
PARTAG27=1000
PARNAME28=R21NUM
PARTAG28=2000
PARNAME29=R21VOL
PARTAG29=3000
PARNAME29=R21SUB
PARTAG29=3001

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

#1000/1:_200 /* 200 - это номер записи в базе

#2000/1:_^A1^B4000 /* ^a - префикс номера MFN ^b - номер поля
#2000/2:_^A1^B4001

#3001/1:_^A1^BA /* ^a - идентификатор повторения v2000 с номером поля. ^c - метка подполя
#3001/2:_^A1^BB
#3001/3:_^A2^BA

#3000/1:_^A1^BЗначение подполя для поля 4000 /* ^a - идентификатор повторения v2000 с номером поля. ^c - строка для записи.
#3000/2:_^A1^BЗначение второго подполя для поля 4000
#3000/3:_^A2^BЗначение подполя для поля 4001

Это выглядит сложно? Да. Но этого требует безопасность.


__Проверка__

В скрипте защиты CGIflc.pft пишем:

/* Проверка метки поля и допустимого MFN. В данном случае, это запись пользователя.
if s((if ‘4000 4001’:v2000 then else 'ERROR' fi))='' and v1000=f(mfn, 0, 0) then ‘1’ else ‘0’ fi,

(немного оптимизировал, чтобы обойтись без глобальной переменной)

Аналогичным образом проверяем любые другие поля.



Отправка отредактированного (15-04-06 13:42)

Константин Сбойчаков писал(а):

> >Если бы он работал, это было бы очень хорошо. Кстати,
> хотелось бы узнать, почему в новой версии вы изменили метки
> модельных полей?
>
> Потому-что основой является дистрибутив WEB ИРБИС64
> С незначительными изменениями набор фреймов и форматов
> подходит и к WEB ИРБИС32
> Метки я поменял в WEB ИРБИС64 раньше чтобы они не мешались с
> полями RDR и Каталога - теперь обновился WEB ИРБИС32

> Действительно я пока тестировал скрипт на WEB ИРБИС64 там
> происходит замена параметров и все работает как я написал выше
> Видимо есть все-таки разница в работе алгоритмов (хоть код и
> переноситься но...)

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

Т.е. при передаче скриптом параметра 'I21DBN=NWPIB' сервер осуществляет поиск в NWPIВ, но модельное поле сохраняет старое значение - ELIB, например

<!FORMAT='<input type="hidden" name="I21DBN" value="' v1 '">'>

Необходимо, чтобы изменялись и модельные поля.



Отправка отредактированного (14-04-06 18:24)

Что-то я не понимаю, к чему такие сложности. В скрипте защиты просто прописываются условия, в которых выполнение команды возможно. Например можно зашить список допустимых логинов для записи. Этого достаточно. Можно так же запретить запись тех параметров, которые в форме не предусмотрены. В общем, я лично не вижу этих проблем. Правда я и не экспериментировал пока. Но пробовал для теста пару условий - все работает так, как мне нужно.
Просьба к Кириллу: приведите хотябы один пример, когда такая навороченая защита нужна?

Панев Максим писал(а):

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

Вот именно этого сделать и нельзя. Параметры **R21VOL** просто недоступны для скрипта. Если даже вы пропишете в своём INI файле параметр 1_R21VOL1_1, то останется ещё необозримое множество 2_R21VOL1_1, 1_R21VOL2_1 и т. п., которые может послать пользователь, чтобы вместе с подконтрольной записью совершить совершить неконтролируемую запись в другие MFN или другие поля.

Кстати, Константин Олегович ошибся, предположив, что можно ограничить в INI некий диапазон параметров записи, при выходе за пределы которого будет срабатывать защита. Ведь если суффиксы для обозначения метки поля и подполя - номера порядковые(R21NUMi), то префиксы могут быть произвольными алфавитными или цифровыми символами.

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

Таким образом, даже если мы «не по программистски»(используя ваше удачное выражение) зарегистрируем в INI диапазон в 50 параметров, взломщик всё равно сможет выйти за пределы этого диапазона и вписать(стереть) в нашу базу всё, что ему заблагорассудится.

Поэтому я настаивал на необходимости обеспечить перезапись значениями скрипта ВСЕГО ряда повторяющихся параметров. Т.е. по меньшей мере, скрипт должен уметь не просто добавлять значения R21NUM, но ещё и затирать те, которые были посланы пользователем, независимо от их префикса и суффикса.

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

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

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

При этом должны быть обеспечены ограничения по:
1. MFN(пользователь должен получить право писать только в свою запись)
2. Номеру поля(чтобы пользователь не мог удалить записанную на него литературу)

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



Отправка отредактированного (14-04-06 20:17)

Думаю открывать RDR на запись не нужно - более того пользуясь скрипт-защитой надо закрыть RDR даже на чтение (без авторизации)
Достаточно сделать рабочую БД и вписывать туда нужную информацию + ФИО Читателя для связки с RDR