序言：在过往合作开发中，不能牵涉到布吕马的难题，因为常常都是在同一工程项目中合作开发标识符或是纯粹写小demo；However，在前述工程项目中，其间端分为两个相同的工程项目，各别布署在相同的搜索引擎下，这也就会碰到布吕马难题了。
难道难题发生了，那要是关键在于去化解难题，在开始说化解方案前，他们有必要性介绍呵呵甚么是布吕马
1、甚么是布吕马
在应用程序相混思路管制下，向相相混（相同协定、相同搜索引擎或是相同路由器）推送XHR允诺，应用程序指出该允诺不受信赖，明令禁止允诺，其二为允诺后不恒定响
从表述中可以看见这都是应用程序做的“坏事”。所以甚么是不必源呢？只不过也很单纯，如果网页的协定、搜索引擎和路由器与允诺门牌号的没有全然那样，就指出你是相相混，举个极端范例而言：
http://www.baidu.com:80与
https://msg.baidu.com:80802、是不是化解布吕马
如果价值观不崩塌，配套措施总比十分困难多，难道已经介绍甚么是布吕马，那他们就著手来解决这个难题
1.从应用程序侧发力
只不过布吕马只在应用程序下才会促发，那是不是配套措施停止使用应用程序的相混思路呢？配套措施还吗有。
对IE应用程序：步入ie的网路快捷键增设，接着优先选择可靠性，再优先选择自定级别，接着沙莱县，找出「存
对chrome应用程序：通过在配置文件，输出chrome.exe –allow-file-access-from-files –user-data-dir=”C:/Chrome dev session” –disable-web-security，这会增建一个应用程序示例，手动关上的chrome会表明一连串红色的文本就表明获得成功了；
对FireFox应用程序：在地址栏输出about:config，接着沙莱县找出security.fileuri.strict_origin_policy，接着增设为false方可
2.从搜索引擎侧发力
难道搜索引擎等信息不一致导致布吕马产生，所以干脆就把两个工程项目合并成一个工程项目，使用相同的协定、搜索引擎和路由器。
3.从jsonp侧发力
只不过认真想想，他们的系统中经常会用到外链的图片、样式文件以及插件，那这些不能导致布吕马吗？是的，吗不能，因为这些是http允诺，并不是前面表述的xhr（XmlHttpRequest）允诺。
难道图片和js脚本可以恒定允诺，所以如果把script脚本的src改成我需要布吕马允诺的url是不是就可以了呢？
是可以的，当允诺接口返回的数据需要稍微处理下。在平常引入script脚本时，下载完文件后手动执行，如果他们把src改成布吕马url，而且返回值是一段jjs语句，比如：
req.send(“alert(1)”); //后台返回js语句
所以前台会会手动解析并执行（这里是弹出1）。所以，如果返回的js语句是一个调用函数的js语句，恰巧前台事先表述了该函数，如：
所以在fun函数将被调用（可以理解成后台调用前台标识符），如果对fun的参数进行处理，就可以实现复杂的业务逻辑了。
在前述情况下是是不是处理的呢？一般他们会先协商好需要被调用的方法及参数（fun）,接着动态创建一个script标签，并增设该标签的src为布吕马url，最后插入到文档中，插入后，应用程序会手动发起http的get允诺，下载完成后将会执行后台返回的js语句（后台调用前台）。
这就是jsonp。
4.从代理侧发力
还是回到最开始，难道应用程序指出非相混不安全，所以向相混允诺不就行了？他们把允诺转到同一工程项目下的后台，在同工程项目的后台进行xhr允诺，接着把允诺结果原样返回给前台，这就是代理（或是叫转发）。
获得成功的原因是相混思路只在应用程序下才起作用，我用后台来允诺其他的url，那是不受影响的。开启后台代理可以用C#、JAVA、NodeJs、甚至是python都行，如果能被前端访问的并且能转发允诺就可以。
5.从CORS侧发力
除了前面的几种方法外，还有一种单纯得多的方法，那就是后台的允诺响应头告诉应用程序“我的这个允诺很安全，允许当前搜索引擎布吕马访问”。如何去实现的呢，只不过这是利用了CORS（Cross-Origin Resource Sharing, 跨源资源共享），听起来牛逼哄哄的，只不过也就是一个W3C新标准，应用程序检测到响应头的一些字段的值后，跳过相混思路。
所以有那些响应头字段，以及它们分别是甚么表述呢？
res.header(“X-Powered-By”, ” 3.2.1″); //快速模式
res.header(“Content-Type”, “application/json;charset=utf-8”); //类型及字符编码3、如何实现布吕马下的登陆
用前面任意一种方案都可以化解布吕马，然而，布吕马带来的登陆难题却不好化解。在说如何化解登陆难题前，还是按照老规则说呵呵问甚么就登陆不了了。
在解析前需要先明确几点：
1：http是无状态的，不知道该允诺归属于谁
2：每次http允诺都会手动携带cookie（在允诺头中）
3：session存放在服务端，是有时间有效性的，一段时间内不访问将失效
在恒定情况下（非布吕马），他们前台发出p服务端的session信息，如：
req.session[“UserInfo”]
//登录时增设了key为UserInfo的session
乍一看就是这么一回事，当时仔细想想又会发现奇怪的地方：
①都说了ht
②session的key是UserInfo，如果有多个用户同时操作，拿到的值会不能是同一呢？
接下来他们先介绍呵呵session的增设与读取
说起session，就不得不说cookie，两者都是缓存，只不过前者保存在服务端，后者保存在客户端。在登录完成后，后台增设一个key为UserInfo的session对象（就叫对象S吧），这个对象S有三个重要的属性，分别是key、value以及sid。key和value的非常好理解，那sid是拿来干嘛？
只不过sid又叫session_id，是这个session对象的主键。
众所周知，http是无状态的，为了区分状态，在增设session的时候，服务端会手动在http允诺的响应头中把sid增设到cookie中（合作开发人员感知不到这步操作的，也就是手动增设cookie），应用程序响应允诺后，会把更新带有sid的cookie，并在下一个允诺时手动带上cookie（应用程序允诺手动携带cookie，也是静默操作，关于携带cookie的后面还会继续介绍）。
当第二次允诺来到后台，此时已经
这就是增设session和读取session的流程，
本文为CSDN博主「Msgyvcici」的原创文章，
