String sql = "select * from reg, где username = '" + user + "' и pass = '" + pwd + "'";

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

Используйте сессии, в JSP / Servlet там у вас есть HttpSessionдля. На самом деле также нет необходимости снова и снова нажимать на БД при каждом запросе, используя Filter. Это излишне дорого. Просто включите Userсеанс с помощью a Servletи используйте Filterдля проверки его присутствия при каждом запросе.

Начните с /login.jsp:

<form action="login" method="post">
    <input type="text" name="username">
    <input type="password" name="password">
    <input type="submit"> ${error}
</form>

Затем, создать LoginServletкоторый отображается на url-patternиз /loginи имеет doPost()реализуется следующим образом :

String username = request.getParameter("username");
String password = request.getParameter("password");
User user = userDAO.find(username, password);

if (user != null) {
    request.getSession().setAttribute("user", user); // Put user in session.
    response.sendRedirect("/secured/home.jsp"); // Go to some start page.
} else {
    request.setAttribute("error", "Unknown login, try again"); // Set error msg for ${error}
    request.getRequestDispatcher("/login.jsp").forward(request, response); // Go back to login page.
}

Затем, создать LoginFilterкоторый отображается на url-patternиз /secured/*(вы можете выбрать свой собственный , однако, например /protected/*, /restricted/*, /users/*и т.д., но это необходимо по крайней мере охватывать все обеспеченные страницы, вы также должны поставить JSP находится в соответствующей папке в WebContent) и имеет doFilter()реализовано следующим образом:

HttpServletRequest request = (HttpServletRequest) req;
HttpServletResponse response = (HttpServletResponse) res;
HttpSession session = request.getSession(false);
String loginURI = request.getContextPath() + "/login.jsp";

boolean loggedIn = session != null && session.getAttribute("user") != null;
boolean loginRequest = request.getRequestURI().equals(loginURI);

if (loggedIn || loginRequest) {
    chain.doFilter(request, response); // User is logged in, just continue request.
} else {
    response.sendRedirect(loginURI); // Not logged in, show login page.
}

Это должно быть так. Надеюсь это поможет.

Чтобы понять, как UserDAOбудет выглядеть an , вы можете найти эту статью полезной. В нем также рассказывается, как использовать PreparedStatementвеб-приложение для защиты от атак с использованием SQL-инъекций.

Смотрите также:

• Как перенаправить на страницу входа, когда сеанс истек в веб-приложении Java?
• Фильтр аутентификации и сервлет для входа
• Как обрабатывать аутентификацию / авторизацию с пользователями в базе данных?

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

Connection con = getMyConnection();
        try {
                //no string concatenation, we use ? instead:
                PreparedStatement ps = con.prepareStatement("select * from reg where username=? and pass=?");
                try {
                        //actual value for parameters are set here:
                        ps.setString(1, user);
                        ps.setString(2, pwd);
                        ResultSet rs = ps.executeQuery();
                        if(rs.next()) {
                                chain.doFilter(request,response);
                        } else {
                                sc.getRequestDispatcher("/error.html").forward(request,response);
                        }

                } finally {
                        ps.close();
                }
        } finally {
                con.close();
        }

Теперь по вашему вопросу, пожалуйста, проверьте:

• что имена таблиц и столбцов правильные (разве у вас нет столбца «логин» и «имя пользователя»?)
• что значения действительно правильные (попробуйте запрос в sqldevelopper, например)
• что он работает с паролем ascii-7 и именем пользователя (это может быть проблемой кодирования)
• что столбец пароля содержит реальный пароль, а не его хеш

Столько всего плохого в этом ...: - /

1. Большой - SQL-инъекция . Не пишите еще одну строчку SQL в своем коде, пока не поймете это. И это не преувеличение для эффекта; код, написанный без понимания этого, может дать злоумышленнику произвольный доступ к вашей базе данных.
2. Вы не должны быть в состоянии выполнить такой запрос, потому что вы никогда не должны хранить пароли в открытом тексте. Вместо этого вы должны рассчитать и сохранить какой-то (желательно соленый) хэш пароля, а затем хешировать представленный пароль и сравнить его. См., Например, Как лучше всего хранить логин и пароль пользователя и Salting ваш пароль здесь на SO. Это особенно плохо, учитывая вашу уязвимость SQL-инъекций.
3. select * from regявляется ненужным, учитывая, что вы просто хотите знать, существует ли строка. Если бы вы использовали select 1вместо этого базу данных, вам не пришлось бы проверять содержимое строки, и она могла бы обслуживать результаты запроса только из индекса. Если вы ожидаете, что будет много строк, select 1 where exists ...это будет быстрее, поскольку это позволит БД выполнить короткое замыкание запроса после нахождения хотя бы одной строки.
4. Вы не закрываете оператор и набор результатов в finallyблоках. Это означает, что они не всегда будут утилизированы (например, если есть SQLExceptionвыброс), что приведет к утечке ресурсов и соединения.

Прежде всего, вы действительно должны использовать для этого параметризованные запросы. Если пользователь входит '";DROP TABLE reg;в качестве имени пользователя, у вас будут большие проблемы.

Кроме того, вы уверены, что имя пользователя и пароль верны? Как насчет капитализации?