1.什么是跨域？要了解什么是跨域，我们先说一下同源的概念。同源，是指协议、域名、端口都相同。
例如：与不是同源，因为协议不同，个冒号前面的为协议，中间的为域名，第二个冒号后面的为端口，只要满足有一处不同，则就不是同源。
所谓跨域就是从 A 向 B 发请求，如若他们的地址协议、域名、端口都不相同，直接访问就会造成跨域问题，跨域是非常常见的现象！请求是跨域的但并不一定会报错，普通的图片请求。css文件请求是不会报错的。报错的条件是浏览器的同源策略，且发送Ajax请求，跨域是客户端问题。
2.为什么要跨域？为了安全起见，浏览器设置了同源策略，当页面执行脚本的时候，浏览器会检查访问的资源是否同源，如果不是，就会报错。
3.如何解决跨域？（1）JSONP利用的是 script 标签 src 属性请求 js 无跨域问题，但具有局限性，只能发送 get 请求
（2）CORS当请求违反了同源策略，就在请求头添加 Access-Control-Allow-Origin 属性，浏览器会判断响应中 Access-Control-Allow-Origin 值是否和当前的地址相同，匹配成功后才会做响应处理，否则继续报错。缺点是会忽略cookie，而且对浏览器版本有一定的要求
（3）nginx反向代理接口跨域可以将前端项目部署到和接口同源的当前本地的 服务器 上。在vue.config.js 中进行代理配置，假设当我访问时会转换为间接访问
devServer: {// 其他代码省略。。。。。// 代理配置proxy: {// 代理服务器，当请求的网址是的时候，会转成/api 是 看接口文档所写的，每当访问本地的/api接口时，会转化为访问真实的服务器'/api': {target: 'http://localhost:3000' // 我们要代理的真实接口地址}}（4）web sockets它是一种浏览器的API，它的目标是在一个单独的持久连接上提供全双工、双向通信。(同源策略对web sockets不适用)web sockets原理：在JS创建了web socket之后，会有一个HTTP请求发送到浏览器以发起连接。取得服务器响应后，建立的连接会使用HTTP升级从HTTP协议交换为web sockt协议。 只有在支持web socket协议的服务器上才能正常工作。
c# 对象二进制序列化
本质上说，这并不是二进制序列化的问题，甚至不关序列化的问题。 你想要的是在两个内部结构一致但在不同命名空间（甚至不同项目）的同名类间做类型转换。 这个问题很常见，因为实际工作中经常会有此类需求，但是我们又不可能手动的把每个字段的值都抄来抄去。 解决此问题的方法很多，但都逃不开一个关键思想：A不知道B的存在，B不知道A的存在，那么我就找出一个C，只要A和B都能以C的形式表示，那么转换就不是问题。 这里的C是概念上的一个标准，用于当做A和B转换的桥梁。 普遍的解决方法：1. 如一楼所说，XmlSerializer序列化器能够将一个可Xml序列化的类A的“内容”部分抽取出来序列化成Xml片段，也能够将其反序列化为一个符合该Xml“格式”的类B。 代码如下。 序列化端=(typeof(classA));=(@c:\,);(stream,newclassA{i=10,s=hello});();反序列化端=(typeof(classA));classAb=(classA)((@c:\,,));打开c:\，我们可以看到中间传输的内容是10 hello 这表明了传输的内容只关注类名和共有属性/字段。 所以在反序列化端，只要我们有同样结构的同名类classA，是可以直接从Xml流进行转换的。 当然使用内存流、字节流等都是可以的。 这里一定要切记三点：同名同结构（指共有字段/属性部分）的两个类，以及只能序列化公有字段和属性，两个类都必须有默认构造方法。 Xml序列化的优点在于只序列化必要部分且消耗较少，常用于序列化DataTable等结构。 2.第二种方法是使用接口。 也许你的两个类分处不同的命名空间或者不同项目，但是只要都能访问到同一interface，那么我们可以稍微费点功夫写一个两个都“认识”的接口，通过接口来转换对象。 public interface dataInterface { int i{get;set;} string s{get;set;} } [Serializable] public class classA : dataInterface { public int i{get;set;} public string s{get;set;} } [Serializable] public class classB : dataInterface { public int i{get;set} public string s{get;set;} }如此，不管classA和classB在哪里，只要你认得dataInterface，那么就可以用其来传输、访问和转换。 传输的过程相比xml序列化就灵活多了，你可以使用socket、文件、消息、甚至共享内存等等手段来传输，序列化也可以使用万能的二进制序列化，因为你传出和接受的，都是dataInterface对象而已。 序列化端(二进制序列化+文件传输举例）： formatter = new (); fs = new (@c:\tmp, , ); (fs, (new classA { i = 10, s = hello })); ();反序列化： dataInterface data = (dataInterface)(new (@c:\tmp, , ));此方法优缺点显而易见。 优点是无视两个类的位置、无需同名同结构，缺点是有额外工作（写接口）外加反序列化后只能得到接口不能得到classB。 额外注意，上例中使用的二进制序列化需要在类上标记[Serializable]。 除此之外还有很多种方法可以做跨域类型转换，但并不常用，这里就不再敖述了。
跨域 问题 JS
在里JS和通信是无缝的其中很好的一个方法应该是实现
class 你的类 : , ICallbackEventHandler
public String callbackResult = ;
#region ICallbackEventHandler 成员public string GetCallbackResult(){return callbackResult;}public void RaiseCallbackEvent(string eventArgument){//你在调用SERVICE的代码;}#endregion
JS脚本
function 你的函数(){var tmpStr=(idd);<%=(this, tmpStr, 要在客户端处理的函数名称, null)%>;}
function 要在客户端处理的函数名称(str)
//str为callbackResult;其实这个函数可以接收两个函数.可以查下相关资料
//可在此进行相关处理
这个过程而且不会刷新.
ASP.NET 跨域共享Session的解决思路
1.首先简要说说 的session机制，当客户端向服务端发生会话时（不是访问了网站某页面就一定产生了会话），服务端会写一个cookie到客户端，这个cookie保存着sessionid ，名字为“_SessionID” ,在下一次发生向服务端的请求时这个cookie会包含在请求头中，这个cookie仅仅包含了sessionid ，其他信息以（某种形式）保存在服务端并被sessionid标识。2.因为我们要实现两个域的session共享，我们采用的方式是session的值保存在SqlServer数据库中(至于为什么要保存在SqlServer数据库中，这里不做探讨)，如何用数据库保存session的资料可以很轻易的在博客园中找到，子秋的博客中有记表ASPStateTempApplications有两个字段 ，一个appid ，一个appname ，一个应用程序相当于一个网站，这个表中的数据会在网站第一次被访问并产生session时添加，一个网站会产生一条记录，ASPStateTempSessions 表才是真正保存会话信息的表，有个二进制数据类型的字段用来保存session数据，还有创建时间过期时间的字段，当然少不了主键标识字段，也就是sessionid， 注意了！这个sessionid 的保存会在真正的sessionid上加个后缀 ，后缀是相应的ASPStateTempSessions表中应用程序id的十六进制表示形式，这样的话，如果两个应用程序不小心产生了同样的sessionid 也不会出现问题，因为还有后缀标识。4.问题出来了，如果让两个域（既是两个应用程序，两个网站）产生同样的sessionid 并且让应用程序名一样，不就可以共享session了吗？这样一来又有问题了？a.会话sessionid是保存在名字为“_SessionId”的cookie中的，我们知道cookie是不能跨域的，但是我们有方法让他能够夸二级多级域名，注意：主域名还是不能跨的方法就是该cookie的主机名，具体代码如：HttpCookieco=[_SessionId];=;(co);这一步只让sessionid 一样了呀，还差一步，就是让应用程序名一样b.如何让应用程序名一样呢 ，我们分析ASPStateTempApplications这张表中的记录是如何的来的，上面也有简单提到，具体分析后，发现记录是通过存储过程TempGetAppID插入的，我们将其改为：代码setANSI_NULLSONsetQUOTED_IDENTIFIERONgoALTERPROCEDURE[dbo].[TempGetAppID]@appNametAppName,@appIdintOUTPUTASSET@appName=fejerry--LOWER(@appName)SET@appId=NULLselect@appId=AppIdFROM[ASPState]=@appNameIF@appIdISNULLBEGINBEGINTRANSELECT@appId=AppIdFROM[ASPState](TABLOCKX)WHEREAppName=@appNameIF@appIdISNULLBEGINEXECGetHashCode@appName,@appIdOUTPUTINSERT[ASPState](@appId,@appName)IF@@error=2627BEGINDECLARE@dupApptAppNameSELECT@dupApp=RTRIM(AppName)FROM[ASPState]=@appIdRAISERROR(SQLsessionstatefatalerror:hash-codecollisionbetweenapplications%sand%1stapplicationtoresolvetheproblem.,18,1,@appName,@dupApp)ENDENDCOMMITENDRETURN0给一个固定的应用程序名，不管什么网站，只要以当前SqlServer作为session存储机制，都会记录为同一个应用程序，换句话说，就是表ASPStateTempApplications将只会有一条记录。5。 我这人喜欢钻牛角尖，这条记录是什么时候插入到数据库的呢？于是我手动删除了这条记录，但是即使删除了，仍然不影响应用程序的使用，不影响session的共享，于是我又把应用程序（网站）重启了， 对网站产生第一个会话后，我又去观察表ASPStateTempApplications，奇怪了，仍然一条记录都没有。
于是很自然的我把iis给重启了， 再对网站产生第一个会话后，又去观察表ASPStateTempApplications，出现了，出现了，终于出现了一条新的记录。 总结：表ASPStateTempApplications中的记录是在应用程序产生第一个会话时执行存储过程TempGetAppID产生的，（并且大胆猜测这条记录的信息也保存在iis中，依据是删掉表中记录也无影响）。
发表评论