Особливості створення елементів керування ActiveX у Delphi
Перевірка if FEvents <> nil є обов'язковою, оскільки клієнтська програма може не підтримувати нотифікаційний інтерфейс, і в цьому випадку спроба виклику неіснуючого методу призведе до виключення.
Для створення обробника подій у HTML-документі скористаємося попереднім проектом. У створений файл AXTest.htm внесемо такі зміни (доданий код виділено жирним шрифтом):
Для роботи зі скриптовими мовами елемент управління повинен мати ідентифікатор ( >), на ім'я якого до нього здійснюється доступ із коду цими мовами. Ім'я обробника події має починатися з ідентифікатора, далі слідує нижнє підкреслення (_), а потім ім'я обробника події, як воно визначено в диспінтерфейс елемента керування ActiveX. Якщо обробник події має параметри, вони теж наводяться.
Електронний підпис, крім відомостей про фірму-виробника, несе й низку іншої корисної інформації. Так, наприклад, якщо файл *.OCX був змінений після додавання електронного підпису, про це буде негайно повідомлено перед запуском такого елемента керування.
Для комерційної розробки елементів керування ActiveX бажано придбати Microsoft ActiveX SDK. Крім детальної документації та ряду корисних ресурсів, він містить програму MAKECER, яка генерує тестові сертифікати.
Таким чином, отримання міжнародного електронного сертифікату в нашій країні становить сьогодні серйозну проблему. У той же час відсутність у користувача електронного підпису призводить або до постійних нагадувань про це (або навіть до заборони на завантаження елементів керування ActiveX при високому рівні безпеки браузера), або змушує його відключити систему безпеки Internet. Звісно, наявність електронного сертифікатане гарантує відсутність потенційно небезпечного вмісту, але принаймні дозволяє клієнту встановити джерело небезпечного вмісту. Крім того, він перекодує файл із використанням сучасних шифрувальних алгоритмів та підраховує контрольні суми. Якщо хтось спробує змінити код елемента керування ActiveX, така спроба буде негайно виявлена за допомогою контрольних сум і цей елемент керування ActiveX не буде працювати в Microsoft Internet Explorer. Тому наявність електронного підпису бажано навіть при роботі в інтрамережах, а при роботі елемента керування ActiveX в Internet вона просто необхідна.
Повернімося до попереднього проекту. Усі тести, описані тут, виконано з Microsoft Personal Web Server 5.0. та Microsoft Internet Explorer 5.0. Рівень безпеки Microsoft Internet Explorer слід встановити рівним Сustom. Значення всіх опцій, що відносяться до елементів керування ActiveX в діалозі, що з'являється при цьому, встановимо рівними Prompt.
">, і скрипт з обробником події OnBtClick, як це описано в попередньому розділі. Потім можна почати тестувати систему безпеки Microsoft Internet Explorer.
Після першого звернення до HTML-сторінці, що містить ActiveX, відбувається його завантаження і копіюється в каталог WINNT\Downloaded Program Files. Далі перевіряється наявність електронного підпису (який у нашому випадку відсутній). Якщо рівень захисту, встановлений у Microsoft Internet Explorer, відповідає Low, користувач отримає повідомлення про те, що може бути запущено на виконання потенційно небезпечного вмісту. Якщо користувач не заперечує проти цього, відбувається реєстрація отриманого файлу *.OCX в системному реєстрі і за допомогою інтерфейсу IPersistPropertyBag зчитуються йоговластивості HTML-сторінки (див. вище). При цьому відновлюється діалог, з якого стає ясно, що хоча наш елемент управління і безпечний, але до нього можуть звертатися зі скриптів (рис. 6). Крім того, слід звернути увагу на опцію Initialize and script ActiveX controls no marked as safe» у діалоговій панелі Security Settings браузера Microsoft Internet Explorer. Хоча значення опції було встановлено рівним Prompt і з HTML-документа проводиться ініціалізація параметра URL, попередження не було отримано. Таким чином, Microsoft Internet Explorer вважає цей елемент керування ActiveX безпечним з погляду ініціалізації даних та виконання скриптів.
Причина цього полягає в тому, що елементи керування ActiveX, створені за допомогою версій Delphi старше 3-ї, підтримують інтерфейс IObjectSafety. У цьому інтерфейсі визначаються два методи:
INTERFACESAFE_FOR_UNTRUSTED_CALLER (= 1, дозволяє анонімний доступ до інтерфейсу)
INTERFACESAFE_FOR_UNTRUSTED_DATA (= 2 дозволяє анонімному користувачеві посилати дані в інтерфейс).
Припустимо, що автор елемента керування ActiveX вважає, що при виконанні скриптів або при некоректній ініціалізації даних цей елемент керування може завдати шкоди клієнтові. У разі він повинен переписати реалізовані методи IObjectSafety. Якщо елемент керування ActiveX реалізований у класі TActiveXControl, то це не складно, оскільки обидва методи IObjectSafety оголошені віртуальними в секції protected. Але для класу-нащадка TActiveForm це зробити неможливо, оскільки активна форма не є нащадком класу TActiveXControl. Щоб змінити методи IObjectSafety в активній формі, необхідно знову реалізувати зазначений інтерфейс. При цьому методи нового інтерфейсу«затіняють» старі і, отже, саме вони викликатимуться клієнтами.
Спочатку слід додати інтерфейс IObjectSafety до списку підтримуваних інтерфейсів TAFTest:
TAFTest = class(TActiveForm, IFilledBox, IObjectSafety)
Далі в секції private визначимо два методи - GetInterfaceSafetyOptions і SetInterfaceSafetyOptions з директивою виклику stdcall, а в секції implementation створимо реалізацію цих методів:
Результат тестування цієї програми відрізняється від попереднього (рис. 7).
У Delphi з елементами керування ActiveX працюють так: спочатку викликається команда меню Component Import ActiveX control, обраний ActiveX поміщається на палітру компонентів, потім він поміщається на форму, а інспекторі об'єктів змінюються властивості і створюються обробники подій. Виникає питання: а як можна ініціалізувати елемент керування ActiveX під час виконання програми - тобто, не реєструючи ActiveX на палітрі компонентів, під час виконання програми створити його робочий екземпляр?
Зі сказаного раніше ясно, що, крім ініціалізації та створенняробочого екземпляра елемента керування ActiveX, для роботи програми потрібно створити VCL-контейнер, куди він буде розміщуватися. Роль такого контейнера в Delphi виконує клас TOleControl, який оголошено у модулі OleCtrls.pas. Базовий метод цього класу – InitControlData. У зазначеному методі необхідно визначити GUID фабрики класів елемента керування ActiveX, кількість обробників подій та посилання реалізованого на клієнті інтерфейсу обробників подій, а також посилання на ліцензійний інтерфейс, необхідний викликів методів IClassFactory2. Метод InitControlData викликається автоматично після відпрацювання конструктора TOleControl.
Створимо новий додаток і в секції Interface оголосимо новий клас-нащадок TOleControl:
Методи InitControlData та EbeggAX реалізуємо наступним чином:
Помістимо на форму кнопку та створимо простий обробник події:
Тепер можна запустити створений додаток і під час виконання натиснути кнопку. Елемент керування ActiveX з'явиться у зазначеній області. Змінивши GUID фабрики класів на , можна побачити інший результат (рис. 8). Як перший, так і другий з тестованих елементів управління не були зареєстровані в палітрі компонентів Delphi. У принципі, так само можна звернутися до будь-якого із зареєстрованих у системному реєстрі COM-серверів, які мають ключ реєстру Control у секції з GUID фабрики класів. Наявність цієї секції гарантує підтримку COM-сервером інтерфейсів IOleClientSite, IOleControlSite, IOleInplaceSite, які необхідні для відображення елемента керування ActiveX на клієнті.