Вход с разных пользователей в БД с формы авторизации

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

например если конектитса пользователь 2 (которому можно только смотреть таблицы)
то вслучае нажатия на кнопки которые както меняют таблицу не выполняли действия .

например если конектитса пользователь 3 (которому доступны только 1 таблица з 4)
то вслучае запроса просмотра таблицы работала только та одна.

0

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

По поводу юзера 3, вам может помочь такая вещь как промежуточная таблица и связь многие ко многим. Почитайте об этом в интернете. Чтоб посмотреть, какие таблицы доступны каждому из пользователей вы обращаетесь к этой промежуточной таблице и смотрите ID каких таблиц связаны с ID конкретного пользователя.

0

Необходимо в БД держать таблицу, содержащую информацию не только о пользователях (ФИО, логин, пароль и т.д.), но и об их правах и возможностях в системе. Иначе говоря, - профили. В этих вот профилях и должна храниться информация о том, с какими таблицами (а точнее, сущностями) БД и в каких объемах пользователь может работать.
Интерфейс, если он общий для всех пользователей, должен контекстно к профилю реагировать на функционал. Например, если пользователь может только смотреть какую-то таблицу, то кнопки "Добавить", "Изменить", "Удалить" должны быть неактивны или вообще отсутствовать в интерфейсе.

Добавлено через 2 минуты
Настройка интерфейса на профиль должна выполняться после процедуры авторизации и открытия основной формы приложения в соответствующем режиме согласно профилю вошедшего пользователя.

0

Ребят всем спасибо но вы непоняли меня, как зделать чтоб в програмном коде так было .
Как зделать строчки програмного кода которые будут запоминать даные входа тоисть логин и пароль после чего все кнопки и команды будут или не будут выполнятса в зависимости от пользователя.
Я работаю не з самим MySQL а ищо з програмированием C#
А ищо я заметил что з MySQL невозможно будет зделать ето програмно поскоку таблица з Пользователями делает Хеширование для паролей.

0

Ну, все правильно, есть такой замечательный фреймворк Entity Framework. Он позволяет работать с БД очень удобно. И он может САМ создавать классы, которые будут подходящими для того, чтоб в них записывать данные из определенных таблиц БД. То есть, есть, например, таблица Users с какими-то столбцами. EF может сама создать класс, который назовет User и сконструирует его так, чтоб вы могли с таблицы Users получить данные и записать их в этот самый класс User.

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

Надеюсь, понятно объяснил

1

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

0

Пользователей может быть хоть миллион. У каждого из них есть права (роль), в соответствии с которой и предоставляется функционал. Например, есть Маша, Саша, Глаша с одинаковыми правами "только просмотр". При авторизации приложение считывает профиль пользователя и, если он Маша, Саша, Глаша, то редактирование, добавление и удаление для них невозможно и это пункты меню "закрываюся" (Enable = false) и становятся не доступны.
Заходит Ваня, Саня, Даня и Мишаня, в их профиле указано право только на добавление - соответственно приложение закрывает пункты редактирование и удаление и они могут кроме просмотра еще и добавлять новые записи в таблицу.

0

MsGuns, Скажыте мне пожалуста уменя как я выше сказал 60 пользователей с РАЗНЫМИ не ОДИНАКОВЫЕ а РАЗНЫЕ права что тут не понятно?
если бы мне нужно было создавать много пользователей а функцыонал одинаковый то я б и не создавал ету тему.(поскоку ето и так понятно и просто).
А уменя каждый имеет личные права ЛИЧНЫЕ и делать 60 форм и 60 вариацый кнопок не охота поетому я хотел чтобы кто вдруг если знает как зделать запись с полей в переменые который передаютса в командную строку вот сама строка


MySqlConnection = new MySqlConnection("Server=localhost; Database=bazadanuh;username=root;passwor d=1234546;")

и мне нужно сделать так чтоб в етой команде вместо прямых значений username и password были значения переменых записующие в себе те логин и праоль которые вводит пользователь а не постояно root и 1234546 .

Извините за агресивный стиль написания сообщения(просто уже который раз говорю что у каждого пользователя разные права).

0

Сообщение от JorJoFox C# 1 MySqlConnection = new MySqlConnection("Server=localhost; Database=bazadanuh;username=root;password=1234546;")

примерно так можно сконфигурировать строку

0

JorJoFox,
... вы вообще в курсе, что не вы первый пишете подобное приложение (вообще, приложение с доступом к БД), в том числе и с авторизацией, и подобные приложения используют служебную учетку для доступа к БД, а саму авторизацию реализуют на уровне приложения, а не строки подключения ... У вас в MySQL шестьдесят пользователей? .. Не 60 записей в базе, а именно
... это так?

0

JorJoFox,
Вы путаете права на объекты СУБД с особенностями интерфейса работы с СУБД.
Интерфейс может быть один на 60 пользователей с разными правами, но при этом доступные функции в этом интерфейсе будут разные. Как было написано в [7].
А можно написать 60 форм (или даже 60 разных приложений) - по одной персонально для каждого пользователя.
Не зная особенностей Вашего приложения, что-то советовать конкретно трудно. Одно ясно - 60 форм, а тем более приложений - это явно не тот путь.

Добавлено через 19 минут
Вот простейший пример:
Есть БД, состоящая из
1) Таблица "Расписание занятий"
2) Таблица "Состав преподавателей кафедры"
3) Таблица "Перечень дисциплин (предметов)"
4) Таблица "Учебные группы и студенты в этих группах"
5) Таблица "Посещения занятий студентами"
6) Таблица "Успеваемость студентов (оценки)"

Для каждой из таблиц в интерфейсе приложения предусмотрена форма с кнопками "Добавить", "Изменить", "Удалить" (IUD), которые действуют согласно правилам, определенным ниже.

Есть пользователи (Users)
1) Декан факультета - завкафедрой
2) Преподаватель
3) Студент

Роли (права):
Декан - все таблицы - просмотр, таблицы 1-4 - все операции (добавление, изменение, удаление)
Т.е. ему доступны все 6 форм с таблицами. При этом для форм 1-4 доступны кнопки IUD

Преподаватель - таблицы 1,4,5,6 для просмотра. Дополнительно : для 1 - U (может вписывать номер аудитории и себя, любимого как лектора), 5 - U (ставить отметки о посещении или пропуске занятия студентами), 6 - IEU - проставление оценок студентам на каждом занятии. Доступны 4 формы понятно с какими кнопками.

Студент - таблицы 1-6 только для просмотра. Доступны все формы, но нет кнопок IEU

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

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

Добавлено через 13 минут
Пример простейший, но показывает механизм реализации различных схем доступа к сущностям БД.
В реальности, конечно, лучше использовать динамические схемы.
Например, вместо всех этих полей VIEUx в записи профиля вообще от них отказаться в пользу дочерней таблицы, которая будет содержать данные о доступе к конкретным сущностям и поле-ссылку на Id профиля пользователя. Т.е. для декана и студента там будет по 6 записей с флажками IEU, а для преподавателя - 4.
Это позволит легко настраивать приложение при расширении модели СУБД (добавлении новых сущностей) без правки модели самого профиля (состава и типов полей)

0

carrotik, всьо верно

0

Сообщение от JorJoFox username=root;password=1234546;

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

1

Сообщение от JorJoFox всьо верно

..в таком случае, как ваше приложение обрабатывает ответ от БД "access denied", если бесправный Вася нажмет на общей форме кнопку "Редактировать" ..? .. просто игнорирует?

1

А можно обойтись без профиля и его дочерней таблицы вообще, прописав самих пользователей и их права в бизнес-логику сервера (Users, Roles - см. BOL по TSQL). Но в этом случае для настроек элементов управления (меню, кнопки) придется предварительно извлекать с сервера метаданные о ролях и пользователях, для чего, очевидно, создавать отдельное соединение с правами админа и посылать соответствующий запрос в его контексте.

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

Добавлено через 8 минут
Подобным образом построен механизм доступа в БД в системе "Парус".
Для каждого входящего юзера том есть список ролей, а для каждой роли - список доступных подсистем и объектов СУБД.
Заходит, например, в "Парус" бухгалтер - ему отображается меню только системы "Бухгалтерия", а внутри нее меню к ее объектам (План счетов, Таблица проводок, Банковские документы и т.д.), причем объекты тоже определяются ролями. Например, для "простого" бухгалтера не будет в меню подсистемы "Зарплата", а для бухгалтера группы расчета з/пл - будет.
И т.д.

1

Andrey-MSK, всьо верно я так и думал но в случае з PhpMyAdmin там можно сравнивать.

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

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

0

.. ну ладно .. архитекторам - архитекторово ...

0

Если переложить пример в [7] на "язык" SQL-Server, то получим такую картину.
Роли:
- Role1_View - Таблица "Расписание занятий" просмотр
- Role1_Edit - Таблица "Расписание занятий" редактирование
- Role1_IsertDelete - Таблица "Расписание занятий" удаление-добавление

- Role2_ View - Таблица "Состав преподавателей кафедры" просмотр
- Role2_ Edit - Таблица "Состав преподавателей кафедры" редактирование
- Role2_ InsertDelete - Таблица "Состав преподавателей кафедры" удаление-добавление

- Role3xxx - Role6xx по аналогии

Пользователи:
- User1 Декан
- User2 Преподаватель
- User3 Студент

Привязка ролей:
User1
Role1_View+Role1_Edit+Role1_InsertDelete +
Role2_View+Role2_Edit+Role2_InsertDelete +
Role3_View+Role3_Edit+Role3_InsertDelete +
Role4_View+Role4_Edit+Role4_InsertDelete +
Role5_View +
Role6_View
User2
Role1_View+Role1_Edit +
Role4_View+Role4_Edit+Role4_InsertDelete +
Role5_View+Role5_Edit +
Role6_View+Role6_Edit+Role6_InsertDelete
User3
Role1_View +
Role2_View +
Role3_View +
Role4_View +
Role5_View +
Role6_View

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

Сообщение от JorJoFox я понимаю что приложения не будет иметь ничего к правам доступа пользователей.

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

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

Сообщение от JorJoFox но в случае з PhpMyAdmin там можно сравнивать

Все, что делает PhpMyAdmin (в смысле работы с сервером, а не показа "картинок"), Вы можете делать в своем приложении. SQL-Server разницу не увидит

Добавлено через 8 минут
В дополнение.
С ролями в SQL-Server можно весьма эффективно играться.
Например, есть несколько ролей (часто весьма много - десятки), типичных для нескольких (часто-многих) пользователей. Чтобы не перечислять для каждого их них все эти роли, можно объединить их в "кучку", создав новую "коммулятивную" роль, которую и назначать юзерам.

Добавлено через 6 минут
Механика "разруливания" прав в SQL весьма мощная штука, но и требующая понимания как это все работает - с одной стороны, и гибких, зачастую далеко не тривиальных алгоритмов настройки приложений на адекватную реализацию своего контекстного по отношению к пользователю функционала,- с другой стороны.

В общем, это дело явно не для новичка

Добавлено через 17 минут
Подитоживая все вышесказанное, можно сказать, что имеется по крайней мере 3 способа реализации разграничений прав пользователя:
1. Клиентский
Авторизация + настройка приложения на конкретного пользователя выполняется в рамках исключительно самого приложения. Данные о пользователях хранятся не в БД, а, к примеру, в файле txt/xls/doc/xml/json.. в папке с приложением или в одной из системных папок (ProgramFiles/MyFineApplication).
SQL-Server ничего не знает ни о каких пользователях и ролях. Вход на сервер (connectionstring) обычный либо с "зашитым" админским логином-паролем

2. Клиентский + БД
Авторизация + настройка приложения на конкретного пользователя выполняется с использованием некоторых специальных таблиц БД. Например, таблицы профилей пользователей.
SQL-Server ничего не знает ни о каких пользователях и ролях. Вход на сервер (connectionstring) обычный либо с "зашитым" админским логином-паролем

3. Бизнес-логика сервера.
Авторизация выполняется указанием логина-пароля юзера, "зашитого" в БЛ сервера. После успешной авторизации функционал настраивается в соответствии с ролями, определенными на сервере для данного юзера.
Либо показывается весь функционал, но по каждой "кнопке" ловится ошибка (try catch) и, если поймалась, то сообщение "функция недоступна".
Второй вариант нехороший, т.к. создает у юзера иллюзию всемогущества, тут же сменяющуюся досадой, что, оказывается, не все

1

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

0