Написать код для авторизации

нужен код для проверки пароля и логина из mssql в C#,

Миниатюры

 

Вложения

Архив WinRAR.rar (382.4 Кб, 9 просмотров)

0

В этой теме человек хотя бы старается сделать что-то, темы похожие, а у вас что не получается ?

0

Не понимаю одного... Зачем, используя MS SQL Server у которого есть мощнейший инструмент контроля пользователей, городить какие-то таблицы с логинами и паролями?

0

Andrey-MSK, потому, что пользователи SQL Server'а - это пользователи SQL Server'а. И далеко не всегда это живые люди. Бекенд веб-приложения - пользователь SQL Server'а. Этот бекэнд один (один экземпляр приложения, процесс), значит и пользователь один. А вот пользователи в самой системе (те, что более-менее живые) - уже оформляются силами самого сервера приложения, со всем атрибутами и особенностями этого приложения.

Пользователи SQL Server'а - просто аспект хранилища данных. Пользователи в самой системе - точно такие же данные как и всё остальное. Не надо смешивать тёплое с мягким просто потому, что есть такая возможность.

0

Usaga, ну может быть я и ошибаюсь, но я бы организовал все это совсем по другому
Просто не понимаю, зачем при такой строке подключения
которая явно показывает то, что приложение работает с сервером от имени администратора, так как думаю ТС не стал делать отдельного пользователя в Windows для работы, городить таблицы с логинами и паролями? Толку от них? Я в контексте именно этого проекта, а не глобально. И таких проектов тут куча, коннект от админа и таблички с логинами и паролями.
Заводишь на SQL Server специального пользователя, который ТОЛЬКО имеет право создать пользователя с ограниченными правами (строка подключения одна), новый пользователь вводит свои данные, жмакает создать пользователя, и подключается вторая строка, уже с его данными и он спокойно по форме заходит под своей учеткой на сервер. Я бы думал в эту сторону, а не в таблички....

0

Andrey-MSK, и таки шо? Мне надо под каждого юзера заводить пользователя sql server.
Создавать лично для него строку подключения
Паролить и сохранять ее.
И все это делать программно, вы знаете как? Я понятия не имею.
Мне уж проще вставить 1 запись в свою колхозную таблицу User

0

Andrey-MSK, очень круто) А что нам делать, когда нам нужно какое-то правило доступа, которое силами SQL Server'а не моделируется? К примеру, запретить пользователю доступ к каталогам товара на складах Ростова? Или вы планируете ковырять СУБД каждый раз, добавляя вьюхи и процедуры?

Пользователь в строке подключения - только аспект работы хранилища, которое может быть и на базе простой файловой системы. Этот пользователь - весь процесс целиком, а не отдельно взятый оператор. То, что сервер приложения цепляется к СУБД с полными правами не значит, что все пользователи работающие с этим сервером приложения тоже в раз становятся дофига админами.

Не надо смешивать пользователей вашей системы и пользователей СУБД. Это разный уровень абстракций.

0

Рядовой, а про то что можно менять строки подключения вы не знали? Вы же передаёте строку для объекта Connection, кто мешает ему сунуть ту строку, которая нужна именно в этот момент?
Строк всего две. Одна для создания нового пользователя, она работает по умолчанию со своим ограниченным пользователем SQL Server который и создает пользователей для работы (из введенных данных в форме регистрации) с заранее условленными ограничениями (больше этот пользователь вообще ничего не умеет). Вторая, для работы, строится динамически с данными пользователя из формы входа.
MS SQL Server СУБД корпоративного класса, безопасность данных у него стоит на первом месте, поэтому и надо работать с теми средствами, которые он предоставляет, а не изобретать непонятно что... Если делать, то делать сразу нормально.
А вот эта запись в строке - Integrated Security=True - используется для работы в корпоративной сети с условием того, что пользователь вошел в систему Windows в своем домене. И этот пользователь уже есть в базе данных, добавление этого пользователя делается руками, и все разрешения для него тоже выставляются руками. На локальной машине разработчика строка с этой записью это соединение от имени админа со всеми вытекающими последствиями.
Как-то так... Может где и ошибаюсь, пусть знающие подправят

0

Сообщение от Andrey-MSK Вы же передаёте строку для объекта Connection, кто мешает ему сунуть ту строку, которая нужна именно в этот момент?

Т.е. вы для каждого пользователя\оператора вашей системы предлагаете использовать собственную строку подключения просто потому, что некоторые возможности авторизации есть в СУБД?

0

Usaga, а вы знаете все возможности управления доступом в MS SQL Server?. Разговор именно про эту СУБД. Вы знаете что там можно настроить доступ вплоть до отдельных полей в таблице, как вы настроите это своими табличками? Будете писать GRANT в коде, и как интересно, если такой пользователь существует только в вашей табличке, а не в БД? Там есть группы пользователей, которым можно то и нельзя это, там есть много чего. Потому и говорю, что при работе с продуктами такого класса лучше использовать их возможности. Там ведь тоже не дураки сидят и выдумают всякие политики безопасности и защиты

0

Вы конечно все молодцы. Но по теме так и никто не написал.
айнур2310, начнем с того, что ты в бд хранишь сам пароль, но я думаю у тебя приложение - любительское самописное приложение, то можешь и так сделать. А по правильному необходимо хэш пароля хранить, а не сам текстовый пароль, чтобы твой пароль с бд не стырили.

в трех словах:
1. вводится логин пароль
2. нажимается кнопка входа
3. считываются введенные логин и пароль
4. пишешь sql запрос на существование такого логина, если такой логин существует, то необходимо возвратить логин+пароль(не рассматриваю ситуацию с хешем пароля) или же сразу как то сравнивать пароли, далее сравниваешь введенный пароль с возвращенным паролем, если пароли совпадают, то даешь доступ, иначе нет.

Добавлено через 3 минуты
хотя даже сразу можно наверное в 4 пункте сделать проверку существования записи с таким логином и паролем типа:

0

Сообщение от Andrey-MSK а про то что можно менять строки подключения вы не знали? Вы же передаёте строку для объекта Connection, кто мешает ему сунуть ту строку, которая нужна именно в этот момент?

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

0

Рядовой, вы шутите? Хранимка для создания пользователя, примерно так (можно дальше ее расширить с паролями, логинами, разрешениями, ролями и т.д.)
Доступ только на ее выполнение дается пользователю для создания учеток в БД. Запускаете приложение, форма - два поля, три кнопки (Регистрация, Вход, Закрыть) На регистрацию вешаете вызов этой хранимки из под пользователя для создания и его строку подключения, на Вход вешаете вторую строку с параметрами User и Password, Сервер должен работать в режиме Аутентификации SQL. Примерно как-то так
Если делается приложение для работы в корпоративной среде, ничего этого не надо. Trusted Connection, сервер в режим Windows и руками на сервере всех пользователей обрабатывать. Обычно создаются групповые политики и все делается довольно быстро.

0

Andrey-MSK, ещё раз: СУБД моделирует только правила доступа к хранимым в ней данным в том виде. Оно не может моделировать бизнес-логику. Любые попытки вкорячить хотя бы хранимку, это уже расширение и надстройка того, чего в СУБД нет. Это раз. Два: многие правила вообще не относятся к доступу к данным никаким образом, а только регулируют какие-то действия или выбор логики обработки данных. Т.е. правила существуют ещё до обращения к СУБД. Вы это тоже силами СУБД будете моделировать? Опять же, исключительно собственными силами SQL Server'а, без введения дополнительных сущностей! Нет.

0

Usaga, то есть вы считаете что городить свои таблички с логинами и паролями в изначально многопользовательском продукте со встроенными функциями управления пользователями это нормально? Ну ладно, ваше право
В моем понимании вся бизнес-логика вертится вокруг данных, которые хранятся в БД и должны быть туда введены и получены в том виде, в каком мне надо. Пользователи, которые работают с этими данными имеют четкие разрешения на определенные действия в БД, такие как просмотр, ввод, изменение, удаление. Это все настраивается с помощью встроенных возможностей SQL Server. В моем приложении сейчас работает 153 человека, у всех есть учетки в SQL Server, и каждый имеет право на ОПРЕДЕЛЕННЫЕ действия в БД (кто-то видит одно и не видит другого, кто-то может только смотреть, другие могут редактировать и вводить новое и т.д.). 99% расчетов ведутся силами SQL Server, а клиентская часть только дает возможность ввести, отредактировать данные и вывести их в удобоваримом формате.
И кстати, хранимые процедуры и пользовательские функции это такая же встроенная возможность SQL Server как и язык T-SQL для него

0

Сообщение от Andrey-MSK В моем приложении сейчас работает 153 человека, у всех есть учетки в SQL Server, и каждый имеет право на ОПРЕДЕЛЕННЫЕ действия в БД

А если что-то нужно будет изменить в правах, менять не вспотеете ? Т.е. у вас теоретически 153 "дырки" в безопасности ?

Добавлено через 49 секунд
Аааа, я понял, они (153 чела) работают напрямую, не через сервер приложений )))), тогда понятно

0

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

0

Сообщение от Andrey-MSK то есть вы считаете что городить свои таблички с логинами и паролями в изначально многопользовательском продукте со встроенными функциями управления пользователями это нормально? Ну ладно, ваше право

Не городить, а моделировать то, что СУБД не может и не должно.

Добавлено через 48 секунд

Сообщение от Andrey-MSK моем приложении сейчас работает 153 человека, у всех есть учетки в SQL Server, и каждый имеет право на ОПРЕДЕЛЕННЫЕ действия в БД (кто-то видит одно и не видит другого, кто-то может только смотреть, другие могут редактировать и вводить новое и т.д.)

И права на вещи с СУБД не связанные тоже СУБД определяются?

0

Сообщение от Usaga И права на вещи с СУБД не связанные тоже СУБД определяются?

А как это относится к нашему разговору? Разговор идет про логины и пароли в самопальных табличках. И как это они не связаны с СУБД, если они там хранятся?
А поменять интерфейс, в зависимости от группы залогиненного пользователя, это вполне себе решаемая задача. Не будет же у вас 200 групп чтоб рисовать под них 200 интерфейсов.

0

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

Сообщение от Andrey-MSK Разговор идет про логины и пароли в самопальных табличках.

ОК. Система над которой я работаю, умеет авторизировать не только по логину и паролю (и по AD), но и по внешним системам типа SAML. Мне это как надо было силами СУБД реализовывать?

Сообщение от Andrey-MSK Разговор идет про логины и пароли в самопальных табличках.

Ещё и про права доступа к функциям системы. Моя система интегрируется с несколькими внешними (наши и чужие). Права распространяются и на доступ к этим вещам. Как вы это силами СУБД собрались моделировать без введения дополнительных сущностей и доступа к ним со стороны приложения?

1