Автоматическая авторизация в программе
Цитата: Иван от 27.08.2022, 11:22Приветствую всех!
Нуждаюсь в Вашей помощи по реализации метода автоавторизации.
Что у меня есть?
При входе в программу пользователь вводит логин\пароль, нажимает кнопку войти, затем на форме main отображаются его данные.
Данные хранятся в базе.
Что я хочу сделать?
При первой авторизации пользователь устанавливает галочку - запомнить меня, после данного действия авторизация не требуется, пользователя после запуска программы сразу перенаправляет на форму main с его данными.Буду рад любой идее, можно без кода, просто описать как бы это сделали Вы.
Приветствую всех!
Нуждаюсь в Вашей помощи по реализации метода автоавторизации.
Что у меня есть?
При входе в программу пользователь вводит логин\пароль, нажимает кнопку войти, затем на форме main отображаются его данные.
Данные хранятся в базе.
Что я хочу сделать?
При первой авторизации пользователь устанавливает галочку - запомнить меня, после данного действия авторизация не требуется, пользователя после запуска программы сразу перенаправляет на форму main с его данными.
Буду рад любой идее, можно без кода, просто описать как бы это сделали Вы.
Цитата: Adler от 27.08.2022, 11:25Добрый день.
БД авторизации на чем основана? Т.е. логин/пароль с чем будет сопоставляться и где будет храниться список пользователей?
Добрый день.
БД авторизации на чем основана? Т.е. логин/пароль с чем будет сопоставляться и где будет храниться список пользователей?
Цитата: Иван от 27.08.2022, 11:26Цитата: Adler от 27.08.2022, 11:25Добрый день.
БД авторизации на чем основана? Т.е. логин/пароль с чем будет сопоставляться и где будет храниться список пользователей?В БД есть таблица пользователей, в ней есть поля log,pass
Цитата: Adler от 27.08.2022, 11:25Добрый день.
БД авторизации на чем основана? Т.е. логин/пароль с чем будет сопоставляться и где будет храниться список пользователей?
В БД есть таблица пользователей, в ней есть поля log,pass
Цитата: Adler от 27.08.2022, 11:32Какая СУБД? И на чем она основана, это независимый список пользователей, на основе пользователей Windows, LDAP/AD и т.д.?
P.S. Обычно пароль в БД никогда не хранится, а сохраняется его хеш или вообще как в протоколе SRP-6a, где данные авторизации можно передавать по небезопасному каналу.
Какая СУБД? И на чем она основана, это независимый список пользователей, на основе пользователей Windows, LDAP/AD и т.д.?
P.S. Обычно пароль в БД никогда не хранится, а сохраняется его хеш или вообще как в протоколе SRP-6a, где данные авторизации можно передавать по небезопасному каналу.
Цитата: Иван от 27.08.2022, 11:42Цитата: Adler от 27.08.2022, 11:32Какая СУБД? И на чем она основана, это независимый список пользователей, на основе пользователей Windows, LDAP/AD и т.д.?
MS SQL, список пользователей не будет зависеть ни от чего. Изначально у нас есть только база, логин и пароль.
Хотя интересно было бы узнать и про доменную авторизацию. Возможно этому имеет смысл быть.
Кажется понял к чему вы клоните. При первом входе записываем информацию о пк в таблицу по типу (ид пользователя, имя машины\пользователя\айпи если локальный\true|false если хочет входить автоматически). Потом в program.cs проверяем перед отдачей формы, есть ли запись от этой машины в базе, если есть и стоит тру, то даем main с его id, если нет, то даем форму авторизации.
Данной мысли есть место быть?
И хотелось бы конечно ещё варианты, для общего развития.
Цитата: Adler от 27.08.2022, 11:32Какая СУБД? И на чем она основана, это независимый список пользователей, на основе пользователей Windows, LDAP/AD и т.д.?
MS SQL, список пользователей не будет зависеть ни от чего. Изначально у нас есть только база, логин и пароль.
Хотя интересно было бы узнать и про доменную авторизацию. Возможно этому имеет смысл быть.
Кажется понял к чему вы клоните. При первом входе записываем информацию о пк в таблицу по типу (ид пользователя, имя машины\пользователя\айпи если локальный\true|false если хочет входить автоматически). Потом в program.cs проверяем перед отдачей формы, есть ли запись от этой машины в базе, если есть и стоит тру, то даем main с его id, если нет, то даем форму авторизации.
Данной мысли есть место быть?
И хотелось бы конечно ещё варианты, для общего развития.
Цитата: Adler от 27.08.2022, 11:58На самом деле я пока никуда не клонил, т.к. было не понятно, что как и где авторизуется вообще.
Отчасти доменная авторизация может одно упростить, а другой усложнить ,т.к. для авторизации будет использоваться не своя БД, а база пользователей AD. А где и как хранить дополнительный флаг авторизации уже вопрос.
Можно сделать так, в AD всех пользователей, кому в теории можно запускать программу выделить в группу. А при первой авторизации создавать локального пользователя в БД программы. Т.е. саму авторизацию проводить через домен, а все остальные настройки сопоставлять с данными в своей БД.
Т.е. при запуске программы проверять можно ли ему вообще пользоваться программой наличием текущего залогиненого пользователя в нужной группе и если он там есть, потом лезть в свою БД и смотреть, можно ли ему запускать в автомате, если да - запускать, если нет - выдавать запрос на авторизацию и через доменные учетные данные проводить авторизацию. Но при такой схеме привязка будет к текущему авторизованному пользователю на ПК.
Хотя это можно доработать и для авторизации других доменных пользователей с принудительным вводом логина и пароля, если основной залогиненный пользователь отличается от авторизуемого.К слову, на C# довольно удобно работать с AD через
System.DirectoryServices.AccountManagement. В гугле довольно много по этому поводу информации.
На самом деле я пока никуда не клонил, т.к. было не понятно, что как и где авторизуется вообще.
Отчасти доменная авторизация может одно упростить, а другой усложнить ,т.к. для авторизации будет использоваться не своя БД, а база пользователей AD. А где и как хранить дополнительный флаг авторизации уже вопрос.
Можно сделать так, в AD всех пользователей, кому в теории можно запускать программу выделить в группу. А при первой авторизации создавать локального пользователя в БД программы. Т.е. саму авторизацию проводить через домен, а все остальные настройки сопоставлять с данными в своей БД.
Т.е. при запуске программы проверять можно ли ему вообще пользоваться программой наличием текущего залогиненого пользователя в нужной группе и если он там есть, потом лезть в свою БД и смотреть, можно ли ему запускать в автомате, если да - запускать, если нет - выдавать запрос на авторизацию и через доменные учетные данные проводить авторизацию. Но при такой схеме привязка будет к текущему авторизованному пользователю на ПК.
Хотя это можно доработать и для авторизации других доменных пользователей с принудительным вводом логина и пароля, если основной залогиненный пользователь отличается от авторизуемого.
К слову, на C# довольно удобно работать с AD через СкопированоSystem.DirectoryServices.AccountManagement. В гугле довольно много по этому поводу информации.
Цитата: Иван от 27.08.2022, 13:55Цитата: Adler от 27.08.2022, 11:58На самом деле я пока никуда не клонил, т.к. было не понятно, что как и где авторизуется вообще.
Отчасти доменная авторизация может одно упростить, а другой усложнить ,т.к. для авторизации будет использоваться не своя БД, а база пользователей AD. А где и как хранить дополнительный флаг авторизации уже вопрос.
Можно сделать так, в AD всех пользователей, кому в теории можно запускать программу выделить в группу. А при первой авторизации создавать локального пользователя в БД программы. Т.е. саму авторизацию проводить через домен, а все остальные настройки сопоставлять с данными в своей БД.
Т.е. при запуске программы проверять можно ли ему вообще пользоваться программой наличием текущего залогиненого пользователя в нужной группе и если он там есть, потом лезть в свою БД и смотреть, можно ли ему запускать в автомате, если да - запускать, если нет - выдавать запрос на авторизацию и через доменные учетные данные проводить авторизацию. Но при такой схеме привязка будет к текущему авторизованному пользователю на ПК.
Хотя это можно доработать и для авторизации других доменных пользователей с принудительным вводом логина и пароля, если основной залогиненный пользователь отличается от авторизуемого.К слову, на C# довольно удобно работать с AD через
System.DirectoryServices.AccountManagement. В гугле довольно много по этому поводу информации.Спасибо большое за ответ!
Цитата: Adler от 27.08.2022, 11:58На самом деле я пока никуда не клонил, т.к. было не понятно, что как и где авторизуется вообще.
Отчасти доменная авторизация может одно упростить, а другой усложнить ,т.к. для авторизации будет использоваться не своя БД, а база пользователей AD. А где и как хранить дополнительный флаг авторизации уже вопрос.
Можно сделать так, в AD всех пользователей, кому в теории можно запускать программу выделить в группу. А при первой авторизации создавать локального пользователя в БД программы. Т.е. саму авторизацию проводить через домен, а все остальные настройки сопоставлять с данными в своей БД.
Т.е. при запуске программы проверять можно ли ему вообще пользоваться программой наличием текущего залогиненого пользователя в нужной группе и если он там есть, потом лезть в свою БД и смотреть, можно ли ему запускать в автомате, если да - запускать, если нет - выдавать запрос на авторизацию и через доменные учетные данные проводить авторизацию. Но при такой схеме привязка будет к текущему авторизованному пользователю на ПК.
Хотя это можно доработать и для авторизации других доменных пользователей с принудительным вводом логина и пароля, если основной залогиненный пользователь отличается от авторизуемого.К слову, на C# довольно удобно работать с AD через
СкопированоSystem.DirectoryServices.AccountManagement. В гугле довольно много по этому поводу информации.
Спасибо большое за ответ!