2015-10-15 4 views
0

У меня есть немного тайны на руках, и я надеюсь, что вы все поможете мне разобраться.Страница входа в систему Mystery ASP.Net C#

Я создаю страницу входа для веб-приложения Asp.net C#. Страница входа в систему - это просто страница веб-формы с двумя текстовыми полями для ввода имени пользователя и пароля (с ярлыками имен), кнопкой входа в систему и скрытой меткой сообщения, которая отображается через обратный код, если мне это нужно.

Обработчик события для входа в систему состоит из двух частей.

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

До этого момента код работает так, как он предназначен.

Теперь идет вторая часть.

Когда запрашивается БД и найдена соответствующая запись, у меня есть эта запись, заполненная в набор данных, и я установил строковую переменную, называемую AccessLevel, чтобы равняться значению поля userAccessLvl из таблицы БД. Затем я запускаю оператор switch для оценки значения.

Если значение = «A» (для администратора), страница входа в систему должна перенаправить пользователя на страницу администратора.

Если значение = «S» (для стандартного пользователя), страница входа должна перенаправить пользователя на страницу учетной записи клиента.

Кроме того, оба параметра задают переменные сеанса, называемые UserName и AccessLevel.

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

Код для обработчика событий.

Любые мысли? Если это важно, я запускаю VS 2015 Community и Access 2010 DB.

Спасибо.

public partial class logIn : System.Web.UI.Page 
{ 
private OleDbConnection connection = new OleDbConnection(); 
private dsUserLogIn LogInData; 
private OleDbDataAdapter sqlDA; 
private string AccessLevel; 

protected void Page_Load(object sender, EventArgs e) 
{ 
    connection.ConnectionString = "Provider=Microsoft.ACE.OLEDB.12.0; Data Source=E:\\Documents\\Visual Studio 2015\\WebSites\\OneStopFurniture\\App_Data\\OneStopFur.accdb"; 

} 

protected void btn_LogIn_Click(object sender, EventArgs e) 
{ 

    sqlDA = new OleDbDataAdapter("SELECT userName, [password], userAccessLvl FROM [userInfo] WHERE userName ='" + txtUserName.Text + "' AND [password] ='" + txtPassword.Text + "'", connection); 
    LogInData = new dsUserLogIn(); 
    sqlDA.Fill(LogInData.userInfo); 

    if(LogInData.userInfo.Count == 1) 
    { 
     lblLogInMessage.Visible = true; 
     lblLogInMessage.Text = "Username and Password are correct."; 
    } 
    else 
    { 
     lblLogInMessage.Visible = true; 
     lblLogInMessage.Text = "Username and Password are not correct."; 
    } 

    AccessLevel = LogInData.userInfo[0].userAccessLvl.ToString(); 

    switch (AccessLevel) 
    { 
     case "A": 

      Session["UserName"] = txtUserName.Text; 
      Session["AccessLevel"] = "A"; 
      Response.Redirect("adminArea.aspx"); 
      break; 

     case "S": 
      Session["UserName"] = txtUserName.Text; 
      Session["AccessLevel"] = "S"; 
      Response.Redirect("customerAcctArea.aspx"); 
      break; 

     default: 
      break; 
    } 
} 

}

РЕДАКТИРОВАТЬ ------------------------------------- ---------------

ОК. Я установил разрыв кода, чтобы проверить значение AccessLevel, когда найдена запись администратора. AccessLevel установлен на «A»; как и предполагалось.

Я также установил разрыв после сеанса ["AccessLevel"] = "A" и проверил это значение. Снова значение установлено на «A»; как и предполагалось.

Наконец, я проверил файл web.config и не нашел ничего, что ограничивало бы доступ к любым страницам.

Это заставило меня задаться вопросом, может ли проблема не оказаться в функции Page_Load на разных страницах учетной записи, а не на странице входа.Функция Page_Load как для учетной записи клиента и на страницах администратора содержат идентичный блок

protected void Page_Load(object sender, EventArgs e) 
{ 
    if(Session["AccessLevel"] == null) 
    { 
     Response.Redirect("login.aspx"); 
    } 
    else 
    { 
     lblWelcome.Text = "WELCOME BACK " + Session["UserName"]; 
    } 
} 

кода Теперь снова, для обычного пользователя («S») счетов, все работает отлично. Это учетные записи администратора («А»), которые не работают.

Небольшое исследование Google предполагает, что ASP.net не любит идентичный код, подобный этому, на нескольких страницах и может вызвать непреднамеренные функции.

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

Считаете ли вы, что, поскольку кодовые блоки на двух страницах идентичны, возможно, что код Page_Load на странице администратора будет считать объект сеанса равным нулю (хотя это не так) и затем перенаправить меня обратно на вход? Будет ли создание отдельного файла класса для блока кода возможной работой? Или мне просто нужно пройти долгий путь, чтобы вернуться к той же проблеме?

Просто бросайте некоторые идеи там, пытаясь обернуть голову вокруг этого. Спасибо за любую предоставленную помощь.

+1

adminArea.aspx ограничен в конфигурации ASP? Это могло бы объяснить это. – Duston

+4

Не отвечая на ваш вопрос, я хотел бы указать на две основные проблемы, которые у вас есть. Сначала ваши пароли хранятся в открытом виде, что никогда не должно происходить. Во-вторых, вы ОЧЕНЬ уязвимы для SQL-инъекций - я могу обойти вашу проверку безопасности и быть администратором вашей системы, введя довольно простое имя пользователя в вашем текстовом поле. – DavidG

+3

Обязательные замечания: не сворачивайте свою собственную безопасность, хеш-пароли и избегайте SQL-инъекций. Этот сайт очень опасен. –

ответ

1

Кроме того, что другие упомянули о дефекте в дизайне, у вас есть случай для A и S и ничего по умолчанию. Скорее всего, это случай, когда дело никогда не попадает, и вы собираетесь по умолчанию, поэтому вы остаетесь на той же странице. Отладка, чтобы проверить, что ваш уровень доступа, когда вы думаете, что это должно быть A.

//set breakpoint here to make sure you get an A 
AccessLevel = LogInData.userInfo[0].userAccessLvl.ToString(); 

    switch (AccessLevel) 
    { 
     case "A": 

      Session["UserName"] = txtUserName.Text; 
      Session["AccessLevel"] = "A"; 
      Response.Redirect("adminArea.aspx"); 
      break; 

     case "S": 
      Session["UserName"] = txtUserName.Text; 
      Session["AccessLevel"] = "S"; 
      Response.Redirect("customerAcctArea.aspx"); 
      break; 

     default: 
      break; //you are just falling through to here, not redirecting. 
    } 
+0

@stephen ... Я загляну в него и отчитаю. Благодарю. – tworley1977

Смежные вопросы