Блог

Я думал о входе в систему через SQL, я создал базовую форму входа, как показано ниже

 protected void btnLogin_Click(object sender, EventArgs e)
{
    string cs="Data Source=Dev-PC;Initial Catalog=CodeSolution;User ID=sa; password=12345678"
    SqlConnection con = new SqlConnection(cs);
    con.Open();
    String sqlCommand = "SELECT * FROM tblLogin WHERE " 
                     "username = @user AND password = @pwd"
    SqlCommand cmd = new SqlCommand(sqlCommand, con);
    cmd.Parameters.AddWithValue("@user", TextBox1.Text);
    cmd.Parameters.AddWithValue("@pwd", TextBox2.Text);
    SqlDataAdapter da = new SqlDataAdapter(cmd);
    DataTable dt = new DataTable();
    da.Fill(dt);
    if (dt.Rows.Count > 0)
    {
        Response.Redirect("Details.aspx");
    }
    else
    {
        Response.Write("<script>alert('Please enter valid Username and Password')</script>");
    }
}
  

Но потом это заставило меня задуматься, потому что без входа в систему люди могут угадать url Details.aspx

И тогда я подумал, что, если вход в систему был успешным, также добавить столбец в tblLogin и сохранить там идентификатор сеанса этого пользователя. Затем страницы должны проверять, равен ли идентификатор сеанса идентификатору tblLogin для этого пользователя.

Мне интересно узнать об этом 2 вещи:

• Как сохранить идентификатор сеанса в tblLogin, как известно серверу IIS
• Является ли это плохим решением, или оно было бы приемлемым (с тем недостатком, что каждая страница asp должна начинаться с функции для проверки на соответствие действительному идентификатору сеанса).

Одна ошибка удалена, аналогичная в SqlCommand, теперь ее =

Похоже, вы делаете так много неправильных вещей, что написание правильного ответа автоматически сделало бы этот вопрос слишком широким. Я попробую:

• Не следует жестко кодировать строки подключения. Сохраните их в своем файле конфигурации и ссылайтесь на них по имени.
• Никогда не используйте свою sa учетную запись, даже для разработки.
• Не добавляйте к таблицам префикс с tbl , это избыточно.
• Не используйте like для имен пользователей и паролей, вам нужно точное совпадение.
• Не храните пароли в виде открытого текста.
• «люди могут угадать URL-адрес Details.aspx» — вы проверяете авторизацию («разрешено ли этому пользователю выполнять это действие») при каждом действии.

Объяснение того, как исправить все эти проблемы, потребует слишком больших усилий. Не изобретайте колесо, называемое авторизацией и аутентификацией. Используйте для этого безопасную, протестированную, поддерживаемую библиотеку.

Возможно, вы захотите изучитьASP.NET Членство или его преемник ASP.NET Идентификация.

Не точный ответ на ваш вопрос, но это будет хорошим руководством / советом.

Ваша идея иметь идентификатор сеанса совсем не плоха (в зависимости от требований вашего сайта / системы). Но в данном случае не сеанс из IIS, потому что вам нужно его расшифровать, что сделает вас уязвимым для встроенной атаки (сделает доступной вашу базу данных / корневую папку).

Вот пример того, как получить идентификатор сеанса сеанса во время входа в систему, но не из IIS (вы можете использовать это для ведения журнала):

string sessionId = System.Web.HttpContext.Current.Session.SessionID;

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