Главная страница
    Top.Mail.Ru    Яндекс.Метрика
Форум: "Базы";
Текущий архив: 2003.03.24;
Скачать: [xml.tar.bz2];

Вниз

Вход под одним логином   Найти похожие ветки 

 
Genzzz   (2003-01-25 22:36) [0]

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

Это можно поправить ?


 
Sergey Masloff   (2003-01-26 00:09) [1]

Ничего странного, стандартное поведение. Поправлять это не надо. А в чем, собственно, проблема?


 
Genzzz   (2003-01-26 00:47) [2]

Не то, чтобы проблема - просто хочется, чтобы под одним аккаунтом мог находится только один человек в однои и тоже время.

P.S. А в MSSQL тоже самое ?


 
mad0max   (2003-01-26 10:18) [3]

Конечно, обрабатывай ручками если что не нравиться...


 
Tsr   (2003-01-26 11:13) [4]

А я даже не представляю что обрабатывать...


 
Tsr   (2003-01-26 15:18) [5]

Как сделать, так, чтоюы запретить вход ?


 
Shulc   (2003-01-26 16:32) [6]

Создаеш справочник пользователей(Login,pasword...). При входе в прогу запрашиваешь это все, проверяешь существование в справочнике пользователей, если все верно, блокируешь запись пользователя в справочнике. При входе в прогу, проверяшь, запись блокирована или нет. Ну, а дальше сам.


 
Tsr   (2003-01-26 18:09) [7]

хм. Не понимаю. Ты предлагаешь все хранить в файле ?

Ну так файл только для одной машины сгодится. А чтобы под этим логином никто с другим машин не зашел как сделать ?


 
Ich Hasse   (2003-01-26 22:15) [8]

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

2 Shulc Ну с password"ом ты погорячился


 
Tsr   (2003-01-27 01:17) [9]

А-а-а. Вы хотите наложить ограничения со стороны клиента...

А мне надо ограничение со стороны сервера...


 
mad0max   (2003-01-27 05:57) [10]

Штатной проверки средствами сервера по -моему нет, так что придется самостоятельно написать процедурку (например), и вызывать ее после коннекта. А уж последствия обрабатывай как хочешь....


 
Reindeer Moss Eater   (2003-01-27 10:30) [11]

Не то, чтобы проблема - просто хочется, чтобы под одним аккаунтом мог находится только один человек в однои и тоже время.

Один и тот же логин и его пароль знают несколько человек?
Пробовать устранять этот недостаток средствами сервера или клиента?

А если навести порядок в администрировании ?


 
mad0max   (2003-01-27 12:34) [12]

to Reindeer Moss Eater

Почему бы двум администраторам одновременно не смотреть в базу?
:)


 
Reindeer Moss Eater   (2003-01-27 13:45) [13]

mad0max
Мне вообще непонятна печаль автора вопроса.

Почему бы двум администраторам одновременно не смотреть в базу?
Ради бога. Хоть тысяча администраторов одновременно.
Но зачем им пользоваться одним и тем же логином?


 
JibSkeart   (2003-01-27 14:44) [14]

Странно а почему бы и нет ...


 
Reindeer Moss Eater   (2003-01-27 15:33) [15]

Странно а почему бы и нет ...
Странно для тех, кто забыл, зачем нужны логины и пароли


 
Соловьев   (2003-01-27 15:42) [16]

Сделай 3-х уровневую БД, а там ручками на сервере сделай проверку при коннекте клиента : IP, Login, Password Море фантазии...


 
Tsr   (2003-01-27 18:34) [17]

Ой, ну под трехуровневую сейчас это геморорй переделывать...

Reindeer Moss Eater
проблема в том, что если засечена попытка войти в базу под одним аккаунтом в одно время - создается предупреждение. А как реализовать - не знаю

mad0max
Штатной проверки средствами сервера по -моему нет, так что придется самостоятельно написать процедурку (например), и вызывать ее после коннекта. А уж последствия обрабатывай как хочешь....

Вызывать процедуру ? Из клиента ? Нет...

нужно что-то типа тригерра, я так думаю, который срабатывает после коннекта сразу. Также еще вроде в interbase есть таблица, где прописаны те, кто в данное время подключен (по крайней мере, IBConsole может это узнать).
Если есть такая таблица - подскажите название плиз.


 
Deniz   (2003-01-27 18:58) [18]

По поводу справочников - это ЗРЯ, потому как если поставить блокировку и потерять connect, то user НИКОГДА больше не зайдет (если админ не поправит).
Есть предложение руками с event"ом
1. Коннект к базе.
2. Регистрация на event и post event "UserName".
3. Обработка event"ов "UserName".
4. Решение о возможности коннекта.
Обработка должна проверять количество event"ов, т.к. получит еще и свой.
При аварийном завершении программы или потере коннекта, проблем с повторным подключением не будет.
В любом случае нужно экспериментировать
Удачи,
Денис.


 
Victor_Cr   (2003-01-27 19:46) [19]

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

INSERT INTO LOG_TABLE (USER_NAME,LOGON_TIME,TXT_VERB)
VALUE (user,"now","вход(выход или другое действие)");

Спасти тебя это не спасет, но зато будешь знать кто и когда входил.


 
Tsr   (2003-01-27 21:42) [20]

Ну буду знать кто входил, используя мой клиент... а не допустим IBconsole

Никто не знает имя таблицы, где хранятся пользователи, использующие сейчас базу ?


 
Reindeer Moss Eater   (2003-01-28 08:41) [21]

Какая беда должна исчезнуть, если в одно и то же время не будут подключены одинаковые пользователи ? (От чего хотим избавиться иными словами?)


 
Tsr   (2003-01-29 17:36) [22]

Reindeer Moss Eater, это правда так важно ? Я же говорю - ничего такого особенного. Просто логика использования базы подразумевает, что человек может быть в базе только один. И если их два - то значит кто-то у кого-то спионерил аккаунт.
Я, конечно, понимаю, что вы мне предлагаете идти по пути наименьшего сопротивления (ака ленивый бык) - нифига не делать, если это не архиважно. Но я так не люблю работать

Помогите, если кто знает как


 
Johnmen   (2003-01-29 17:45) [23]

>Tsr

Представь, что ты спионерил кредитную карточку и суешь ее в банкомат, при этом пользуясь спионеренным кодом...
Так вот, банкомату побарабану, кто пихает карточку !
Он не смотрит, правильный чел или нет.


 
Tsr   (2003-01-29 23:45) [24]

Johnmen, очень здорово что ты привел такой классный пример, только я не понял его.

Johnmen, а вот еще, знаешь что. Если ты подделаешь документы ФСБ"шника - то тебя менты на машине не будут проверять, а сразу отпускать. Представь ? Он не будет проверять - есть ли в ФСБ такой агент или нет


 
Reindeer Moss Eater   (2003-01-30 08:58) [25]

Я, конечно, понимаю, что вы мне предлагаете идти по пути наименьшего сопротивления (ака ленивый бык) - нифига не делать, если это не архиважно.

Ты совсем не понял, что я тебе предлагаю.
Кроме того "ака" - это совсем не синоним слова "как". И в контексте сказанного тобой неприменим.


 
passm   (2003-01-30 10:00) [26]

Tsr (29.01.03 23:45)> Тогда используй дополнительные средства аутентификации пользователя (отпечатки пальцев, радужная оболочка глаза...) :)
Но представь другой механизм: есть торговая система, где для пользователей разделены права на создание/проведение торговых/хозяйственных операций. Есть цепочка поставок/перемещений... Так вот, что если пользователь имеет право на проведение какой-либо операции, которая порождает последовательность поставок/перемещений, содержащую операции на которые у него нет прав? Цепочки реализуются посредством DCOM-сервера. Выход - создание суперпользователя с наличием прав на все операции, DCOM-сервер логинится под его аккаунтем и проводит цепочку. Итак, получаем, что несколько коннектов к базе данных под одним пользователем нам просто необходимо.


 
Sheriff   (2003-01-30 10:14) [27]

2Tsr
как Вам такой вариант:
- работаю с базой в IBConsole
- проверяю программу в Delphi
все это одновременно.
мне что 2 аккаунта заводить?


 
Reindeer Moss Eater   (2003-01-30 10:36) [28]

Реализовал Tsr (допустим) то, что хотел. Радуется.
Пришел на работу сотрудник, который знает логин и пароль другого сотрудника, который тоже придет, но позже.
Соединился первый сотрудник с базой данных используя логин второго сотрудника и сидит, ждет что будет.
Пришел на работу второй сотрудник, который не знает никаких логинов и паролей, кроме своего логина и своего пароля. Стал соединяться с базой данных второй сотрудник, да не тут-то было. Явилось ему сообщение программы в котором говорилось ему, второму сотруднику, что не можно быть ему залогонену сейчас, ибо уже залогонен один пользователь с таким именем.

Итог : на автоматизацию чего-то это совсем не похоже. Второй юзер хочет и должен работать, но не имеет возможности. Требуется администратор, который будет принимать решение и выполнять ручные опреации (дропать сессии, оттаскивать пользователей от компьютеров и т.д.)
Мораль: Зачем?


 
alex-xxc   (2003-01-30 11:12) [29]

Можно взять IBDatabaseInfo и у Database.AfterConnect пишем:


if IBDatabaseInfo.UserNames.IndexOf(USER_NAME)>=0 then
//пользователь уже подключен, закрываем коннект,
//ругаемся и т.д.



 
Genzzz   (2003-01-30 18:03) [30]

Вот блин. Люди, вы странные какие-то ужас. Я говорю, что хочу реализовать. Вам обязательно знать, зачем это ? Вы здесь всех так допытываете. Если вы можете помочь - помогите. А не приводить дурацкие примеры. Reindeer Moss Eater, если под одним аккаунтом войдут два сотрудника - будет создано предупреждение, аккаунт аннулирован до окончания разбирательств кто у кого что украл. И вообще, я не хочу вас всех убеждать, что мне это нужно. ПОверьте на слово, что нужно. Наверное, я лучше понимаю, что надо делать в моей базе ?

alex-xxc, как понимаю, ты предлагаешь опять же сделать это на стороне клиента. А нужно на стороне сервера.


 
Sergey13   (2003-01-30 18:38) [31]

2Genzzz (30.01.03 18:03)
Если у тебя такие требования к секретности, то твои взгляды нужно обратить в сторону платного ПО. Оракл например. За дешево сердито бывает редко.


 
Genzzz   (2003-01-30 23:44) [32]

1) В Оракле это легко реализуемо ?

2) А как эт овсе таки в IB/FB сделать ?


 
Александр С.   (2003-01-31 07:34) [33]

Решений множество, но не чисто серверных:
1. Клиент имеет грант ТОЛЬКО на получение имени роли (через СП или вид).
Сами клиенту о ролях догадываться и не должны.
Подключение к серверу не с помощью клиентской программы ему ни чего не даст.
Подключение с помощью клиентской программы происходит в два приема:
I подключение без роли и получение ее имени.
II подключение с именем и ролью.
Для роли установлены гранты, которыми теперь пользователь может также пользоваться.
Так же на сервере происходит блокирование подключения пользователя с таким именем.
При попытке нового коннекта с таким именем оповещается админ с помощью POST EVENT.

2. Клиент привязан к машине, и клиентская программа помимо пользователя передает при логине помимо имени-пароля IP адрес. Сервер проверяет 3 составляющих и пускает либо нет клиента.
Любая не клиентская программа передавать адрес не будет.
Подобных заморочек можно придумать еще, но одному серверу не потянуть.


 
Sergey13   (2003-01-31 08:31) [34]

2Genzzz (30.01.03 23:44)
>1) В Оракле это легко реализуемо ?
Количество сессий на клиента - легко - через использование профиля. Там вообще много чем можно порулить. Практически всем. Но и отвечать за все придется самому.


 
passm   (2003-01-31 10:16) [35]

Genzzz (30.01.03 18:03)> Ничего странного.
Перечитай <Genzzz (25.01.03 22:36)>


 
Max Zyuzin   (2003-01-31 10:49) [36]

>Genzzz (30.01.03 23:44)
А чем вам не нравится такой вариант? Victor_Cr © (27.01.03 19:46) ИМХО вполне приемлимо...


 
passm   (2003-01-31 10:56) [37]

Max Zyuzin © (31.01.03 10:49)> Подходит только если организовать второе соединение с БД на уровне DirtyRead и запустить транзакцию, которая заканчивается при выходе из приложения. Иначе при аварийном выходе - останется "привет" от прошлого соединения.
Но все это противоречит тому, что необходим только один коннект с БД. А тут их минимум два.


 
Max Zyuzin   (2003-01-31 11:04) [38]

>passm © (31.01.03 10:56)
Ну второй конект производится только для того, что бы определить, есть ли первый... Если есть сразу отваливаемся...

А на счет аварийных выходов, это да... проблемма...


 
passm   (2003-01-31 11:18) [39]

Max Zyuzin © (31.01.03 11:04)> Потому и предлагаю:
НАЧАЛО ПРИЛОЖЕНИЯ:
Database1.TransIsolation = tiDirtyRead
ЕСЛИ есть запись о регистрации - вываливаемся
ИНАЧЕ стартуем транзакцию, вносим запись о регистрации, открываем второй Database2
КОНЕЦ ПРИЛОЖЕНИЯ:
Закрываем Database2
Database1.Rollback

ЗЫ: Сам не пробовал :)


 
Genzzz   (2003-02-02 11:24) [40]

passm
при всем написанном вся проверка на стороне клиена, что не есть ГУД.


 
Desdechado   (2003-02-02 18:20) [41]

не совсем по теме, но, может, придут еще мысли по мотивам
http://www.volny.cz/iprenosil/interbase/ip_ib_isc4.htm

а список подключенных юзеров можно в компонентах IBX через TIBDatabaseInfo прочитать


 
Tio   (2003-02-04 00:46) [42]

Блин, а как посмотреть список подключенных юзеров на стороне сервера ?
не нету там ни IBX, ни BDE :-)

Desdechado, спасибо за ссылку, пойду глядеть


 
Genzzz   (2003-02-04 00:46) [43]

Блин, а как посмотреть список подключенных юзеров на стороне сервера ?
не нету там ни IBX, ни BDE :-)

Desdechado, спасибо за ссылку, пойду глядеть


 
Johnmen   (2003-02-04 01:20) [44]

Для этого есть средства администрирования...


 
passm   (2003-02-04 09:59) [45]

Genzzz (02.02.03 11:24)> Разумеется, не хорошо. Но ведь ты собираешься реализовать весьма нестандартную весчь...


 
Desdechado   (2003-02-04 13:37) [46]

с клиента подключаешься через IBX к серверу и читаешь список подключенных к нему всех клиентов TIBDatabaseInfo (логинов, в смысле, а не тачек)


 
Genzzz   (2003-02-04 18:37) [47]

Ой, блиииин....

Desdechado, ну я ведь говорю ! Мне не на стороне КЛИЕНТА нужно, а на стороне СЕРВЕРА !


 
Genzzz   (2003-02-05 19:02) [48]

Задавая вопрос, даже и представить не мог, что это настолько сложно и никто не знает как реализовать...


 
Desdechado   (2003-02-05 19:23) [49]

я себе представляю процесс так:
1. программа-клиент запускается, требуя логин у юзера
2. юзер вводит логи-пароль
3. программа-клиент долбится к серверу и узнает список логинов, с которыми к БД уже подключились
4. проверяет, есть ли в нем логин, который ввел текущий юзер
5. ругается или пускает дальше - по обстоятельствам

так что НА СТОРОНЕ КЛИЕНТА.

а как применить при этом сторону сервера - не вижу. Покажи.


 
Harry   (2003-02-05 19:44) [50]

Если нельзя сделать этого стандартными средствами сервера, почему это нельзя проэмулировать самостоятельно? Скажем написать прогу, котроя периодически проверяет подключение к базе данных двух логинов и выдает каким-либо образом сообщекние, вплоть до отправления на мыло или SMS.


 
Genzzz   (2003-02-05 22:40) [51]

Desdechado, я себе представляю это так:

1. Когда идет подключение к серверу - вызывается некий триггер, типа OnLogin
2. В этом триггере идет проверка на существование уже такого логина
3. Если такой логин существует, то он аннулируется.

А вот как реализовать - не знаю...


Конечно, firebrid поставляется с исходниками... но у меня, думаю, не хватит квалификации


 
Sergey13   (2003-02-06 09:32) [52]

2Genzzz (05.02.03 22:40)
>1. Когда идет подключение к серверу - вызывается некий триггер, типа OnLogin
В ИБ нет тригеров уровня БД. Это тебе на Оракл надо. 8-) Че то ты кажись зациклился на проблеме. 8-) Какая для тебя принципиальная разница на какой стороне идет проверка. Тебе же предлагали вполне работоспособные варианты.


 
Reindeer Moss Eater   (2003-02-06 09:45) [53]

Какая для тебя принципиальная разница на какой стороне идет проверка.

Клиент не обязан использовать программу, в которой реализован механизм защиты. Он может запустить например SQL explorer


 
Sergey13   (2003-02-06 10:25) [54]

2Reindeer Moss Eater (06.02.03 09:45)
>Клиент не обязан использовать программу, в которой реализован механизм защиты. Он может запустить например SQL explorer
Ну тогда, только Оракл, хотя это и там не так просто реализовать.
Я где то видел описание такого решения. Вводя логин и пароль юзер на самом деле вводит данные для некоей функции, которая вместо введенных подставляет истинные логины и уже с ними лезет в базу. Например Иванов в базе может быть Bdfyjd. Тогда проблема с "чужими" программами отпадает - юзер не знает своего истинного логина.
Или стереть все программы типа SQL explorer у клиента, и запретить ставить их. 8-)


 
Genzzz   (2003-02-06 20:40) [55]

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

Правда, лучше реализовать все таки по нормальному, иначе проблемы с админстрированием и другие неприятности...


 
Sergey13   (2003-02-07 09:26) [56]

2Genzzz (06.02.03 20:40)
> иначе проблемы с админстрированием и другие неприятности...
А какие проблемы? Добавляй к имени пользователя например "-гад" - и мральное удовлетворение получишь и юзер ни о чем не догадается и все понятно кто работает - "иванов-гад". Можно и покрепче словечки подобрать. 8-)


 
Genzzz   (2003-02-08 00:32) [57]

Sergey13, а вдруг догадается ? И все равно это не очень... у базы могут быть различные администраторы, которые имеют различные права... и стоит увидеть, что в к именам пользователя приписывается -гад как вся защита накроется :-(

Это все, конечно, варианты, но полумерные...


 
Genzzz   (2003-02-09 14:28) [58]

может у кого появились идеи ?


 
Cranium   (2003-02-10 01:13) [59]

Ну тут вроде ни кто про UDF не вспомнил! Тогда схема такая:
1) Отлавливаем вход юзера, ну скажем по тригеру
2) А все остальное реализуем через UDF
Конечно другой админ может сделать тригер не активным, но на то он и админ....


 
Sergey13   (2003-02-10 09:03) [60]

2Cranium © (10.02.03 01:13)
>1) Отлавливаем вход юзера, ну скажем по тригеру
По какому????
2Genzzz (08.02.03 00:32)
>у базы могут быть различные администраторы
А зачем администраторов под одну гребенку с обычными юзерами? Что положено Юпитеру...
>Это все, конечно, варианты, но полумерные...
Опять повторюсь, ты много хочешь за бесплатно. Серьезные решения стоят серьезных денег. Иногда ОЧЕНЬ серьезных.
К тому же. А почему ты все про базу говоришь? Может подумать про нормальное администрирование сети. Там можно много чего настроить.


 
{bas}   (2003-02-10 10:02) [61]

А грант на ссесию м. в IB давать??


 
dash78   (2003-02-10 10:09) [62]

Удалено модератором
Примечание: Личная переписка


 
SergeyKatruk   (2003-02-10 16:57) [63]

Не обязательно Оракл, можна и Информикс.............


 
Nikolay M.   (2003-02-11 10:17) [64]

Может я поздно включился и чего не понял, но почему обязательно нужно реализовывать несколько коннектов к БАЗЕ? К собственно БД логин-пароль будет один (SYSDBA/masterkey), а у юзеров для входа в твою прогу будут заводимые администратором (или продвинутым пользователем) логины (vasya/1234), которые будут лежать в закодированном виде где-нибудь на сервере. И кто мешает сделать проверку на клиенте, стоит ли в этой таблице юзеров напротив введенного логина галочка "юзер уже находится в системе"?
Проблема, как я понимаю, не в том, чтобы дать каждому юзеру свой логин к базе, а в том, чтобы не дать двум юзерам работать под одним логином в твоей проге.
А заводить каждому юзеру логин в БД - имхо, чесаться левой ногой. Рано или поздно найдется продвинутый 10-классник, который запустит SQL Explorer и потрет под своим логином все записи в таблицах, на которые ему дан доступ.
Еще раз сорри, если пост не в тему или такая мысль уже проходила.


 
Genzzz   (2003-02-12 18:18) [65]

Nikolay M
спасибо, что пробегая рядом, решили поделиться мыслями...

Очень порадовало:

А заводить каждому юзеру логин в БД - имхо, чесаться левой ногой. Рано или поздно найдется продвинутый 10-классник, который запустит SQL Explorer и потрет под своим логином все записи в таблицах, на которые ему дан доступ

А вы как себе представляете логику работы базы ?


 
Genzzz   (2003-02-15 01:25) [66]

поднимаю ветку


 
Chubaiss   (2003-02-15 02:25) [67]

Аа-а-а-а-а-а-а-а-а--а-а-а..........Пук.....................


 
ЮЮ   (2003-02-15 03:19) [68]

Для Чубайса ветка оказалась неподъёмная :-) Ну, допустим, ты решишь эту проблему на стороне сервера и у тебя появится свободное время сделать ещё одно клиентское приложение. А оно не запускается, говорит "вы уже на Базе" :-) Твоё "извращеное" желание "один аккаунт - один коннект" верно только в рамках твоего приложения, вот в рамках своего приложения его и реализуй.


 
Genzzz   (2003-02-15 13:20) [69]

ЮЮ, а можно расшифровать ваш глубокомысленный пост ?
что-то не понял я


 
sndanil   (2003-02-15 17:00) [70]

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


 
Johnmen   (2003-02-16 01:53) [71]

Потрясающее упрямство в нежелании понимать сущность коннекта и юзера....:(


 
Genzzz   (2003-02-18 00:26) [72]

Johnmen, я то понимаю. А вот если бы вы прочитали мои посты - может тоже поняли...

sndanil, интересно. Гиморно, но интересно... единственное, можно ли будет сменить пароль юзера, если он в системе ? надо проверить...


 
Genzzz   (2003-02-18 00:28) [73]

sndanil, опять же - это только препятствие для доступа к базе... Хотя уже хорошо =)

Но идеально было бы знать когда кто-нибудь пытается использовать чужой логин...


 
Johnmen   (2003-02-18 09:24) [74]

>Genzzz (18.02.03 00:26)
>...я то понимаю.

Следующая фраза однозначно доказывает обратное :

> (18.02.03 00:28)
>Но идеально было бы знать когда кто-нибудь пытается
>использовать чужой логин...

Поясню - невозможно (!) определить использование челом чужого логина ! :)



 
Соловьев   (2003-02-18 09:47) [75]

2 Genzzz
Ты уже полмесяца(!) стоишь, а мог сделать как я посоветовал
>>Соловьев © (27.01.03 15:42). Я сделал и не жалею, можно контролтровать как угодно: и по количеству коннектов, и по нику, и по пасворду.


 
Reindeer Moss Eater   (2003-02-18 09:47) [76]

Но очень хочется :)


 
NDeu   (2003-02-18 12:52) [77]

2 Genzzz
Давайте уточним задание
1. У тебя есть база на сервере(IB6) и клиентское ПО.
2. У тебя есть один или несколько BDадминов.(Они как Зевс. Им позволено все. Они знаят как свой пароль беречь)
3. У тебя есть несколько операторов на клиентское ПО ( Тетки, которые свой пароль клеят на мониторе, чтоб не забыли :)

Тебе нужно чтоб с пароль тетки, никто и никак не мог свезатся с сервера, даже с посторонным ПО (напр. IBConsole).

Решение
1.Создай юзер Application с свой пароль.
2.Этот пароль дай клиентскому ПО (в Registry или *.ini, лучше криптовано). Приложение конектикся к сервера под этот юзер Application.
3.Создай в базе табл. MyUsers, где записываеш UserName, Password, Permitions, IsConeccted и т.д. и т.п. что твоя душа захочет.
4.Запрашивай тетки за пароль, и сравнивай с запис в MyUsers. Эсли так хочется пиши логов в LogFile или LogTable.

Так пароль тетки не является пароль сервера и с этом никого и никогда не конектится.
С пороль админа можно сделать все (даже конектится сколко раз захочет), но так и надо.

Извини за плохого русского. Не родной :(
3.В базе


 
Andrey   (2003-02-18 13:33) [78]

>можно ли будет сменить пароль юзера, если он в системе
Поменять можно. Это точно.

>параллельно с сервером будет висеть прога, которая
>допустм на время соединения клиета будет менять его пароль
Паралельно это конечно можно, но как часто она будет проверять кто подключился, кто отключился. Раз в час, минуту, секунду, а это достаточная частота? А не перегрузит ли такая частота сервер? Короче минусов много. Есть конечно решение 3-х звенка, но IMHO это не та проблемма которая требует столь радикальной перепланировки 2-х уровневых систем.


Я тоже этот вопрос исследовал. Нет в IB такой возможности. Единственное естественное (выполненяемое не извратами на клиенте, а непосредственно сервером) решение это перекомпиляция IB... Скоро, через 1-2 месяца я этим вплотную займусь.

Тогда можно решить и более сложную (мою) проблемму: 1 коннект к 1 базе для 1 хоста.


 
Genzzz   (2003-02-18 20:53) [79]

NDeu, идея просто замечательная. Но ты хочешь, чтобы Application был админским аккаунтом ? Имхо, это серьезное нарушение безопасности. Где бы я его и как не хранил - хранить аккаунто администратора на компьютере...

Johnmen, вы очень хорошо все пояснили. Только я вас уверяю. Сделать можно все, ЧТО УГОДНО. Если вы не знаете как - это ничего не значит


 
Johnmen   (2003-02-19 09:33) [80]

>...Если вы не знаете как - это ничего не значит

Да. Я ничего не знаю о том, знаешь ли ты, что я знаю о твоих знаниях и пониманиях...Но это ничего не значит...



 
Genzzz   (2003-02-20 22:04) [81]

ау


 
Johnmen   (2003-02-20 23:53) [82]

>Genzzz (20.02.03 22:04)
>ау

Ау... Похоже мы попали в лес...:)

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


 
Genzzz   (2003-03-04 18:25) [83]

Может появились у кого идеи ?


 
Deniz   (2003-03-04 20:04) [84]

Пора ЗАКРЫВАТЬ эту ветку.
Человеку сказали, что это сделать нельзя(пока нет триггеров типа OnConnect и т.д.), но Он таки ждет идей. К Genzzz: или жди функциал, или сам компилируй.


 
Vladimir   (2003-03-05 07:54) [85]

2 Genzzz
Пиши сервер приложений и ворочай там чего угодно.


 
Alexandr   (2003-03-05 08:20) [86]

а я то-думал, чего тут так долго обсуждать-то можно...


 
Vladimir   (2003-03-05 09:40) [87]


> Alexandr ©

Ха, да если задать вопрос типа "куда мне пойти, чтобы чего-нибудь найти..", так еще не такая дискуссия может разгореться :)


 
Анонимщик   (2003-03-05 14:07) [88]

Да, задолбали человека, решили ему объяснить, что он делать должен.
Genzzz, не трать на них время, они не умеют отделять главное от второстепенного. Нельзя этого пока сделать на стороне сервера.


 
Mirolex   (2003-03-06 03:24) [89]

Уфф...дочитал до конца...разочарован...Genzzz, переквалифицируйся в дворники. Программер - это призвание, а не професия. В первую очередь надо уметь слушать и слышать ответы (на свои же вопросы). Этот тред можно было еще в середине прекратить, но уважаемый Genzzz говорит, что мы все дураки, а он один умный и..."вновь продолжается бой". Как капризная девица, хочу и все.


 
Asgard   (2003-03-06 05:16) [90]

Сам сервер делать такого не умеет.
Следовательно, надо делать трехзвенку.
Можно сделать не полноценную трехзвенку, а что-то типа прокси-сервера, который будет втупую перенаправлять коннекты клиентов серверу, отлавливая в потоках данных только запрос авторизации.
Прокси должен строить таблицу активных коннектов, в которую прописываются в том числе и имена пользователей, переданные в запросе авторизации.
Машину с БД-сервером нужно закрыть firewall"ом от попыток прямого коннекта, разрешив только коннект от прокси.
Плюсы такой схемы:
+Прокси может отслеживать активность сессий, и неживые сессии прибивать автоматом, удаляя из таблицы запись о логине (исключает необходимость ручного вмешательства при некорректном завершении сессии).
+Можно заставить проксю определять мак-адрес по ip запросившего коннект, и сравнивать его по вручную сделанной таблице типа (UserName, MAC) - таким образом можно заставить юзера входить только с определенной машины в сети.

А минусы - это нужно писать :) Но все равно проще, чем переписывать ядро Firebird.


 
Asgard   (2003-03-06 07:03) [91]


> Mirolex (06.03.03 03:24)
> Уфф...дочитал до конца...разочарован...Genzzz

Это форум для программистов, а не для всяких лопухов, которые постят не по теме.


 
Wind2000   (2003-03-06 09:53) [92]

Что касается Oracle - такая задача (контроль количества подключений) средствами самого сервера решается очень просто. Что касается расширения такой задачи до уровня "Не дать никому использовать чужой логин" - можно добавить механизм контроля по имени application, АйПишнику машину и т.д. Информация, собираемая Oracle о соединении, позволяет контролировать что угодно и как угодно.



Страницы: 1 2 3 вся ветка

Форум: "Базы";
Текущий архив: 2003.03.24;
Скачать: [xml.tar.bz2];

Наверх





Память: 0.69 MB
Время: 0.017 c
8-76537
Dimitri
2002-12-08 22:01
2003.03.24
MPEG-1 video


1-76475
AlLive
2003-03-12 07:38
2003.03.24
Есть ли подстрока в строке?


7-76687
BALU1111
2003-01-27 11:45
2003.03.24
Свекрнуть программу в System Tray


14-76645
Оля
2003-03-07 10:29
2003.03.24
Помогите девушке определиться


3-76340
Andy Eremin
2003-03-06 07:09
2003.03.24
SQL UPDATE





Afrikaans Albanian Arabic Armenian Azerbaijani Basque Belarusian Bulgarian Catalan Chinese (Simplified) Chinese (Traditional) Croatian Czech Danish Dutch English Estonian Filipino Finnish French
Galician Georgian German Greek Haitian Creole Hebrew Hindi Hungarian Icelandic Indonesian Irish Italian Japanese Korean Latvian Lithuanian Macedonian Malay Maltese Norwegian
Persian Polish Portuguese Romanian Russian Serbian Slovak Slovenian Spanish Swahili Swedish Thai Turkish Ukrainian Urdu Vietnamese Welsh Yiddish Bengali Bosnian
Cebuano Esperanto Gujarati Hausa Hmong Igbo Javanese Kannada Khmer Lao Latin Maori Marathi Mongolian Nepali Punjabi Somali Tamil Telugu Yoruba
Zulu
Английский Французский Немецкий Итальянский Португальский Русский Испанский