代码实现来验证请求的流程

userController内增加login登陆的方法。

 @GetMapping("/login")

    public void login(@Validated UserInfo user,HttpServletRequest request){

        UserInfo info = userService.login(user);

        request.getSession().setAttribute("user",user);

    }

userService内增加login方法

UserInfo login(UserInfo user);

实现类实现login的方法

 @Override

    public UserInfo login(UserInfo info) {

        UserInfo result=null;

        User user=userRepository.findByUsername(info.getUsername());

        if(user!=null && SCryptUtil.check(info.getPassword(),user.getPassword())){

            result=user.buildInfo();

        }

        return result;

    }

因为之前做的授权的拦截器，把所有的请求都给拦截了。修改登陆时候我们不需要拦截，

定义一个数组，把不需要拦截的url放在数组内。

请求的路径如果不在我们的数组内就执行原来访问控制的逻辑。

如果是登陆的路径的话，不判断Attribute是否存在user了，也不判断请求的方法是否有权限了。直接返回true

private String[] permitUrls=new String[] {"/users/login"};

    @Override

    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {

        System.out.println();

        boolean result=true;

        if(!ArrayUtils.contains(permitUrls,request.getRequestURI())){

            User user=(User)request.getAttribute("user");

            if (user==null){

                response.setContentType("text/plain");

                response.getWriter().write("need authentication");

                response.setStatus(HttpStatus.UNAUTHORIZED.value());

                return false;

            }else{

                String method = request.getMethod();

                if(!user.hasPermission(method)){

                    response.setContentType("text/plain");

                    response.getWriter().write("forbidden");

                    response.setStatus(HttpStatus.FORBIDDEN.value());

                    return false;

                }

            }

        }

        return result;

    }

启动服务进行测试

先调用获取用户信息的服务，返回了401，没有带身份认证信息。

http://localhost:8080/users/13

下面来调用一下login的方法，传入用户名和密码

这个方法返回了200.里面的Reponse Headers里面。Set-Cookies里面写的JSESSIONID

类似于下面这种：

Set-Cookie:

JSESSIONID=A0C5DF8537D2E42D9542774AB18EBCDF; Path=/; HttpOnly

在chrome的设置里面

这就是我们存起来的服务器返回的token

session有了信息了再去访问

我们可以看发出去的请求里面 Cookie里面有JSessionID，刚才浏览器里面存的JSessionID就从这里发出去了。

也就是这里的第四部，第五步

以上就是session的原理。你要明白的是，基于cookie、session的本质上仍然还是基于token的认证方式。只不过他的这种认证方式是servlet规范里面已经都实现好了的。有优点也有缺点，客户端只存一个串，真的信息是存在服务器端的，另外一个优点就是使用起来很方便，因为所有的东西servlet容器都替你实现好了，你啥都不用管了，代码里只需要getSession()然后往里面放东西就可以了。验证的时候只需要从里面拿，然后验证就可以了。使用起来非常的方便
缺点：只针对浏览器起作用，因为我返回的Repoonse Header，浏览器收到这个Repoonse Header然后自个去设置cookie这件事只有浏览器支持。如果你是一个客户或者app 甚至一个第三方的应用，你是走不了这个机制的。当服务器向浏览器传输cookie的时候，很容易被劫持。并不是绝对安全的。在大型的项目中，我们的servlet容器。服务器往往不是一台，如果一个用户的信息落在第一台服务，那么后面请求在访问的是第二台服务器。那么后面的就访问不到这个用户信息了。然后又要重新登陆。Spring 有一个Spring Session外部的存储来当你的Token Store来存session信息。以前没有Spring Session 要做这个事情还是挺麻烦的，要在好多个tomcat之间同步session信息，然后保持他们的一致性，

所以出现了另外一种自己实现来基于token 的登陆

基于cookie和sesison常见的风险。也就是一些攻击方式，以及怎么去防护这些攻击

巴特西

Spring cloud微服务安全实战-3-11API安全机制之登录

代码实现来验证请求的流程

结束

最新文章

热门文章