Технология организации удалённого доступа к IB базам

← →
DeepSky © (2004-09-17 17:39) [0]

Уважаемые Мастера, нужен совет по сабжу.
Идея такова - на серваке стоит InterBase"овая БД. Необходимо организовывать к ней удалённый доступ по I-net"у. Кол-во удалённых клиентов - 30. Используемый WEB-cервер - Apache 2.0.49.
Клиентские формы хочеться сделать автономными (т.е. не в броузере), скорее всего используя IBExpress.
Как организовать связь клиентских форм с IB сервером? Никогда не работал по удалённому доступу с базами данных, потому с особой благодарностью будут встречены советы с указанием на документацию по этому вопросу.

← →
Роман Снегирев (2004-09-17 17:49) [1]

а сервер БД на линухе что ли будет крутиться?

← →
DeepSky © (2004-09-17 17:51) [2]

> Роман Снегирев (17.09.04 17:49) [1]
> а сервер БД на линухе что ли будет крутиться?

нет. ОС Windows 2000 Server

← →
Роман Снегирев (2004-09-17 17:55) [3]

ну тогда нет проблем (на самом деле и на линухе не было бы никаких проблем, просто я никогда не работал). Просто в строке подключения компонента TIBDataBase пиши "www.mysite.ru:C:\Base\MyDataBase.gdb" а в остальном все как обычно. Сразу порекомендую использовать не Интербес а FireBird и не IBExpress а FibPlus

← →
DeepSky © (2004-09-17 17:56) [4]

> а сервер БД на линухе что ли будет крутиться?

Собственно, как по мне, это абсолютно не принципиально. Я имею в виду - для моей задачи.

← →
DeepSky © (2004-09-17 18:01) [5]

А без http можно?

← →
Роман Снегирев (2004-09-17 18:02) [6]

а я разве где написал http?

← →
kaif © (2004-09-18 01:10) [7]

Говорят, что такой способ не очень безопасен. Кстати, правильно ли говорят? Я не знаю (слышал об атаках типа заходит юзер и создает внешнюю таблицу от своего имени. А потом заливает ее гигабайтами мусора, пока все не рухнет). Хотя может быть для большинства задач этот уровень безопасности вполне сойдет. Кстати, а зачем Apache в данном случае?
Я лично боюсь открывать Firebird для такого доступа и подумываю о связке Firebird +PHP+Apache. Правда я предпочитаю в качестве клиента иметь все же браузер, а не клиента Firebird + IBX. Тогда поддержку в 30 местах осуществлять не придется. Подправил PHP-скрипты на сервере - вот и вся поддержка.
Но если кто-то напрямую работал с IB через интернет - буду рад услышать лестные отзывы в пользу такого решения. Я лично пока не пробовал...

← →
Роман Снегирев (2004-09-18 10:02) [8]

to kaif
а чем такой способ небезопасен? Ты че типа знаешь пароль сервера (в смысле FB конечно)?

← →
kaif © (2004-09-18 13:48) [9]

Я не знаю и потому спрашиваю. Я много раз в инете сталкивался с разговорами на этот счет. Юзер даже с малыми правами все равно имеет право создавать таблицы. А это в принципе дырка для атаки.

← →
DeepSky © (2004-09-18 13:55) [10]

На счёт безопасности не стоит беспокоиться. Организовум работу юзеров только через временные таблицы и сторед процедуры. И даём юзерам доступ только к ним.

← →
DeepSky © (2004-09-18 14:04) [11]

Кстати, родился ещё один вопрос. Я раньше работал с Ораклом так там была возможность дать доступ юзеру только к Вьюхе с правом Инсерта в таблицы, из к-рых эта Вьюха собираеться. Попробовал в Интербейсе - а, он, подлый выдаёт сообщение, типа: у этого юзверя нет права Инсертать в эту таблицу.
Вожможно ли всё же сделать вышеописаное, и, если возможно, то как.

← →
Роман Снегирев (2004-09-18 15:46) [12]

вообщем сейчас в интербесе права/роли сделаны через ж..., жди выхода Firebird 2

← →
-SeM- (2004-09-18 16:43) [13]

Роман Снегирев (18.09.04 15:46) [12]
Откуда такое умозаключение?

DeepSky © (18.09.04 14:04) [11]
Берем простой вариант: у нас есть две таблицы, на основе которых построен просмотр, который является редактируемым (с пом. триггеров). Есть пользователи SYSDBA(куда нам без него :)), CREATOR (который создает базу), USER1 (который работает с базой), USER2 (он только смотрит).
Первым делом создаем домен SYSDBA - пользователю с таким именем хватит и isc4. В нашей базе ему делать нечего.
Потом убираем ВСЕ права со ВСЕХ таблиц и просмотров (не забываем про "виртуального" пользователя PUBLIC).
Далее раздаем необходимые права свои людям :) : в нашем случае ВСЕ права для USER1 на вьюху, только селект для USER2 на вьюху и ОБЯЗАТЕЛЬНО триггерам вьюхи (с учетом назначения) на таблицы, с которыми они работают.

И что мы после этого имеем? SYSDBA не подключится, CREATOR - имеет полные права, USER1 - все права на работу ТОЛЬКО с вьюхой, USER2 - права ТОЛЬКО на просмотр данных из вьюхи.

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

← →
kaif © (2004-09-18 20:52) [14]

OK
А теперь представим себе юзера, еоторый имеет права инсертить только в эту вьюху (это-то прекрасно). Но юзер подключается с помощью своего ISQL или IBExpert и выполняет всего три команды:

CREATE TABLE FUCKALL(FUCKSTRING VARCHAR(20));

SET TERM ^;
CREATE PROCEDURE INSERT_INTO_FUCKALL_LIKE_HELL
AS
BEGIN
WHILE (1=1) DO
BEGIN
INSERT INTO FUCKALL(FUCKSTRING) VALUES ("FuckAll");
END
END
SET TERM ;^

EXECUTE PROCEDURE INSERT_INTO_FUCKALL_LIKE_HELL;

И дальше (я так думаю) сервер висит.
А можно сделать по миллиону записей с коммитом, если в WHILE счетчик поставить до миллиона и коммиттить после каждого вызова процедуры. От юзеров защищаться смысла нет даже вьюхами. А вот от хакеров чтобы защититься, нужно чтобы IB не позволял создавать новые таблицы. А это он вроде как раз позволяет. Любому юзеру. Я специально не проверял, но мне кажется, что это именно так. Создавший таблицу становится ее OWNER и делает с ней, что хочет. В том числе и инсертит в нее все, что хочет и сколько хочет. А если SYSDBA решит, не останавливая сервер, удалить эту таблицу, то он получит сообщение "table is in use". Так что придется останавливать сервер и удалять руками, потом бакапить и ресторить и писать письма хакеру с просьбой больше так не делать.
Я об этом говорю...

← →
Sergey_Masloff (2004-09-18 21:05) [15]

kaif © (18.09.04 20:52) [14]
Ты прав насчет безопасности. Но это не все. Работа в клиент-серверной идеологии на медленных каналах это ужас. Во всех отношениях. Так работать НЕЛЬЗЯ.

kaif © (18.09.04 01:10) [7]
>Говорят, что такой способ не очень безопасен. Кстати, правильно >ли говорят? Я не знаю (слышал об атаках типа заходит юзер и >создает внешнюю таблицу от своего имени.
Не обязательно так. Можно еще создать временную таблицу из одного поля типа CHAR(1). А в качестве имени файла указать имя файла бд (.gdb). После этого селектом из этой таблицы можно вытащить на клиента ВСЮ базу. Нет, в FB можно запретить в конфиге создание временных таблиц в определенных папках. Но кто-то это делает? ;-)

DeepSky © (17.09.04 17:39)
Извини, но ты несешь пургу. Если у тебя Web-сервер то при чем здесь "формочки". Если ты хочешь с работать с IB просто как с сервером это одно. Если ты хочешь обеспечить работу клиента через WEB - интерфейс то это другое. Если ты хочешь написать свой аналог WEB SNAP то (судя по уровню вопроса) рановато.
Кстати и про временные таблицы... для IB это одно из самых плохих решений.

← →
Роман Снегирев (2004-09-18 23:30) [16]

короче, ребята, лично я всегда безопасность (роли/права/юзеры) реализую на уровне бизнес логики приложения. ИМХО так более удобно и гибго. вообщем я к тому что не надо использовать встроенные возможности сервера БД

← →
Sergey_Masloff (2004-09-18 23:40) [17]

Роман Снегирев (18.09.04 23:30) [16]
>что не надо использовать встроенные возможности сервера БД
Как раз надо. Защита которая не у тебя под боком это не защита. Потому что всегда в твою базу можно коннектнуться не твоим клиентом. Поэтому защита - ТОЛЬКО на сервере, с СУБД или сервере приложений (лучше и там и там).

А бизнес-логика это понятие абстрактное. Может быть вся логика в СУБД. Может быть логика на сервере приложений. Конечно (самый худший вариант) логика может быть и на клиенте.

← →
Роман Снегирев (2004-09-18 23:54) [18]

to Sergey_Masloff
Ну давай, достучись до моей БД (сервера конечно)...

← →
Роман Снегирев (2004-09-19 07:01) [19]

www.it-studio.ru там их до ж... (штук 50 в смысле)

← →
Sergey_Masloff (2004-09-19 07:55) [20]

Роман Снегирев (18.09.04 23:54) [18]

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

← →
Роман Снегирев (2004-09-19 09:36) [21]

я повторяю, что вся безопасность реализоавана н ауровне бизнес-логики
http://www.maslograd.ru/
логин roman
пароль q

← →
Sergey_Masloff (2004-09-19 09:46) [22]

Роман Снегирев (19.09.04 07:01) [19]
Читать умеем?
>Клиентские формы хочеться сделать автономными (т.е. не в броузере),
При чем здесь ASP? У тебя клиент (БД) на сервере же ж ;-) Да и 3050 порт вовне закрыт наверное (если не закрыт лучше все ж закрой)

Теперь читаем
Sergey_Masloff (18.09.04 23:40) [17]
последнее предложение первого абзаца ;-) до полного прояснения.

← →
Роман Снегирев (2004-09-19 10:42) [23]

да читать то умеем, мы вообще о чем говорим? мне казалось что о безопасности. вообщем в чем проблема-то?

← →
Sergey_Masloff (2004-09-19 10:51) [24]

О том что человек хочет клиент-серверной работы через Инет. Ему пояснили что это есть нехорошо. Ты сообщил что нет-хорошо. В доказательство привел пример в котором работа с базой организована СОВЕРШЕННО по другому. Вот и все.
При работе в клиент-серверной архитектуре пароль юзера к базе известен ВСЕГДА. Если безопасность обеспечивается ВНЕ базы это уже дыра. Потому что я с паролем юзера подключусь через isql и буду делать с базой очень много чего нехорошего.

← →
Роман Снегирев (2004-09-19 11:02) [25]

я не буду спорить, я же привел пример, где там дыры?

← →
Sergey_Masloff (2004-09-19 11:09) [26]

Роман, ну почему ты опять не хочешь читать. Ты привел другой пример, на другую тему. Поясню еще раз.
В твоем примере у юзера НЕТ клиента. Защита на сервере (в твоем случае сервере приложения). Поэтому твоя защита работает. Но если у тебя появится необходимость работы не через ASP то тебе придется твою безопасность реализовать второй раз. Потом третий и так далее причем реализуя третий ты придумаешь новую фичу которую забудешь добавить в первые два.

← →
Роман Снегирев (2004-09-19 12:46) [27]

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

← →
Sergey_Masloff (2004-09-19 13:01) [28]

Роман Снегирев (19.09.04 12:46) [27]
Ну, на 90% я работаю действительно с другим сервером... Но с IB стаж работы у меня лет 10 ;-) Там тоже много можно сделать и довольно гибко.
Причем пойми - я тебя не критикую. В случае с ASP твой подход вполне нормальный.

Технология организации удалённого доступа к IB базам Найти похожие ветки