asp.net session 如何知道是哪个浏览器客户端_前后端分离项目session,cookie,token比较...-CSDN博客

点击上方“ IT Factory ”，星标公众号技术前沿，第一时间送达

涉及知识点

1.HTTP无状态：

HTTP是无状态的，一次请求结束，连接断开，下次服务器再收到请求，它就不知道这个请求是哪个用户发过来的。当然它知道是哪个客户端地址发过来的，但是对于我们的应用来说，我们是靠用户来管理，而不是靠客户端。 2.session,cookie： session跟踪是web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是cookie和session。cookie通过在客户端记录信息确定用户身份，session通过在服务器端记录确定用户身份。

3.前后端分离：

前后端分离的"前"特指浏览器端(或客户端)。Java服务器端初学者最容易引起误解的一个概念就是: JSP是前端技术。“后”特指java后端层通常可认为是spring boot服务器。

4.何为token:

在计算机身份认证中是令牌(临时)的意思，在词法分析中是标记的意思。一般作为邀请、登录系统使用。

5.同域以及跨域:

跨域，指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器施加的安全限制。所谓同源是指，域名，协议，端口均相同，不明白没关系，举个栗子：

http://www.123.com/index.html 调用 http://www.123.com/server.php (非跨域)

http://www.123.com/index.html 调用 http://www.456.com/server.php (主域名不同:123/456，跨域)

http://www.123.com:8081/server.php (端口不同:8080/8081，跨域)

请注意：localhost和127.0.0.1虽然都指向本机，但也属于跨域。

浏览器执行javascript脚本时，会检查这个脚本属于哪个页面，如果不是同源页面，就不会被执行

6.same-origin policy(同源策略)

一个浏览器中访问的网站不能访问另一个网站的数据，除非两个网站具有相同的origin(根源),也即是拥有相同的“协议”，“域名”，端口“。一旦这三项数据中有一项不同，那么该资源就将被认为是从不同的origin 得来，进而不被允许访问。

前后端不分离

在前后端不分离的应用模式中，前端页面看到的效果都是由后端控制，由后端渲染页面或重定向，也就是后端需要控制前端的展示，前端与后端的耦合度很高。

这种应用模式比较适合纯网页应用，但是当后端对接App时，App可能并不需要后端返回一个HTML网页，而仅仅是数据本身，所以后端原本返回网页的接口不再适用于前端App应用，为了对接App后端还需再开发一套接口。

前后端分离

在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果。至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App有App的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。

在前后端分离的应用模式中，前端与后端的耦合度相对较低。

在前后端分离的应用模式中，我们通常将后端开发的每个视图都称为一个接口，或者API，前端通过访问接口来对数据进行增删改查。

分离后遇到的问题

1.跨域

这里有有张摘自网络的图片

简述跨域问题

如何解决跨域

解决思路

1.JSONP 2.nginx代理 3.浏览器禁止检查跨域 4.Cors协议

一、nginx反向代理解决跨域(客户端解决跨域)

反向代理的原理就是讲前端的地址和后端的地址用nginx转发到同一个地址下，如5500端口和3000端口都转到3003端口下，具体配置如下：

打开nginx目录下的conf目录里面nginx.conf
为了方便以后测试，我们将配置分离开来，弄成多个文件
在nginx.conf的http对象的最后加上include ../vhost/test.conf;(注意要最后加上分号)
这样就可以在test.conf下单独配置了

二、JSONP解决跨域

JSONP(JSON with Padding)是JSON的一种“使用模式”，可用于解决主流浏览器的跨域数据访问的问题。由于同源策略，一般来说位于 server1.example.com 的网页无法与不是 server1.example.com的服务器沟通，而 HTML 的

2. 在客户端写callbackFunction函数的实现

function CustomerLoaded(result,methodName){    var html='

'; for(var i=0;i { html+=''+result[i]+''; } html+=''; document.getElementById('divCustomers').innerHTML=html;}

三、浏览器禁止检查跨域

思路：通过命令行修改浏览器启动参数，使得浏览器不进行跨域检查，从而允许跨域

方法：命令行参数启动浏览器后添加参数--disable-web-security

例：chrome --disable-web-security

--disabl-web-security参数的作用是禁止浏览器进行跨域检查

但是，这种方法有三个缺点：

1.每次启动浏览器都需要通过命令行启动，太过繁琐

2.该方法会导致安全性方面的问题

3.该方法是客户端方面的改动，在实际使用中，在每个客户端上都禁止浏览器进行跨域检查不太现实，所以实用性较低。

总的来说，该方法虽然可以解决跨域问题，但是价值不大。在实际项目中，主要对服务器端进行改动使得支持跨域。

四、Cors协议

再谈同源策略：

同源策略(Same origin policy)是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说Web是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。　　　

H5中的新特性：Cross-Origin Resource Sharing(跨域资源共享)。通过它，我们的开发者(主要指后端开发者)可以决定资源是否能被跨域访问。

cors是一个w3c标准，它允许浏览器(目前ie8以下还不能被支持)像我们不同源的服务器发出xmlHttpRequest请求，我们可以继续使用ajax进行请求访问。

在springboot中如何通过cors协议解决跨域问题

springmvc4.2版本增加了对cors的支持。

目前我所做的项目基本都是springboot进行开发

@Configurationpublic class MyWebAppConfigurer extends WebMvcConfigurerAdapter{    @Override    public void addCorsMappings(CorsRegistry registry) {        registry.addMapping("/**");    }}

当然也可以修改其它属性

@Configurationpublic class MyWebAppConfigurer extends WebMvcConfigurerAdapter{    @Override    public void addCorsMappings(CorsRegistry registry) {           registry.addMapping("/api/**")           .allowedOrigins("http://192.168.1.97")           .allowedMethods("GET", "POST")           .allowCredentials(false).maxAge(3600);

以上两种，都是针对全局配置，如果你想做到更细致也可以使用@CrossOrigin这个注解在controller类中使用。

@CrossOrigin(origins = "http://192.168.1.97:8080", maxAge = 3600)@RequestMapping("rest_index")@RestControllerpublic class IndexController{

2.传统的session，cookie以及token的引入

目前大多数Web应用采用前后端分离方式进行开发。所以前端网站或应用都属于SPA(Single Page Application)。如果前端，后台API部署在同域下，不存在跨域的情况，登录方式相对简单。

1.服务端session是用户第一次访问应用时，服务器就会创建的对象，代表用户的一次会话过程，可以用来存放数据。服务器为每一个session都分配一个唯一的sessionid，以保证每个用户都有一个不同的session对象。 2.服务器在创建完session后，会把sessionid通过cookie返回给用户所在的浏览器，这样当用户第二次及以后向服务器发送请求的时候，就会通过cookie把sessionid传回给服务器，以便服务器能够根据sessionid找到与该用户对应的session对象。 3.session通常有失效时间的设定，比如2个小时。当失效时间到，服务器会销毁之前的session，并创建新的session返回给用户。但是只要用户在失效时间内，有发送新的请求给服务器，通常服务器都会把他对应的session的失效时间根据当前的请求时间再延长2个小时。 4.session在一开始并不具备会话管理的作用。它只有在用户登录认证成功之后，并且往sesssion对象里面放入了用户登录成功的凭证，才能用来管理会话。管理会话的逻辑也很简单，只要拿到用户的session对象，看它里面有没有登录成功的凭证，就能判断这个用户是否已经登录。当用户主动退出的时候，会把它的session对象里的登录凭证清掉。所以在用户登录前或退出后或者session对象失效时，肯定都是拿不到需要的登录凭证的。

5.cookie的缺点：大小收到限制，用户可禁用客户端接收cookie的功能，简单性，基于文本的key-value对

基于Token登录

1.用户在浏览器中输入用户和密码，后台服务器通过加密或者其他逻辑，生成一个Token。
2.前端获取到Token，存储到cookie或者localStorage中，在接下来的请求中，将token通过url参数或者HTTP Header头部传入到服务器
3.服务器获取token值，通过查找数据库判断当前token是否有效
基于Token登录，而且可以用于第三方单点登录的OAuth2.0更适合。可以参考本人公众号:OAuth 2.0 是个啥？