In the previous section, we completed the basic operation of the shopping cart, but there is a problem: when the user clicks to settle, we should make a login judgment to determine whether the user is logged in. If he is not logged in, he must first let the user log in. This uses the technology of filters. The filter specifically intercepts page requests. It is similar to the principle of an interceptor. The interceptor specifically intercepts Action requests, so each has its own uses. If it is a page jump directly without going through an Action, we just need to write an interceptor. If we need to jump to an Action for processing, then we have to write an interceptor.
1. The principle of login jump <br /> Let me first talk about 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 meets the configuration, the filter we wrote will be executed. In the filter, we first check whether there is a user logged in the session. If there is no indication that there is no login, then get the page url and parameters that the user wants to access, re-stitch it into the url and put it in the session, and then redirect to the login page, log in and jump to the Action processing, and after processing, jump to the url saved in the session, that is, where the user originally wanted to go. This completes the login jump.
2. Login jump implementation
When the real shopping cart page is used, we click on checkout, and it will automatically jump to the order confirmation page, as follows:
However, if the user is not logged in at this time, we will definitely not jump to the order confirmation page directly, so we have to use a filter to block it and make a judgment. Let’s write the filter below:
2.1 Implementation of filters
The filter implementation needs to implement the Filter interface and overwrite three methods. In fact, we mainly need to overwrite one of them. as follows:
public class UserFilter implements Filter { @Override public void destroy() { // TODO Auto-generated method stub } @Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req = (HttpServletRequest) request; HttpServletResponse res = (HttpServletResponse) response; // Determine whether the current session has user information if(req.getSession().getAttribute("user") == null) { //Save the URL address that the current customer wants to go to String goURL = req.getServletPath();//Get the address that the user wants to go to String param = req.getQueryString(); //Get the parameters carried in the address if(param != null) { goURL = goURL + "?" + param; //Re-stitch the request address + parameters} //Save the address that the current customer wants to access in the session req.getSession().setAttribute("goURL", goURL); //Illegal request, jump to the login page req.getSession().setAttribute("error", "Illegal request, please log in!"); res.sendRedirect(req.getContextPath() + "/ulogin.jsp"); } else { //If there is the next filter, jump, otherwise go directly to the target page chain.doFilter(request, response); } } @Override public void init(FilterConfig config) throws ServletException { // TODO Auto-generated method stub } } Judging from the implementation code, the doFilter method is mainly diarrhea. In the method, first determine whether there is user information in the current session. If not, it means that there is no login. Then you must first save the URL address and parameters in the address that the user wants to go to, spell it into a new URL and save it in the session, and then redirect it to the login page to let the user log in. If there is user information in the session, it means that you have logged in and directly release it to the page the user wants to go to.
After writing Filter, don't forget to configure the url to filter in web.xml, as follows:
So the above ${shop}/user/confirm.jsp will be filtered. Next, let’s take a look at the login page. It actually has two boxes, username and password, which mainly depends on which action it jumps to:
We see that it jumps to the login method in userAction to execute logic. Here we implement userAction:
2.2 Action Implementation
In userAction, we first make a login judgment, that is, look for users with the user name and password in the database. If it is successful, save the user in the session, and then return a result and hand it over to struts2 for processing. The code is as follows:
@Controller("userAction") @Scope("prototype") public class UserAction extends BaseAction<User> { public String login() { //Judgement of login model = userService.login(model); if(model == null) { session.put("error", "Login failed"); return "login"; } else { //Login successfully, first store the user in session session.put("user", model); //Defend the page's jump based on whether the goURL in the session has a value if(session.get("goURL") == null) { return "index"; //Skip to homepage} else { return "goURL"; } } } }Let's take a look at the configuration in struts.xml:
Because we have the goURL in session, but in struts.xml, we cannot get the session and then the parameters in Java code, but we can take it from the value stack. The above is the method of getting data from the value stack.
2.3 Login judgment of the Service layer
The Service layer is mainly the login method used in the above Action, and the implementation is relatively simple, as follows:
//userService interface public interface UserService extends BaseService<User> { //The user logs in and returns the User public User login(User user); } //userServiceImpl implementations @Service("userService") public class UserServiceImpl extends BaseServiceImpl<User> implements UserService { @Override public User login(User user) { String hql = "from User u where u.login=:login and u.pass=:pass"; return (User) getSession().createQuery(hql) // .setString("login", user.getLogin()) // .setString("pass", user.getPass()) // .uniqueResult(); } }OK, so we use filters to realize the judgment and jump of user login. After logging in, we can jump to the order confirmation page. The effect is as follows:
The entire process test has been completed and the function is normal. In fact, we can improve it a little more. We should actually make a login judgment before adding it to the shopping cart. That is to say, the shopping cart page is already in the login state, and here is the order confirmation page to determine the login. However, if we make judgments before the shopping cart page, it will be difficult for us to use the filter. We have to use the interceptor, because the request for Action is not an ordinary page when jumping to the shopping cart page. When requesting Action, we have to use the interceptor to intercept it. Let's improve this later. Now we will basically implement the functions here. Okay, login judgment and jump are done.
Original address: http://blog.csdn.net/eson_15/article/details/51425010
The above is all the content of this article. I hope it will be helpful to everyone's learning and I hope everyone will support Wulin.com more.