#oracle #grails #licensing #oracle10g
#Oracle #grails #лицензирование #oracle10g
Вопрос:
У нас есть веб-приложение (Grails), лицензии на которое мы собираемся продавать в зависимости от количества пользователей. В базе данных (Oracle 10g) есть таблица, в которой хранятся пользователи. Клиенты будут размещать свою собственную копию программного обеспечения и базы данных. Может ли кто-нибудь предложить стратегии для ограничения количества записей, которым разрешено существовать в пользовательской таблице, способом, который не может быть разумно нарушен клиентом? Спасибо.
Ответ №1:
Вам следует, по крайней мере, рассмотреть возможность отказа от всех технических средств здесь и вместо этого настаивать на том, чтобы ваш клиент подписал SLSA с условием аудита, а затем проводил аудит здесь и там.
Все эти технические средства влекут за собой риски сбоев, начиная от внезапных сбоев и заканчивая загадочными проблемами с производительностью. Чем скрытнее и изворотливее, тем более скрытными и коварными будут ошибки.
Комментарии:
1. Очень интересное предложение @bmargulies, определенно есть над чем подумать.
2. В соглашениях убедитесь, что вы настаиваете на регулярном — ежегодном — аудите, который проверяет использование. Это предотвращает странные побочные эффекты и позволяет пользователю расти, что хорошо для пользователя и для вас, если у вас есть средства для этого. Аудит сработает. Oracle делает это, и это не всегда удобно, но это работает.
Ответ №2:
Это будет зависеть от вашего определения «разумно». Если они размещают базу данных, они всегда смогут разрешить больше строк.
- Самым простым возможным решением был бы триггер ОПЕРАТОРА AFTER, который подсчитывал количество строк и выдавал исключение, если было вставлено слишком много строк. Они могли бы, конечно, удалить или отключить этот триггер. С другой стороны, ваше приложение также может запросить словарь данных, чтобы убедиться, что триггер присутствовал и был включен.
- Вы могли бы усложнить им удаление триггера, создав триггер DDL, который искал инструкции, которые влияли на этот триггер или таблицу, о которой идет речь, и запрещал их. Для этого злоумышленнику потребуется также найти и удалить этот триггер, прежде чем он сможет удалить триггер в таблице.
- Вы могли бы доставить задание базы данных (
DBMS_SCHEDULERилиDBMS_JOB), которое периодически выполнялось, искало инструкцию и триггеры DDL и повторно создавало их, если они отсутствовали. Злоумышленник мог выяснить, что было задание базы данных, которое воссоздавало объекты, и удалить это задание, затем удалить триггер DDL, затем удалить триггер инструкции. В этом задании вы могли бы потенциально отправить вам уведомление (по электронной почте или http или что-то еще), предупреждающее вас о проблеме, хотя это может быть сложно с точки зрения сети — брандмауэр вашего клиента может не разрешать исходящие HTTP-запросы с сервера базы данных обратно на ваши серверы. - Если у вас есть лицензионный ключ, который проверяется, вы можете встроить количество разрешенных пользователей в этот лицензионный ключ и сопоставить его с количеством строк в таблице во время таблицы входа.
Комментарии:
1. Спасибо, Джастин! Это несколько отличных идей. Мне нужно будет провести некоторое исследование лицензионных ключей, есть ли у вас какие-либо предлагаемые ресурсы?
Ответ №3:
Если у клиента нет доступа для изменения определения таблицы, вы могли бы использовать простой набор ограничений для таблицы:
CREATE TABLE user_table
(id NUMBER PRIMARY KEY
,name VARCHAR2(100) NOT NULL
,rn NUMBER NOT NULL
,CONSTRAINT rn_check CHECK (rn = TRUNC(rn) AND rn BETWEEN 1 AND 30)
,CONSTRAINT rn_uk UNIQUE (rn)
);
Теперь столбец rn должен принимать целое значение от 1 до 30, а дубликаты недопустимы: таким образом, может быть добавлено максимум 30 строк.