Разграничение прав доступа в приложении

@eon · Регистрация: 23.08.2010

Студворк — интернет-сервис помощи студентам

Задача:
В datagridview выводить строки из единственной таблицы удаленной БД (SQL Server 2008).
Создал базу, настроил связь с ней с клиентских машин, накидал приложение.

Вопрос:
Необходимо разграничить права доступа к БД, например:
1. Пользователь (админ) может всё;
2. Пользователь может только просматривать все записи;
3. Пользователь может просматривать все записи и удалять только свои;
4. Пользователь может просматривать только свои записи и удалять только свои;
и т.д.
это только примерный список, потом еще будет дополняться.

почитал про разграничение прав пользователей на уровне СУБД, и мне показалось что не получится сделать такие ограничения (например №3 и №4)

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

Что скажете по этому поводу? Можно ли делать разграничение прав на уровне приложения? Или же всё-таки надо глубже изучать безопасность на уровне СУБД?

@reiteriX · 24.08.2010, 08:25

Сообщение от eon

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

Вообще, по идее, хранить пароли отдельно не хорошо. Это гораздо менее надежно чем раздать права в "сервере".

Но, данный вариант я использовал довольно таки часто. Давал полные права, админские и уже "во всех щелях" в программе затыкал эти дыры ограничениями. И ничего, получалось надежно.

Даже можно с шифрованием, в программе пишешь процедурку (алгоритм) шифрования твоего пароля.

Юзер вводит в программе один пароль, а на серваке он хранится уже совершенно в другом виде.
PS. Такой вариант мне вообще понравился)

@ksk · 24.08.2010, 21:54

Обычно я ограничиваю права на уровне базы.
Создаю роли (админ, юзер итд), и пользователям эти роли раздаю.
На таблички, процедуры итд раздаю гранты на определённые действия для определённых ролей, в соответствии с задуманной политикой безопасности. Таким образом, даже если хитрый юзер законнектится со своим логином к базе через инструмент СУБД, он всё равно сможет делать только то, что разрешено делать назначенным ему ролям.

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

@nio · 24.08.2010, 23:56

Сообщение от eon

Что скажете по этому поводу? Можно ли делать разграничение прав на уровне приложения? Или же всё-таки надо глубже изучать безопасность на уровне СУБД?

На уровне приложения сделать проще, там в основном только с видимостью компонентов играешь.
Вопрос на сколько у тебя ценная БД и насколько продвинутые пользователи будут и смогут ли они твою БД ломануть. Если ламеры, то и напрягаться сильно не стоит.
Создание только ролей не очень хорошо. Представь у пользователя нет прав на изменение таблицы, но кнопка "Сохранить" в приложении все-равно работает. Результат: прога выбросит исключение. В таком случае предпочтителен вариант, который предложил ksk. А это уже двойная работа.

@reiteriX · 25.08.2010, 08:24

nio, да ладно тебе) Образно: "переменная статус" и на сохранение условие=> нет проблем.

@nio · 25.08.2010, 08:58

Сообщение от reiteriX

Образно: "переменная статус" и на сохранение условие=> нет проблем

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

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

Варианты есть, и Автору решать, что для него проще

Добавлено через 22 минуты

Сообщение от eon

почитал про разграничение прав пользователей на уровне СУБД, и мне показалось что не получится сделать такие ограничения (например №3 и №4)

Получится только для этого придется ввести во все таблицы столбец с ID пользователя внесшего запись, а затем запросами ограничивать право на ее редактирование (..where ID=...).

@reiteriX · 25.08.2010, 11:43

Сообщение от nio

юзверь видит кнопку, он будет в нее тыкать, недоумевать, почему ничего не происходит и снова тыкать......

ну тогда невидимость какую нибудь делать. А если кнопка юзеру всё таки нужна, но например не с теми "действиями" что у админа, то всё же статус)
Ну не будем спорить) А по поводу записи в отношение ИДов, это да. Это будет лучший вариант

@eon · 25.08.2010, 11:52 **[ТС]**

Всем спасибо за мнения, сделал я через приложение разграничение.
Руководству не понравилось. Говорят надо сделать так чтобы в СУБД заводились юзеры.
Надо переделать. Помогите. goto --> Авторизация для MS SQL
с чего начать даже не знаю

Новые блоги и статьи Все статьи Все блоги /
Модель микоризы: классовый агентный подход 3 anaschu 06.01.2026 aa0a7f55b50dd51c5ec569d2d10c54f6/ O1rJuneU_ls https:/ / vkvideo. ru/ video-115721503_456239114	Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ФедосеевПавел 06.01.2026 Owen Logic: О недопустимости использования связки «аналоговый ПИД» + RegKZR ВВЕДЕНИЕ Введу сокращения: аналоговый ПИД — ПИД регулятор с управляющим выходом в виде числа в диапазоне от 0% до. . .	Модель микоризы: классовый агентный подход 2 anaschu 06.01.2026 репозиторий https:/ / github. com/ shumilovas/ fungi ветка по-частям. коммит Create переделка под биомассу. txt вход sc, но sm считается внутри мицелия. кстати, обьем тоже должен там считаться. . . .	Расчёт токов в цепи постоянного тока igorrr37 05.01.2026 / * Дана цепь постоянного тока с сопротивлениями и напряжениями. Надо найти токи в ветвях. Программа составляет систему уравнений по 1 и 2 законам Кирхгофа и решает её. Последовательность действий:. . .
Новый CodeBlocs. Версия 25.03 palva 04.01.2026 Оказывается, недавно вышла новая версия CodeBlocks за номером 25. 03. Когда-то давно я возился с только что вышедшей тогда версией 20. 03. С тех пор я давно снёс всё с компьютера и забыл. Теперь. . .	Модель микоризы: классовый агентный подход anaschu 02.01.2026 Раньше это было два гриба и бактерия. Теперь три гриба, растение. И на уровне агентов добавится между грибами или бактериями взаимодействий. До того я пробовал подход через многомерные массивы,. . .	Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Programma_Boinc 28.12.2025 Советы по крайней бережливости. Внимание, это ОЧЕНЬ длинный пост. Налог на собак: https:/ / ********/ gallery/ V06K53e Финансовый отчет в Excel: https:/ / ********/ gallery/ bKBkQFf Пост отсюда. . .	Кто-нибудь знает, где можно бесплатно получить настольный компьютер или ноутбук? США. Programma_Boinc 26.12.2025 Нашел на реддите интересную статью под названием Anyone know where to get a free Desktop or Laptop? Ниже её машинный перевод. После долгих разбирательств я наконец-то вернула себе. . .

@eon 1 / 1 / 3 Регистрация: 23.08.2010 Сообщений: 46

	Разграничение прав доступа в приложении 24.08.2010, 08:03. Показов 11978. Ответов 7 Метки нет (Все метки) Задача: В datagridview выводить строки из единственной таблицы удаленной БД (SQL Server 2008). Создал базу, настроил связь с ней с клиентских машин, накидал приложение. Вопрос: Необходимо разграничить права доступа к БД, например: 1. Пользователь (админ) может всё; 2. Пользователь может только просматривать все записи; 3. Пользователь может просматривать все записи и удалять только свои; 4. Пользователь может просматривать только свои записи и удалять только свои; и т.д. это только примерный список, потом еще будет дополняться. почитал про разграничение прав пользователей на уровне СУБД, и мне показалось что не получится сделать такие ограничения (например №3 и №4) в голове уже создал вариант разграничения прав на уровне приложения, создам табличку в БД с юзерами и паролями + статус, который и будет определять права пользователей. Что скажете по этому поводу? Можно ли делать разграничение прав на уровне приложения? Или же всё-таки надо глубже изучать безопасность на уровне СУБД? 0

@ksk 624 / 495 / 43 Регистрация: 05.07.2010 Сообщений: 1,589
	24.08.2010, 21:54
	Обычно я ограничиваю права на уровне базы. Создаю роли (админ, юзер итд), и пользователям эти роли раздаю. На таблички, процедуры итд раздаю гранты на определённые действия для определённых ролей, в соответствии с задуманной политикой безопасности. Таким образом, даже если хитрый юзер законнектится со своим логином к базе через инструмент СУБД, он всё равно сможет делать только то, что разрешено делать назначенным ему ролям. Для того, чтобы в приложении понять, что можно конкретному юзеру, а что нельзя, спашиваю у базы для каждой роли IsMemberOf и таким образом узнаю, какая роль юзеру дана, а какая нет, и в соответствии с этим показываю или не показываю например кнопки редактирования. 0

@reiteriX 685 / 241 / 13 Регистрация: 02.04.2009 Сообщений: 692
	25.08.2010, 08:24
	nio, да ладно тебе) Образно: "переменная статус" и на сохранение условие=> нет проблем. 0

@eon 1 / 1 / 3 Регистрация: 23.08.2010 Сообщений: 46
	25.08.2010, 11:52 [ТС]
	Всем спасибо за мнения, сделал я через приложение разграничение. Руководству не понравилось. Говорят надо сделать так чтобы в СУБД заводились юзеры. Надо переделать. Помогите. goto --> Авторизация для MS SQL с чего начать даже не знаю 0