Нове в 8i: повноваження пред’явника в PL / SQL, Інтеграція додатків і даних, Бази даних, статті

Версія Oracle 8i (8.1), випущена в 1999 році після довгих затримок, містить великий обсяг нововведень (як стверджує сама фірма, “більш 150”). Багато хто з них торкнулися такої базової компоненти, як PL / SQL. Незважаючи на появу у розробника альтернативи у вигляді Java (кажуть, у фірмі Oracle довго сперечалися з приводу перспектив вибору мови програмування для системи, але, врешті-решт, прийшли до Соломонову рішенням), PL / SQL залишається найбільш ефективним вбудованою мовою в Oracle, перевершуючи за своїми можливостями аналоги конкурентів – Informix 4GL і Sybase / Microsoft Transact-SQL. Тим прикріше, що деякі якості PL / SQL з’являються тільки зараз, у версії 8.1, а не були вбудовані 10 років тому, в результаті чого розробники виявилися позбавлені, здавалося б, природних можливостей і витрачали свої зусилля на придумування хитрощів, нині позбавлених сенсу. Особливо прикро, коли мова йде про синтаксичних конструкціях, вичерпуються всього парою слів, але змінюють, незважаючи на це, значну частину архітектури створюваного коду.

Одне з таких “мікро-нововведень”, що наближають логіку функціонування коду на PL / SQL логіці виконання програм в Unix, розглянемо сьогодні. Мова йде про так званих “повноваженнях пред’явника” (invoker rights) для процедур на PL / SQL.
 
 

Повноваження створив, перш єдині

У версіях 7 і 8.0 єдиною логікою контролю доступу до об’єктів БД з процедури на PL / SQL була логіка “повноваження створив” (definer rights). Процедура завжди створюється від якого-небудь імені користувача Oracle. Викликатися вона може і іншим користувачем (володіють на це правом, даним за допомогою пропозиції GRANT EXECUTE), але при спробі працювати з об’єктами БД – таблицями, послідовностями – права на доступ до цих об’єктів в попередніх версіях відповідали повноважень творця процедури. (Зараз це вірно тільки за замовчуванням, якщо спеціально не обумовити іншу схему роботи). Ось деякі властивості такої моделі повноважень:


Така логіка роботи має певні переваги. Ось, приблизно, як їх формулювали у фірмі Oracle:


Звучить розумно.
 
  Проблеми з повноваженнями створив

Тим не менш, 90% розробників зізнаються, що використання моделі “повноважень створив” доставляє їм безперервну головний біль через необхідність придумувати спеціальні хитрощі, в кінцевому рахунку негативно позначаються на архітектурі створюваної системи.

Ось типовий випадок. Нехай створюється система за схемою “центр – територіальні відділення”. Всі територіальні відділення (ТО) однорідні по суті і працюють з одними і тими ж програмами, але кожне зі своїми власними даними. Нехай все обслуговується одним сервером БД (наприклад, робота йде через Internet). Тоді логічно (і правильно з точки зору безпеки і розмежування доступу) дати кожному ТО по самостійного імені в БД та за окремою схемою даних. Інша справа, що схеми ці будуть у всіх однакові. І однаковим повинен бути код програм, що працюють з даними.

Для коду напрошується (логічно правильне) рішення: створити окрему схему БД, скажімо, з ім’ям COMMON, і в ній створювати самі PL / SQL-пакети та процедури. Але як ними будуть користуватися ТО? Звернутися до процедури просто new_employee ТО не може, оскільки процедура йому не належить. Звернутися COMMON.new_employee теж не можна, тому що схема COMMON не володіє даними викликає ТО, а крім того поміщати в код програми ім’я схеми теж не завжди правильно.

Раніше в таких ситуаціях доводилося копіювати пакети з COMMON в схеми ТО (див. малюнок) – у багатьох відносинах не найкраще рішення, але часто єдино прийнятне.


 
 

Повноваження пред’явника

Синтаксис вказівки повноважень пред’явника надзвичайно простий: у заголовку процедури або функції перед словом IS або AS треба написати AUTHID CURRENT_USER. (Відповідно з’явилося варіантне вказівку AUTHID DEFINER вступає в силу за відсутності вказівок). Модель прав пред’явника працює за такими правилами:


/* Basic demonstration of AUTHID CURRENT_USER feature */

CONNECT demo/demo
CREATE PROCEDURE dummy1 IS
BEGIN
DBMS_OUTPUT.put_line (“Dummy1 owned by demo”);
END;
/
GRANT execute on dummy1 to public;
CONNECT scott/tiger
CREATE PROCEDURE dummy1 IS
BEGIN
DBMS_OUTPUT.put_line (“Dummy1 owned by scott”);
END;
/
GRANT execute on dummy1 to public;
CREATE PROCEDURE dummy2 AUTHID CURRENT_USER
IS
BEGIN
dummy1;
END;
/
GRANT execute on dummy2 to public;
EXEC scott.dummy2
CONNECT demo/demo
SET serveroutput on
EXEC scott.dummy2

Результати виклику dummy2 від імені SCOTT і від імені DEMO різні.

Зовсім по-іншому буде виглядати тепер схема використання програм територіальними відділеннями (див. малюнок).


 
 

Яку модель коли використовувати?

Застосування моделі “повноважень пред’явника” можливо і в інших ситуаціях, крім наведеної. Воно корисно, коли адміністратор (або хто-небудь з розробників) створює програми загального призначення для всіх користувачів. Ось ще одна проста ілюстрація з Стівена Фойерштайна:

CREATE OF REPLACE PROCEDURE runddl (ddl_in in VARCHAR2)
AUTHID CURRENT_USER
IS
BEGIN
EXECUTE IMMEDIATE ddl_in;
END;
/

EXECUTE IMMEDIATE – ще одне нововведення версії 8i, що вимагає особливої ​​розмови, тут же важливо, що ми маємо можливість дати всім користувачам загальну і корисну процедуру, не обтяжуючи себе кухнею перевірки прав. Вся відповідальність за коректне поводження з даними лягає на користувача, який викликав процедуру.

Але повернемося до переліку “переваг моделі повноважень створив” вище. Він не втрачає своєї актуальності, і відмовлятися від цієї моделі повністю було б нерозумно. Очевидно, що дещо запізніле нововведення Oracle додає розробнику не одну, а дві додаткові можливості для побудови архітектури програмної системи: окрім можливості використання чистої моделі повноважень створив (як раніше) з’являється і можливість використання чистої моделі повноважень пред’явника, і можливість комбінованого використання обох моделей. Останній варіант – найбільш неоднозначний в плані конкретної реалізації, так як теоретично охоплює всі можливі комбінації поділу / усуспільнення (в “центральній” схемою) даних і поділу / усуспільнення коду. Вибір з цієї множини конкретної комбінації для своєї завдання повинен бути зроблений розробником зважено і відповідально.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*