AngularJS 作为一款经典的前端 JAVAScript 框架，在构建单页面应用（SPA）时，经常需要与后端 API 进行数据交互，由于浏览器的同源策略（Same-Origin Policy），跨域请求成为开发者必须面对和解决的重要问题，本文将系统介绍 AngularJS 中跨域问题的成因、常见解决方案及其实现细节,帮助开发者高效处理跨域数据交互。
跨域问题的本质：同源策略的限制
同源策略是浏览器的一种安全机制，它规定仅当协议（protocol）、域名（domain）、端口（port）三者完全一致时，浏览器才允许页面中的脚本读取另一个窗口或资源的响应数据，前端应用运行在
，而后端 API 服务部署在
，由于域名和端口不同，浏览器会阻止前端直接获取后端返回的数据,从而触发跨域错误。
在 AngularJS 中，这一问题主要体现在服务发起的 get="_blank">ajax 请求上，当请求的目标 URL 与当前页面的源不同时，浏览器会在控制台报错，提示“No ‘Access-Control-Allow-Origin’ header is present on the requested resource”等信息。
AngularJS 跨域解决方案及实现
服务端 CORS 配置（推荐方案）
跨域资源共享（Cross-Origin Resource Sharing, CORS）是 W3C 标准化的跨域解决方案，通过在服务端添加特定的 HTTP 头部，允许浏览器跨域访问资源,这是目前最常用且兼容性最好的方法。
实现步骤： 服务端需在响应头中添加以下字段：
示例（Node.js + Express）：
const express = require('express');const app = express();app.use((req, res, next) => {res.header('Access-Control-Allow-Origin', 'http://localhost:8080');res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');res.header('Access-Control-Allow-Credentials', 'true');next();});app.get('/api/data', (req, res) => {res.json({ message: '跨域请求成功' });});app.listen(3000, () => console.log('Server running on port 3000'));
注意事项：
JSONP（仅支持 GET 请求）
JSONP（JSON with Padding）是一种早期的跨域解决方案，通过动态创建标签，利用标签的跨域能力获取数据，其核心原理是服务端返回一段可执行的 JavaScript 代码,前端通过回调函数处理返回的数据。
AngularJS 中的 JSONP 实现： AngularJS 的服务内置了对 JSONP 的支持，只需在请求 URL 中添加参数，并使用回调方式。
示例代码：
angular.module('myApp', []).controller('MainController', Function($scope, $http) {$http.jsonp('http://api.example.com/data?callback=JSON_CALLBACK').success(function(data) {$scope.data =>代理服务器方案当前端无法直接修改服务端配置时，可通过代理服务器转发请求，将跨域请求转化为同源请求，AngularJS 项目中，可通过 （本地开发代理）、（反向代理）或 Webpack 代理实现。
示例（Nginx 反向代理）：配置 nginx.conf，将前端的 API 请求代理到后端服务：
server {listen 8080;server_name localhost;location /api/ {proxy_passHost $host;proxy_set_header X-Real-IP $remote_addr;}}此时前端请求 ，实际会被 Nginx 转发到 避免了跨域问题。
示例（Webpack 代理）：在 angular-cli.json 或 webpack.config.js 中配置代理：
proxy: {'/api': {target: 'http://api.example.com:3000',secure: false,changeOrigin: true}}AngularJS 跨域请求配置细节
在使用 服务时，可通过配置对象调整请求参数，以适应不同的跨域场景：
| 配置项 | 说明 | 示例 |
|---|---|---|
withCredentials | 是否携带 cookies（需服务端支持 Access-Control-Allow-Credentials） | $http.get('/api/data', { withCredentials: true }) |
自定义请求头（需服务端允许 Access-Control-Allow-Headers） | $http.post('/api/data',>跨域问题的常见问题与排查 |
fiddler4 怎么使用跨域问题
在调试ajax请求时，经常遇到的是跨域的问题，而解决跨域问题其中之一的办法就是服务器端添加Access-Control-Allow-Origin : *这样的头在服务器没作出修改之前，我们要模拟这个情况就得用到fiddler了两种方式，各有长短，先上图再说方法1：修改 通过修改给Fiddler添加菜单项，效果永久有效，操作方便，也可随时自定，实现如下a. 在的 public static RulesOption(Cache Always &Fresh, Per&formance)下面加上以下代码:Js代码//这里是新加的菜单项 RulesString(Override &Allow-Origin, true) //一级菜单名称RulesStringValue(1,*, *)//指定几个默认的的选项RulesStringValue(2,*,*)RulesStringValue(3,*,*) //自己可以随时补充RulesStringValue(4,&Custom..., %CUSTOM%)//允许用户自已定义,点击时弹出输入//如果加第4个参数为true的话,会把当前规则当作默认规则,每次启动都会生效,如://RulesStringValue(5,菜单项显示内容,菜单项选中对应值,true)//将会默认选中此项public static var sAllowOrigin: String = null;//定义变量名称b.在时找到static function OnBeforeResponse,在函数体内再加上如下代码: 注意：如果需要跨域读写cookie，要同时设置Access-Control-Allow-Credentials：ture
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中，依据是删掉表中记录也无影响）。
java跨域怎么解决
这个问题的回答很多的吧。 。 一个是用jsonp的方式另一种就是在java代码里接口那里加上(Access-Control-Allow-Origin, *);(Access-Control-Allow-Methods, GET, POST, PUT, DELETE, OPTIONS);(Access-Control-Allow-Headers, x-requested-with);
发表评论