标签:数据库 业务逻辑 str 渲染 不同 cat tor 区别 前端框架
首先说一下jsp的工作原理:
jsp实际上也是是一个继承自Servlet接口的java类,实际上它就是一个Servlet,JSP的页面渲染是在后端完成的,经过tomcat的处理后,把jsp转为html后,再统一发送给前端(浏览器)显示出来
那现在手机移动端app这么普及,那我怎么写一份后端代码,即又可以显示在手机app上面,又可以在pc端跑呢?
手机app不是浏览器,他不可以显示 html 跟 jsp 哦 , 而且手机跟浏览器不一样,是不是需要把数据交给前端,让前端来渲染数据才可以解决问题
前后端通过json格式交互数据
主流前端框架MVVM
vm层(视图模型层)通过接口从后台m层(model层)请求数据,vm层继而和v(view层)实现数据的双向绑定。
token(令牌)
token与Session的区别
SESSION 是服务器通过 Key-Value 对来保存数据的一种机制,比如 APP 的登录状态可以用 SESSION 来保存。
TOKEN 翻译过来叫令牌,令牌是什么意思?可以拿现实中的令牌对比,现实中的令牌起到通行证的作用,而这在服务端也是一样的。我们在登录后,服务端使用 SESSION 保存我们的登录状态,并把 SESSION 的 Key 返回给客户端,那么这个 Key 就成为我们的令牌(TOKEN),我们以后再访问数据,就直接把这个 TOKEN 随着请求一起发送给服务端,这样服务端通过这个 TOKEN 在 SESSION 中查找数据,如果有就说明 TOKEN 有效(就像你去旅游,关口认可你的通行证),并取出你的登录数据,利用你的用户信息(保存在登录数据内)查出你想要的内容。
为什么使用token不用Session
Session的原理:
当用户第一次通过浏览器使用用户名和密码访问服务器时,服务器会验证用户数据,验证成功后在服务器端写入session数据,向客户端浏览器返回sessionid,浏览器将sessionid保存在cookie中,当用户再次访问服务器时,会携带sessionid,服务器会拿着sessionid从服务器获取session数据,然后进行用户信息查询,查询到,就会将查询到的用户信息返回,从而实现状态保持
? Session的弊端:
1、服务器压力增大
通常session是存储在内存中的,每个用户通过认证之后都会将session数据保存在服务器的内存中,而当用户量增大时,服务器的压力增大。
2、CSRF跨站伪造请求攻击
session是基于cookie进行用户识别的, cookie如果被截获,用户就会很容易受到跨站请求伪造的攻击。
3、扩展性不强
如果将来搭建了多个服务器,虽然每个服务器都执行的是同样的业务逻辑,但是session数据是保存在内存中的(不是共享的),用户第一次访问的是服务器1,当用户再次请求时可能访问的是另外一台服务器2,服务器2获取不到session信息,就判定用户没有登陆过。
token实现原理
Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证,服务端认证成功,那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。如果这个 Token 在服务端持久化(比如存入数据库),那它就是一个永久的身份令牌。
token 有很多种实现方式,这里以jwt为例子:
JWT : 是一种基于JSON,用于在网络上声明某种主张的令牌(token),jwt通常有三部分组成:头部信息(header) 消息体, 和签名
头部信息:指定了该JWT使用的签名算法
消息体:包含JWT中储存的信息
签名:通过密钥跟算法生成签名
token与Session的不同点:
token与session的不同主要在
1,认证成功后,会对当前用户数据进行加密,生成一个加密字符串token,返还给客户端(服务器端并不进行保存)
2,浏览器会将接收到的token值存储在Local Storage中,(通过js代码写入Local Storage,通过js获取,并不会像cookie一样自动携带)
3,再次访问时服务器端对token值的处理:服务器对浏览器传来的token值进行解密,解密完成后进行用户数据的查询,如果查询成功,则通过认证,实现状态保持,所以,即时有了多台服务器,服务器也只是做了token的解密和用户数据的查询,它不需要在服务端去保留用户的认证信息或者会话信息,这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了,这就为应用的扩展提供了便利,解决了session扩展性的弊端。
一,登录:
二,业务请求:
三,token过期,刷新token
标签:数据库 业务逻辑 str 渲染 不同 cat tor 区别 前端框架
原文地址:https://www.cnblogs.com/chenhanhao/p/12540511.html