url中增加端口号之后提示Origin is not allowed by Access-Control-Allow-Origin. Angular JS

本来，几个演示系统发布在一台服务器上，运行很正常。可是最近合作伙伴说租用的服务器不想续费了，将那几个项目搬到他们公司内部的服务器上。好吧，搬就搬，本身也费不了多少事，无法就是重新发布、重新设置而已。

OK，搬完了，用新地址访问一下试试，结果，问题来了，情况远比我想象的要复杂。

首先，用原来的url不能访问系统了，会跳转到一个什么身份认证系统，合作伙伴说是防火墙的原因，要加端口号，好吧，然后在url中加了端口号8071，这下首页是能加载了，登录也能登录了，但是发现有几个模块不能打开，然后一看浏览器控制台，发现报错：

1. OPTIONShttp://58.215.219.74/fsjd_service/api/users Origin http://58.215.219.74:8071 is not allowed by Access-Control-Allow-Origin. 
2. XMLHttpRequest cannot load http://58.215.219.74/fsjd_service/api/users. Origin http://58.215.219.74:8071 is not allowed by Access-Control-Allow-Origin.

是跨域访问的问题了，先看看首页是哪个地址：

并且，其实在js文件中配置的url也是带有端口号的：

baseResourceURL: "http://58.215.219.74:8071/fsjd_service"

但是很显然，在访问个别内容（比如用户管理）的时候，这个配置好的url中的端口号8071没了：

http://58.215.219.74/fsjd_service/api/users

问题找到了，接下来就是该弄清楚这个端口号是什么时候被弄没了。

说明一下，Web前端用到了Angular JS，后面的内容和这个插件密切相关。

先来看看这个关于users的请求在javascript中是是怎么写的：

fs.services.factory('User', ['$resource', '$http', function ($resource, $http) {console.log("user的url: "+fs.common.baseResourceURL);    return $resource(fs.common.baseResourceURL + '/api/users/:id', {id: '@id'});}]);fs.services.factory('MultiUserLoader', ['User', '$q', function (User, $q) {    return function () {        var delay = $q.defer();console.log("开始茶人。。。");        User.query(function (users) {            delay.resolve(users);        }, function () {            delay.reject('Unable to fetch users');        });        return delay.promise;    }}]);

首先看这一句：

 return $resource(fs.common.baseResourceURL + '/api/users/:id', {id: '@id'});

定义了名为User的一个资源，注意看其中的url部分，是有一个":id"作为参数的，不管是请求一个user还是全部user。

然后下面的MultiUserLoader中用User.query()方法发送请求。好吧，那么就来看看这个query方法里面到底发生了什么，在angular.js中找了几遍都没有找到query方法，忽然想到“资源”这个概念，应该和resource相关，于是打开angular-resource.js看看，果然找到了：

angular.module('ngResource', ['ng']).  factory('$resource', ['$http', '$parse', function($http, $parse) {    var DEFAULT_ACTIONS = {      'get':    {method:'GET'},      'save':   {method:'POST'},      'query':  {method:'GET', isArray:true},      'remove': {method:'DELETE'},      'delete': {method:'DELETE'}    };

既然找到了query方法是在这里的，那就再找找关于url被改动的线索吧，最终，经过各种测试，发现url端口号被拿走的原因了：

          if (angular.isDefined(val) && val !== null) {  console.log("if calse...");            encodedVal = encodeUriSegment(val);            url = url.replace(new RegExp(":" + urlParam + "(\\W|$)", "g"), encodedVal + "$1");          } else {  console.log("else case...");            url = url.replace(new RegExp("(\/?):" + urlParam + "(\\W|$)", "g"), function(match,                leadingSlashes, tail) {              if (tail.charAt(0) == '/') {                return tail;              } else {                return leadingSlashes + tail;              }            });          }  console.log("New Url2: "+url);

这块代码是在Route.prototype中的，if和else分支中都用replace替换函数对url进行了处理，实测是进了else分支的，从else分支中的正则表达式来看，其中出现了冒号，看来是要做的事情就是替换掉冒号和它后面的内容。这时再联想到前面url中最后的那个“:id”就不难理解了。以下是控制台的输出：

可以看到，else分支进了两次，第一次是把“:8071”拿掉了，第二次是把“:id”拿掉了，好了，至此，url被改动的原因找到了，这是angularjs自己的一种处理GET请求参数的机制，只不过，我们的端口号中枪了。。。当然，换个角度想，也可以算是angularjs设计时没有考虑到这种情况吧。

******************************************************************告一段落的分割线*********************************************************************************

那该怎么解决呢？试过修改apache监听端口号之类的方法，但好像问题也比较多，最后没办法，只能考虑修改这个angular-resource.js。

上文提到，else这个分支进了两次，那为什么是两次呢？很显然，是angular针对它认为是参数的两个家伙（:8071和:id）在做循环。那么好了，让我们来看看这个两个循环中的成员：

forEach(self.urlParams, function(_, urlParam){          val = params.hasOwnProperty(urlParam) ? params[urlParam] : self.defaults[urlParam];

可以看出，是在对两个urlParam在做循环，那么这两个urlParam具体是什么内容呢？是“:8071”、“:id”还是“8071”、“id”呢？实测是后者，见控制台输出：

好了，那就可以从这个urlParam 下手，思路：如果urlParam是这种几个数字的端口号的格式，那就不做处理，跳出这次循环，进入下一个。然后来看看修改之后的代码：

if(!(/\d{4}/.test(urlParam))){          val = params.hasOwnProperty(urlParam) ? params[urlParam] : self.defaults[urlParam];  ...

其中用了4个数字的正则表达式，如果有其他情况，道理是差不多的，修改一下正则表达式即可。

这样修改之后在做前端应用的时候要注意，url中的参数名称不能是4位数字，不然就不会被正确处理，不过话说回来，一般也不会有人用4为数字来给参数起名字吧。

然后测试，OK，不报错了！

总结：虽然正则表达式平时好像用的不多，但它确确实实在很多我们察觉不到的地方发挥着作用。