Article From:https://www.cnblogs.com/sunshine5683/p/9913033.html

 

  From: https://blog.csdn.net/eson_15/article/details/51425010

    In the last section, we finished the basic operation of the shopping cart, but there is a problem: when the user clicks on the settlement, we should make a login judgment to judge whether the user has logged in or not, if not, first let the user login. This uses the filter technology, which is designed to intercept page requests.It is similar to the principle of interceptor, interceptor is designed to intercept action requests, so each has its own use. If it is a page Jump directly, without action, we only need to write an interceptor. If we need to jump to an action process, then we have to write an interceptor.Interceptor.

1. The Principle of Login Jump

        Let’s start with the implementation principle: Write a filter and configure the URL that needs to be intercepted in web.xml. In this way, when the user’s request URL is satisfied with the configuration, we will execute the filter we wrote ourselves. In the filter, we first check whether the session has been logged in or not.User, if there is no explanation for not logging in, then get the page URL and parameters that the user wants to visit, reassemble the URL and put it into session, then redirect to the landing page, jump to Action processing after login, and then jump to session saved after processing.URL is where the original user wants to go. This completes the landing jump.

2. Implementation of Login Jump

        When we click on the checkout page after the actual shopping cart page, it will automatically jump to the order confirmation page, as follows:

        But at this time, if the user is not logged in, we can’t jump directly to the order confirmation page, so we need to use the filter to stop and judge, write the filter below:

2.1 Implementation of filters

        The implementation of filter implements the filter interface and overrides three methods. In fact, we mainly need to override one of them. As follows: 

  1. public class UserFilter implements Filter {
  2.   
  3.  
    @Override
  4.  
    public void destroy() {
  5.  
    // TODO Auto-generated method stub
  6.   
  7.  
    }
  8.   
  9.  
    @Override
  10.  
    public void doFilter(ServletRequest request, ServletResponse response,
  11.  
    FilterChain chain) throws IOException, ServletException {
  12.  
    HttpServletRequest req = (HttpServletRequest) request;
  13.  
    HttpServletResponse res = (HttpServletResponse) response;
  14.  
    // Determine whether the current session has user information
  15.  
    if(req.getSession().getAttribute(“user”) == null) {
  16.  
    //Save the URL address that the current customer wants to go to
  17.  
    String goURL = req.getServletPath();//Get the address the user wants to go to
  18.  
    String param = req.getQueryString(); //Get the parameters carried in the address
  19.  
    if(param != null) {
  20.  
    goURL = goURL + “?” + param; //Respell Request Address + Parameters
  21.  
    }
  22.  
    //Store the address that the current customer wants to access in session
  23.  
    req.getSession().setAttribute(“goURL”, goURL);
  24.  
     
  25.  
    //Illegal request, jump to landing page
  26.  
    req.getSession().setAttribute(“error”, “Illegal request, please login! “”;
  27.  
    res.sendRedirect(req.getContextPath() + “/ulogin.jsp”);
  28.  
    } else {
  29.  
    //If you have the next filter, jump, or go directly to the target page
  30.  
    chain.doFilter(request, response);
  31.  
    }
  32.  
    }
  33.   
  34.  
    @Override
  35.  
    public void init(FilterConfig config) throws ServletException {
  36.  
    // TODO Auto-generated method stub
  37.   
  38.  
    }
  39.  
    }

        From the implementation code, we mainly rewrite the doFilter method. In the method, we first judge whether there is user information in the current session. If there is no login, then we should save the URL address and parameters in the address that the user wants to go to and spell it into a new url.Save it in session and redirect it to the login page to let the user login. If there is user information in the session, it indicates that it has been logged in and released directly to the page users want to go to.

 

        Write the Filter. Don’t forget to configure the URL to be filtered in web.xml. The configuration is as follows:

        So the above ${shop}/ user/confirm.jsp is filtered. Next, let’s look at the landing page, which is actually two boxes, username and password, mainly to see which action it jumps to:

        We see that it jumps to the login method in userAction to execute the logic. Let’s implement userAction:

2.2 ActionImplementation

        In userAction, we first make a login judgment, that is, to find out whether there is a user with the username and password in the database. If successful, we store the user in session, and then return a result to Struts2 for processing. The code is as follows:

  1.  
    @Controller(“userAction”)
  2.  
    @Scope(“prototype”)
  3.  
    public class UserAction extends BaseAction<User> {
  4.  
    public String login() {
  5.  
    //Judgment of landing
  6.  
    model = userService.login(model);
  7.  
    if(model == null) {
  8.  
    session.put(“error”, “Landing failed.
  9.  
    return “login”;
  10.  
    } else {
  11.  
    //Log in successfully, first store the user in session
  12.  
    session.put(“user”, model);
  13.  
    //Jump pages based on whether the goURLs in sessions are valuable or not
  14.  
    if(session.get(“goURL”) == null) {
  15.  
    return “index”; //Skip to the front page
  16.  
    } else {
  17.  
    return “goURL”;
  18.  
    }
  19.  
    }
  20.  
    }
  21.  
    }

        Let’s look at the configuration in struts. xml:

 

        Because we have goURLs in sessions, but in struts. XML we can’t take sessions and parameters like in Java code, but we can take them from the value stack, which is the way to get data from the value stack.

2.3 ServiceLanding judgment of layers

        ServiceLayer is mainly the login method used in the above Action, which is relatively simple to implement, as follows:

 

  1.  
    //userServiceInterface
  2.  
    public interface UserService extends BaseService<User> {
  3.  
    //User logs in and successfully returns the User
  4.  
    public User login(User user);
  5.  
    }
  6.  
     
  7.  
    //userServiceImplImplementation class
  8.  
    @Service(“userService”)
  9.  
    public class UserServiceImpl extends BaseServiceImpl<User> implements
  10.  
    UserService {
  11.  
     
  12.  
    @Override
  13.  
    public User login(User user) {
  14.  
    String hql = “from User u where u.login=:login and u.pass=:pass”;
  15.  
    return (User) getSession().createQuery(hql) //
  16.  
    .setString(“login”, user.getLogin()) //
  17.  
    .setString(“pass”, user.getPass()) //
  18.  
    .uniqueResult();
  19.  
    }
  20.  
     
  21.  
    }

 

        Okay, so we use the filter to realize user login judgment and jump, after login, we can jump to the order confirmation page, the effect is as follows:

 

        The whole process has been tested and the function is normal. In fact, it can be further improved here. We should make login judgment before joining the shopping cart. That is to say, when the shopping cart page is logged in, the order confirmation page judges the login. But before the shopping cart pageJudgment, we can not use filters, we have to use interceptors, because jumping to the shopping cart page requests action, not ordinary pages, when requesting action, we have to use interceptors to judge, later to improve here, now we have basically realized the function here.Besides, login judgment and jump are done.

Leave a Reply

Your email address will not be published. Required fields are marked *