На C# в WPF метод входа в SQL типа bool вам пользователь
Всем привет,
У меня есть метод входа в систему, чтобы проверить, является ли пользователь членом моей БД. Мой метод входа в систему-это всего лишь bool, и мне интересно, как я могу захватить эти текущие данные пользователей, чтобы передать их в следующее окно. Я проверяю текстовые поля, чтобы убедиться, что текст действителен.
Один из способов, которым я знаю, что могу решить эту проблему, - это изменить свой метод входа в систему, чтобы он возвращал пользователя, тогда у меня будет этот конкретный пользователь, но я хотел бы посмотреть, смогу ли я захватить пользовательские данные, проверив, находятся ли они в БД.
Вот что у меня есть:
//Login XAML window. private void BtnLoginUser_Click(object sender, RoutedEventArgs e){ if (string.IsNullOrEmpty(txtUsername.Text)) { //verify and enter username. MessageBox.Show("Enter your username.", "Empty", MessageBoxButton.OK, MessageBoxImage.Information); txtUsername.Focus(); return; } else if (string.IsNullOrEmpty(txtPassword.Password)) { MessageBox.Show("Enter your password.", "Empty", MessageBoxButton.OK, MessageBoxImage.Information); txtPassword.Focus(); return; } else { try { if(SQLuserAccess.UserLogin(txtUsername.Text, txtPassword.Password)){ } } } } //SQL login method public static bool UserLogin(string username, string password) { bool valid = false; //SQL Login Query. string SQLloginQuery = "SELECT * FROM Users WHERE Username=@username AND Password=@password"; SqlCommand cmdLogin = new SqlCommand(SQLloginQuery, connection); cmdLogin.Parameters.AddWithValue("@username", username); cmdLogin.Parameters.AddWithValue("@password", password); try { connection.Open(); int result = (int)cmdLogin.ExecuteScalar(); if (result > 0) { valid = true; MessageBox.Show("Login success"); } else MessageBox.Show("Login Failed"); } catch (Exception ex) { ex.Message.ToString(); throw ex; } finally{ connection.Close(); } return valid; } //This is a method I use to get the user public static User GetUserById(int userId{ string SQLreadQuery = "SELECT Username, Password, IsAdmin, UserCreatedDate " + "FROM Users WHERE UserId = " + userId; //or SELECT ea column or *. SqlCommand cmdRead = new SqlCommand(SQLreadQuery, connection); try{ connection.Open(); SqlDataReader reader = cmdRead.ExecuteReader(CommandBehavior.SingleRow); if(reader.Read()){ User user = new User(); user.UserID = Convert.ToInt32(reader["UserId"]); user.Username = reader["Username"].ToString(); user.Password = reader["Password"].ToString(); user.IsAdmin = Convert.ToBoolean(reader["IsAdmin"]); user.UserCreatedDate = Convert.ToDateTime(reader["UserCreatedDate"]); return user; } else{ return null; } } catch(Exception ex){ ex.Message.ToString(); return null; } finally{ connection.Close(); } }
Что я уже пробовал:
Я знаю, что могу решить эту проблему, вернув пользователя вместо Bool, но я хотел бы посмотреть, смогу ли я сделать это так
Возможно, если я верну объект пользователя с помощью GetUserById (), то смогу получить эти данные.
хочу ли я хранить эти данные в таблице данных? или просто в клиентском объекте
Richard Deeming
Вы храните пароли в виде обычного текста. Не делай этого!
Безопасная Аутентификация Паролем Объясняется Просто[^]
Соленое хэширование паролей - делаем это правильно[^]
Richard Deeming
string SQLreadQuery = "SELECT Username, Password, IsAdmin, UserCreatedDate " + "FROM Users WHERE UserId = " + userId;
Почему?! Вы уже знаете, как использовать параметры, так почему же здесь что-то не так?
В данный случай, так как параметр является
int
, вы, вероятно, избежали уязвимости SQL-инъекции. Но ты все еще поощряешь дурные привычки. А когда вы или кто-то другой позже изменяете код, чтобы передать string
вместо этого нет никакого предупреждения о критической уязвимости безопасности, которая будет введена.Кроме того, использование конкатенации строк вместо параметров может отрицательно сказаться на производительности. SQL не сможет использовать кэшированный план выполнения для запроса, так как запрос будет каждый раз отличаться.
Использовать параметры. Используйте их каждый раз, даже когда вы "знаете", что было бы безопасно не делать этого.
Все, что вы хотели знать о SQL-инъекции (но боялись спросить) | Трой Хант[^]
Как я могу объяснить SQL-инъекцию без технического жаргона? | Обмен Стеками Информационной Безопасности[^]
Шпаргалка по параметризации запросов | OWASP[^]