Вход под одним логином

← →
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]

← →
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
при всем написанном вся проверка на стороне клиена, что не есть ГУД.

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