ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / БД и аутентификация
9 сообщений из 9, страница 1 из 1
БД и аутентификация
    #37529471
InnerCloister
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
InnerCloister
Гость
Интересует, каким образом правильно и эффективно хранить учетные данные для сущностей базы данных.
Допустим, есть модель данных, в ней две сущности - отдел и сотрудник. Нужно предусмотреть ввод пароля для доступа к данным отдела и/или каждого сотрудника по отдельности. Самый прямой путь - хранить логины-пароли (или их хеш) как атрибуты сущностей. Но, по идее, это не совсем правильно, т.к. эти данные к самой сущности (в реальном мире) как бы не очень относятся и никак ее не описывают. Есть ли какие-нибудь способы хранения аутентификационных данных без замусоривания основных сущностей? Вроде как, отдельно от БД делать тоже не вариант, но можно, наверное, как-то обособить систему аутентификации в рамках одной схемы.
...
Рейтинг: 0 / 0
16.11.2011, 15:36
| Ответить | Цитировать | Написать  
БД и аутентификация
    #37529584
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
InnerCloisterНужно предусмотреть ввод пароля для доступа к данным отдела и/или каждого сотрудника по
отдельности.

Назачем? При подключении к БД пользователь уже ввёл пароль. Дальше действуют GRANT и RLS.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
16.11.2011, 16:08
| Ответить | Цитировать | Написать  
БД и аутентификация
    #37529764
InnerCloister
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
InnerCloister
Гость
Dimitry Sibiryakov, дело в том, что к БД могут подключаться разные подразделения. Она одна для всех. И мне нужно, чтобы подразделение работало только со своими данными. Для этого я в конфигах клиента укажу ID подразделения. А чтобы пользователи сами не меняли ID, необходимо будет также вводить пароль. Вот и нужно где-то хранить пароли для каждого подразделения.
...
Рейтинг: 0 / 0
16.11.2011, 17:13
| Ответить | Цитировать | Написать  
БД и аутентификация
    #37529813
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
InnerCloisterдело в том, что к БД могут подключаться разные подразделения. Она одна для всех

К БД не подключаются подразделения. К БД подключаются пользователи. Каждый со своим именем
и паролем. Каждый пользователь может видеть только то, что ему разрешено видеть. Об этом
заботится система SQL прав. RTFM GRANT|REVOKE.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
16.11.2011, 17:31
| Ответить | Цитировать | Написать  
БД и аутентификация
    #37529999
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
Вам нужен доступ на уровне строк
InnerCloister есть модель данных, в ней две сущности - отдел и сотрудникТогда уже три сущности: отдел, сотрудник и данные.
У данных есть функция (подзапрос) определяющая видит ли данный пользователь данную запись. Тогда вы строите вьюху на таблицу
Код: plaintext
create view vw_mytable as select * from mytable where is_mydata('system_user')= 1
и раздаете права на чтение только на нее (с записью все будет чуть сложнее и зависит от вашей СУБД). Прав на запись в таблицу сотрудников и отделов у рядового пользователя нет, так что заморачиваться с самодельными паролями не надо.

InnerCloister Для этого я в конфигах клиента укажу ID подразделения.Храните в базе. Она для этого предназначена
...
Рейтинг: 0 / 0
16.11.2011, 18:27
| Ответить | Цитировать | Написать  
БД и аутентификация
    #37530586
InnerCloister
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
InnerCloister
Гость
SERG1257,

ну если возможен доступ на уровне строк, то все проще, чем я думал. Я просто не думал о такой возможности. Хранить ID подразделения у клиента не обязательно, да. Оно идентифицируется пользователем.
Спасибо за информацию.
...
Рейтинг: 0 / 0
17.11.2011, 02:06
| Ответить | Цитировать | Написать  
БД и аутентификация
    #37530699
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zeon11
Участник
Dimitry SibiryakovInnerCloisterдело в том, что к БД могут подключаться разные подразделения. Она одна для всех

К БД не подключаются подразделения. К БД подключаются пользователи. Каждый со своим именем
и паролем. Каждый пользователь может видеть только то, что ему разрешено видеть. Об этом
заботится система SQL прав. RTFM GRANT|REVOKE.


Это будет работать в том случае, если у каждого подразделения своя табличка с идентичной структурой, однако таких БД как правило опытные разработчики уже давно не делают.

InnerCloister, а ты подумал о том, что рано или поздно, появится сотрудник, которому будет поручено видеть два или три отдела?
Что будешь делать тогда?
Твоя текущая задача - частный случай этой задачи.
Поэтому решай сейчас общую задачу, что-бы небыло мучительно больно потом.
Решение может быть такое:
есть четыре таблицы, например, MAN, BRANCH, MAN_BRANCH, DOC
Выбрать все документы разных отделов, к которым разрешён доступ для сотрудника Иванова:
Код: plaintext
1.
2.
3.
4.
5.
6.
select d.*, b.NAME
  from DOC d
      inner join BRANCH b on (d.ID_BRANCH=b.ID_BRANCH)
      inner join MAN_BRANCH mb on (d.ID_BRANCH=mb.ID_BRANCH)    
      inner join MAN m on (mb.ID_MAN=m.ID_MAN)
   where m.NAME='Иванов'
т.е. тебе при входе в БД необходимо удостоверится что Иванов это действительно Иванов.
Этот запрос, что я привел исключительно учебный, для реальных целей его стоит переделать, но это уже другая история ;-)
...
Рейтинг: 0 / 0
17.11.2011, 08:04
| Ответить | Цитировать | Написать  
БД и аутентификация
    #37531234
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
InnerCloisterНо, по идее, это не совсем правильно, т.к. эти данные к самой сущности (в реальном мире) как бы не очень относятся и никак ее не описывают.
При проектировании не стоит уделять чрезмерного внимания "реальному миру". Реальный мир определяет "интерфейс" разрабатываемого модуля, но не его реализацию. Если в реализации Вам удобная сущность "пьяный розовый слон" - значит, в БД нужно сделать такую сущность, несмотря на то, что в реальном мире таких не бывает. Это в том, что касается подхода к проектированию.

А про решение Вашей задачи уже сказали - читайте, как в вашей СУБД правильно делать row level security. Это стандартная задача.
...
Рейтинг: 0 / 0
17.11.2011, 12:34
| Ответить | Цитировать | Написать  
БД и аутентификация
    #37532946
InnerCloister
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
InnerCloister
Гость
zeon11,

пример, который я привел, всего лишь пример) Моя предметная область - сдельная оплата труда сотрудников организации, т.е. я просто храню информацию о том, какие операции и в каком количестве выполнил сотрудник в определенный день. Ничего лишнего им видеть не надо. Структура, естественно, не из двух таблиц, у меня человек и работник - разные сущности, так что можно, например, выдавать логин-пароль человеку, а не сотруднику. Или просто сделать одинаковые логин и пароль для тех возможностей, которыми пользуется один человек, если уж совсем ничего лучше не придумаю.
Нужно предусмотреть ввод пароля для доступа к данным отдела и/или каждого сотрудника
Вот эту фраза двусмысленна, наверное. Лучше так:
Нужно предусмотреть ввод пароля отделом и/или каждым сотрудником для доступа к данным
То есть, в идеале, конкретный человек с отделения должен этим заниматься. Или несколько человек. И им можно будет просто дать логин, связанный с этим отделением. Ну а на деле всякое может быть, поэтому и для отдельных сотрудников могут понадобиться пароли.
Ну, раз уж с проектированием это особо не связано, пока не буду об этом думать.
...
Рейтинг: 0 / 0
18.11.2011, 10:43
| Ответить | Цитировать | Написать  
9 сообщений из 9, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / БД и аутентификация
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&tid=1541943]:
 0ms
get settings:
 9ms
get forum list:
 25ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 159ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 58ms
get tp. blocked users:
 1ms
others: 244ms
total:  520ms
созд. / загр.: 520ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]