网站策划书的基本内容网页设计登录页面怎么做

网站策划书的基本内容,网页设计登录页面怎么做,门户网站平台建设方案,企业做增资 网站平台目录引言一、令牌技术#xff08;Token#xff09;#xff1a;无状态认证的核心方案传统思路下存在的问题什么是令牌技术JWT#xff08;JSON Web Token#xff09;JWT组成JWT令牌⽣成和校验运用实战引言 在 Java Spring 后端开发中#xff0c;“安全” 永远是绕不开的话…目录引言一、令牌技术Token无状态认证的核心方案传统思路下存在的问题什么是令牌技术JWTJSON Web TokenJWT组成JWT令牌⽣成和校验运用实战引言在 Java Spring 后端开发中“安全”永远是绕不开的话题用户登录如何免 Session 认证用户密码如何防止泄露我们通过上篇令牌技术下篇加盐/加密这两个核心技术,来聊聊关于如何让后端的认证体系更安全、更可靠一、令牌技术Token无状态认证的核心方案传统思路下存在的问题在传统的思路下实现登录接口无非就这几个步骤登陆⻚⾯把⽤⼾名密码提交给服务器服务器端验证⽤⼾名密码是否正确,并返回校验结果给后端如果密码正确,则在服务器端创建Session.通过Cookie把sessionId返回给浏览器存在问题但是你可以仔细一想在开发的项⽬中,在企业中很少会部署在⼀台机器上,容易发⽣单点故障.(单点故障:⼀旦这台服务器挂了,整个应⽤都没法访问了).所以通常情况下,⼀个Web应⽤会部署在多个服务器上,通过Nginx等进⾏负载均衡.此时,来⾃⼀个⽤⼾的请求就会被分发到不同的服务器上假如我们使⽤Session进⾏会话跟踪,我们来思考如下场景首次请求客户端发起请求经过负载均衡分配到其中一台服务器这台服务器创建Session并存储同时生成SessionId通过响应把SessionId 存到客户端 Cookie 里。后续请求客户端再次请求时会携带Cookie包含 SessionId但负载均衡可能把请求分配到另一台服务器这台服务器本地没有之前存储的Session所以通过SessionId 查不到对应的会话信息导致 “会话失效”。也就是说Session 存在单台服务器本地多服务器之间没有共享 Session 数据赵成跨服务器请求会丢失会话状态。什么是负载均衡其实负载均衡可以理解为分布式系统里的 “流量调度员”它处于客户端和多台服务器之间核心作用是把客户端发来的请求合理分配到不同的服务器上既避免单台服务器被大量请求 “压垮”也能在某台服务器故障时把请求转移到其他正常机器以此提升系统的并发处理能力和稳定性。什么是令牌技术令牌Token的本质是服务端颁发给客户端的 “临时身份凭证”本质是一段经过加密的字符串包含用户身份、权限、过期时间等核心信息服务器具备⽣成令牌和验证令牌的能⼒你可以把它理解为用户登录成功后服务端给的一张 “电子通行证”—— 后续客户端访问需要权限的接口时只需出示这张 “通行证”服务端验证通过就允许访问无需再重复验证用户名密码我们使⽤令牌技术,继续思考上述场景:⽤⼾登录 ⽤⼾登录请求,经过负载均衡,把请求转给了第⼀台服务器,第⼀台服务器进⾏账号密码验证,验证成功后,⽣成⼀个令牌,并返回给客⼾端客⼾端收到令牌之后,把令牌存储起来.可以存储在Cookie中,也可以存储在其他的存储空间(⽐如localStorage)查询操作 ⽤⼾登录成功之后,携带令牌继续执⾏查询操作,⽐如查询博客列表.此时请求转发到了第⼆台机器,第⼆台机器会先进⾏权限验证操作.服务器验证令牌是否有效,如果有效,就说明⽤⼾已经执⾏了登录操作,如果令牌是⽆效的,就说明⽤⼾之前未执⾏登录操作.优点显而易见无状态服务端无需存储支持分布式部署轻量级⽆需在服务器端存储传输成本低适配各种客户端缺点的话可能是需要自己实现(包括令牌的⽣成,令牌的传递,令牌的校验)JWTJSON Web TokenJWT是最常用的轻量级令牌​是目前最流行的令牌标准核心是 “自包含信息 数字签名”无需服务端存储状态本质就是⼀个字符串这篇文章主要使用JWT令牌来实现JWT组成JWT由三部分组成,每部分中间使⽤点(.)分隔⽐如aaaaa.bbbbb.cccc部分名称作用格式示例Base64 解码后第一部分Header(头部)声明令牌类型和签名算法{“alg”:“HS256”,“typ”:“JWT”}第二部分Payload(负载)存储核心业务信息用户 ID、角色等{“userId”:1,“role”:“ADMIN”,“exp”:1616270640}第三部分Signature(签名)验证令牌完整性和真实性HMAC256 算法加密结果无法直接解码Payload(负载)部分不建议存放敏感信息,因为此部分可以解码还原原始内容JWT官网描述JWT令牌⽣成和校验需要引⼊JWT令牌的依赖!-- https://mvnrepository.com/artifact/io.jsonwebtoken/jjwt-api --dependencygroupIdio.jsonwebtoken/groupIdartifactIdjjwt-api/artifactIdversion0.11.5/version/dependency!-- https://mvnrepository.com/artifact/io.jsonwebtoken/jjwt-impl --dependencygroupIdio.jsonwebtoken/groupIdartifactIdjjwt-impl/artifactIdversion0.11.5/versionscoperuntime/scope/dependencydependencygroupIdio.jsonwebtoken/groupIdartifactIdjjwt-jackson/artifactId!-- or jjwt-gson if Gson is preferred --version0.11.5/versionscoperuntime/scope/dependency使⽤Jar包中提供的API来完成JWT令牌的⽣成和校验先通过Test测试方法生成密钥TestvoidgenKey(){//生成密钥KeykeyKeys.secretKeyFor(SignatureAlgorithm.HS256);StringsecretStringEncoders.BASE64.encode(key.getEncoded());System.out.println(secretString);//uKdkjBTVIskTsz91VImoh6CLHZKOcWDce1kEuCNaE}⽣成令牌privatestaticfinalStringsecretStringuKdkjBTVIskTsz91VImoh6CLHZKOcWDce1kEuCNaE;//⽣成安全密钥privatestaticfinalSecretKeyKEYKeys.hmacShaKeyFor(Decoders.BASE64.decode(secretString));//⾃定义信息MapString,ObjectclaimsnewHashMap();claims.put(id,12);claims.put(username,admin);//生成 tokenStringcompactJwts.builder().setClaims(claims)//⾃定义内容(负载).signWith(key)//签名算法.compact();System.out.println(compact);//eyJhbGciOiJIUzI1NiJ9.eyJpZCI6MTIsInVzZXJuYW1lIjoiYWRtaW4ifQ.TlsChs_dzYex6pYnym8x2M7zAtcxjl2EBolAbYNvMdM//解析JwtParserbuildJwts.parserBuilder().setSigningKey(key).build();System.out.println(build.parse(compact).getBody());//{id12, usernameadmin}运行结果上述第一行输出的内容,就是JWT令牌可以直接进行解析如上图第二行所示也可以通过点(.)对三个部分进⾏分割,我们把⽣成的令牌通过官⽹进⾏解析注意对于密钥有⻓度和内容有要求如何长度不符合要求就会发生一下错误你使用的密钥字节数组仅为32 位不符合 JWT HMAC-SHA 算法的安全要求根据 JWA 规范RFC 7518HMAC-SHA 算法的密钥长度必须≥256 位密钥长度需不小于哈希输出长度。运用实战登陆⻚⾯把⽤⼾名密码提交给服务器.服务器端验证⽤⼾名密码是否正确,如果正确,服务器⽣成令牌,下发给客⼾端.客⼾端把令牌存储起来(⽐如Cookie,localstorage等),后续请求时,把token发给服务器服务器对令牌进⾏校验, 如果令牌正确,进⾏下⼀步操作生成请求和响应实体类DataAllArgsConstructorpublicclassUserLoginResponse{privateIntegeruserId;privateStringtoken;}DatapublicclassUserLoginRequest{NotNull(message用户名不能为空)privateStringuserName;NotNull(message密码不能为空)privateStringpassword;}生成验证和生成JWT工具类Slf4jpublicclassJwtUtils{//使用固定密钥privatestaticStringSECRET_StRINGrPsPc6787n3N5LjmAgaF85ga6I1qrHdQaasH8tKwTs;publicstaticKeykeyKeys.hmacShaKeyFor(Decoders.BASE64.decode(SECRET_StRING));publicstaticStringgenToken(MapString,Objectclaims){//生成 tokenStringcompactJwts.builder().setClaims(claims).signWith(key).compact();returncompact;}publicstaticClaimsparseToken(Stringtoken){if(!StringUtils.hasLength(token)){returnnull;}//解析JwtParserbuildJwts.parserBuilder().setSigningKey(key).build();Claimsclaimsnull;try{claimsbuild.parseClaimsJws(token).getBody();}catch(Exceptione){log.error(解析token异常,token);}returnclaims;}验证账号密码和生成tokenpublicUserLoginResponsecheckPassword(UserLoginRequestuserLoginRequest){QueryWrapperUserInfoqueryWrappernewQueryWrapper();queryWrapper.lambda().eq(UserInfo::getUserName,userLoginRequest.getUserName()).eq(UserInfo::getDeleteFlag,0);UserInfouserInfouserInfoMapper.selectOne(queryWrapper);if(userInfonull){//用户不存在thrownewBlogException(用户不存在);}if(!SecurityUtil.verify(userLoginRequest.getPassword(),userInfo.getPassword())){thrownewBlogException(用户密码错误);}//密码正确MapString,ObjectmapnewHashMap();map.put(id,userInfo.getId());map.put(name,userInfo.getUserName());StringtokenJwtUtils.genToken(map);returnnewUserLoginResponse(userInfo.getId(),token);}在统一拦截中验证tokenSlf4jComponentpublicclassLoginInterceptorimplementsHandlerInterceptor{//约定前端把token放在header里OverridepublicbooleanpreHandle(HttpServletRequestrequest,HttpServletResponseresponse,Objecthandler)throwsException{StringuserTokenrequest.getHeader(Constants.USER_TOKEN_HEADER_KEY);log.info(从header中获得用户token:{},userToken);if(userTokennull){//拦截response.setStatus(401);returnfalse;}//校验token是否合法ClaimsclaimsJwtUtils.parseToken(userToken);if(claimsnull){//拦截response.setStatus(401);returnfalse;}returntrue;}}前端代码不赘述主要是通过localStorage.setItem将token存在浏览器中当再次进入页面后端就会将我们的携带登录中生成的唯一的token进行验证如果当我们在客户端中错误的token或者无token就会导致验证不通过无法进入此页面从而实现强制要求登陆