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

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

В третьих, если предполагается, что скрипт защиты действительно должен от чего-то защищать, а не выступать в качестве декорации, на подобии рубрикатора ГРНТИ в версии 2005.1, то опять же, какой смысл поднимать вопрос о том, "должно ли всё работать правильно, или не должно"?



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

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

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

Если бы скрипт защиты действительно заменял параметры, эта проблема была бы легко разрешимой.
Добавляем в INI:
PARNAME30=Z21FLAGID
PARTAG30=1098

И в CGIflc.pft:
'Z21FLAGID=1'

Увы, это не работает. Система не начинает требовать обязательного ввода фамилии, как должна была бы.

Посмотрев резюме А.А.Лавриновича, подытоживающее обсуждение ошибок WEB IRBIS, я пришел к выводу, что людям, которые не работают с системой или же используют её старые версии, очень сложно разобраться в тех проблемах, которые здесь обсуждаются. Поэтому решил более популярно изложить суть того, о чём здесь идёт речь.

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

К.Соколинский: Замок, который сейчас используется, ни от чего не защищает. Достаточно повернуть ручку и дверь откроется. Это небезопасно и не даёт возможности хозяевам оставлять квартиру, где находятся ценные вещи.

К.Сбойчаков: Никакой замок от воров не спасёт. Ведь если они придут, то уже ничего сделать нельзя. («Логическая защита на уровне скрипта никогда не может гарантировать уровень конфеденциальности, который дает система. Что же можно сделать если все-таки решиться открыть бд на запись из Интернета?»)

К.Сбойчаков: Дверь в хорошую квартиру лучше сразу заколотить гвоздями. А для воров нужно оставить открытой прихожую. Если туда накидают мусора, то ничего плохого не будет.
(«Во-первых, определить набор БД, куда будет идти запись (для ИРБИС в случае удаленного заказа это БД RQST -Если туда накинуть мусора плохого ничего не будет).»)



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

К.Сбойчаков: Если всё-таки нужно, чтобы дверь открывалась, то можно завести ещё одну квартиру, где нечего будет украсть. Эту квартиру можно вообще не запирать.
(«Нельзя открывать на запись Каталоги - если необходимо все-таки внедрить режим удаленной записи - создайте отдельную БД специально для этой цели.»)

К.Сбойчаков: Замок работает так: если не поворачивать ручку, то дверь закрывается очень хорошо.
(«Скрипт-защита работает так - если первый символ 0 или формат вернул пустоту - значит сработала защита - во всех остальных случаях - все нормально»)

К.Сбойчаков: Впрочем, я так и не понимаю, что нужно сделать, чтобы дверь надёжно запиралась.
(«Впрочем так как эта тема пока остается не совсем ясной.»)

К.Соколинский: Для того чтобы дверь надёжно запиралась, нужно исправить замок!

PS
Ну разве этот диалог хуже чем у Беккета? ;)
Продолжение следует. . .



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

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



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

Вот попал на тему и радилось еще одно соображение: я так понимаю, что подразумевается следующий механизм
1. Браузер формирует запрос серверу.
2. Запрос направляется в cgiflc.
3. Если cgiflc возвращает не 0 или не пусто, то вперед с песнями дальше.

А если логику изменить? Ведь ФЛК - это формат. А значит он возвращает данные. Так почему не сделать так: все параметры передаются в ФЛК. Далее для работы используется то, что вернул ФЛК. Т.е. есть ли он возвращает путоту, значит все параметры зарезаны на корню и работа завершается.
В этом случае мы дальше в цепочку можем послать вообще все. Единственное, что смущает, это парамеры с переменными именами. Следовательно, нужно вводить какую-то унификацию для них.
К примеру: обращение к переменым параметрам
(if v8765^n = 'P03' then if v8765^v = 'K=' then v8765^p,v8765^n'=DS=' fi fi)
в примере я подразумеваю следующее
поле v8765 cсодержит все переменные поля со следующим разделением:
подполе ^p - порядковый номер параметра (к примеру '003'), т.е. то, что идет до S21.
подполе ^n - имя параметра (к примеру 'P03'), т.е. то, что идет после S21 до знака =.
подполе ^v - значение параметра (к примеру 'K=').
Номер метки поля, куда писаться переменные парам етры задается в ини. Метки подполей для хранения разбитых параметров так же задаются в ини. Алгоритм разбивки параметров можно вынести в RegExp. Все что RegExp'у не соответствует, то отбрасывается.

Вот так вот все складно у меня получилось :).

В общем-то по логике мы получаем ТВП. Только вот это не ТВП, а формат. Не вижу ничего сложного в реализации такого механизма. Зато все эти рассуждения, что были выше, более чем вписываются в схему.
Нужно мне запретить запись в RDR, я так и пишу
if v2221='RDR' and v2222='R' then 'C21COM=F' fi

Еще раз поясню идею. Параметры шлюзу приходят именуемые. Он их преобразует в метки полей и засылает в ФЛК. ФЛК делает из них обратно строковые параметры и опять пропускает через механизм преоразования к меткам. Конечно двойная работа, но не думаю, что это сильно увеличит время работы ЦГИ.

ЗЫ. формат

&uf(|DRDR,!RI=|v1002|!,(if p(v112) then if (v112=&uf('+1R1'))or(v112='*.*.*.*') then &uf('+1W2#1'),break,fi fi)|)

что за новая функция break? Опять что-то не документированное. Чувствую я, что за горами моя мечта, когда весь ISIS-язык форматирования будет переработан. Не удивлюсь, если он станет объектно-ориентированным :). Это, кстати, еще одна моя мечта :)



Редактировано 1 раз. Последний раз 28.09.2006 20:46 пользователем Панев Максим.

Собственно так сейчас и работает
Наприме см в ддистрибутиве формат cgiflc.pft

'1'/
if v3331='IBIS' then
'SCRIPT_DONE=YES',
fi

Он возвращает на 1-й строке 1 безусловно - значит все в порядке
И если параметр соответствующий полю v3331 (P21DBN) = IBIS
устанавливает значение параметра SCRIPT_DONE=YES
Это значение действительно при форматировании и составлении фреймов