我有一个仅作为API使用的Sails.js（v0.12.0）应用程序。单个页面应用程序会在此应用程序中对端点执行ajax调用。Sails.js在每次调用时创建新会话
路由'PUT /login'用于验证用户，并在我的控制器中设置req.session.authenticated = true。
对于我的控制器上的所有其他功能，policies.js文件包括'*':['isAuthenticated']。 这个政策是非常简单的：
module.exports = function isAuthenticated(req, res, next) {
if (req.session.authenticated) {
return next();
}
return res.forbidden('You are not permitted to perform this action.');
};
当我检查在Redis的("connect-redis": "^3.0.2")的价值，我可以看到我对会话对象设置的值。
随后，在调用'GET /profile'时，由于用户已通过身份验证，因此它会通过策略。
这适用于我的开发机器（ubuntu）上的sails应用程序和Redis，以及使用邮递员本地（即localhost域中的所有内容）。
将应用程序部署到我们即将生产的系统时出现问题。用户界面是一个运行在Apache上的php应用程序，它为该网站的所有网页内容提供服务。
此前端应用程序的某些部分使用我们的sails.js后端，它在第二个服务器上运行，例如， http://1.1.1.1/index.php已加载，从此单页应用程序调用ajax调用为http://1.1.1.2/login等。 尚未注册域名，我们仅在测试时使用这两个IP地址。这里使用的ip只是例子。
当在sails应用程序中调用/login时，用户通过身份验证并更新会话，使用redis-cli可以看到该会话是正确的。 （Redis也在node/sails框中运行）。
/profile的下一次呼叫失败，并返回403（由于该策略）。在请求头中，我可以看到Origin为http://1.1.1.1，cookie包含sails.sid，响应包含Set-Cookie，但是具有不同的sails.sid。
在redis-cli中，我可以看到为第二个呼叫创建了一个新的会话，所以看起来/profile的呼叫在某种程度上不会使用同一个会话。
从浏览器中调用：
$http({
method: 'GET',
url: 'http://1.1.1.2/profile',
withCredentials:true
})
.then(function (response) {
console.log(response);
});
在cors.js，我有
module.exports.cors = {
allRoutes: true,
origin: 'http://1.1.1.1,http://1.1.1.2',
credentials: true,
methods: 'GET, POST, PUT, DELETE, OPTIONS, HEAD',
headers: 'content-type'
};
据我所知，这应该允许呼叫从http://1.1.1.1到http://1.1.1.2但初始会话不被再次使用来并且对受到isAuthenticated策略影响的任何端点的任何呼叫都将失败，并且将导致403的失败。
因为一切都“在我的机器上工作”我怀疑我的配置有关于这两个域的问题。
任何帮助将不胜感激。