其他系统访问.Net Core网站页面 跳转时SessionId会发生变化

[changuncle]

1、http://10.90.19.109:701/iframeapprove.html?eip_title=普通申请&url=http://localhost:63888/home?taburl=DomainGroup/DomainGroup_Apply/Audit?id=2e0094d4-3ef7-438a-bca0-52c0c5012cd6&urltype=index，在http://10.90.19.109:701网站中通过上述地址来跨域访问Core网站http://localhost:63888/home/Index页面
2、访问Home控制器中的Action时，需要先在CheckSessionFilter中检查是否登录，若用户未登录但是是通过其他系统单点登录访问本系统的页面就将请求地址保存到Session中key=currentUrl，然后跳转到/Login/Index
3、在/Login/Index页面读取Session中key=currentUrl的值，但是/Login/Index页面的Session和http://localhost:63867/home/Index页面的Session不是同一个对象，导致无法获取Session中key=currentUrl的值

请问为什么Core网站中页面跳转时SessionId会发生变化呢？麻烦各位大佬给看看。

[changuncle]

services.Configure<CookiePolicyOptions>(options =>
{
// This lambda determines whether user consent for non-essential cookies is needed for a given request.
options.CheckConsentNeeded = context => false;
options.MinimumSameSitePolicy = SameSiteMode.None;
});
这种情况只在被其他系统跨域访问的时候才出现，本系统正常登陆时存储、读取Session是没问题的

[haiancdp0503]

以前的经验：跨域请求时 浏览器 post 不会发送cookie,只是在浏览器端可以共享cookie

[正怒月神]

你都说跨域访问访问了啊。。。 你要携带自己的cookie。不然服务器找不到sessionID

[小大飞]

你的session是进程内session，跨域后是另一个进程。所以生成的sessionid肯定是一样的。
这种跨站认证，session不能使用进程内session，要么使用独立的认证中心，要么使用redis、memached、内存数据库等性能较好的缓存容器实现独立的session功能。

跨站点认证，也可以不用session技术，可以改用token，在登录系统认证后，生成token，携带token跳转到第三方网站，第三方网站直接解密token，检查token信息是否有效，判断用户的登录状态。

[小大飞]

你的session是进程内session，跨域后是另一个进程。所以生成的sessionid肯定不是一样的。
上面写错了。

[weixin_43864439]

引用 4 楼 小大飞 的回复:

你的session是进程内session，跨域后是另一个进程。所以生成的sessionid肯定是一样的。 这种跨站认证，session不能使用进程内session，要么使用独立的认证中心，要么使用redis、memached、内存数据库等性能较好的缓存容器实现独立的session功能。 跨站点认证，也可以不用session技术，可以改用token，在登录系统认证后，生成token，携带token跳转到第三方网站，第三方网站直接解密token，检查token信息是否有效，判断用户的登录状态。

正解棒棒哒

[以专业开发人员为伍]

传统的（基本的）asp.net 机制，在页面第一次被生成和客户端访问时，假设程序像 Session 集合写入和会话状态数据，那么这个时候才会产生固定的 SessionID，并且将此SessionID 放到 cookie 中传出。这样下一次“刷新”问题时就有了 SessionID 传来。

如果你不符合这个机制，那么自然，貌似“刷新”访问而实际上 Session 是不存在的。

[以专业开发人员为伍]

另外，每一种技术都有其适合和不适合的地方。其中最不应该做的事情就是用原本是纯粹 UI 的东西来保存后台数据。UI就是为了展示用的，并且更容易随着过时、被淘汰而早早被淘汰。同时 UI 部分也会应用户的千变万化的需求改变而改变。所以不要想当然地把数据放到 UI 组件，然后又在别的地方从 UI 组件来“获取”数据。UI 组件要依赖底层数据，而不是把
UI 控件当作保存底层数据的东西。

你使用 Action 之类的“一遍遍刷新重建 html 页面”的 asp.net mvc 机制来当作一个纯粹数据服务，这就好像把大象当作蚂蚁来看待，是个很不好的做法。

[以专业开发人员为伍]

理论上说，每当前端获取后台 html 页面，实际上都相当于是在后台重启一个应用程序。一定要把每一个“页面”看作一个独立的应用程序，这样才能看清楚 asp.net mvc 的模式是多么累赘和低效率，意识到需要考虑多少冗余问题才能保证丰富的页面状态！所以最近8、9年，专业的 html/js 应用是纯粹前端的独立应用程序，跟服务器端只是进行纯粹数据服务交互，而不是靠服务器端来一遍遍地刷新产生新的 html 页面的。

当你从另外一个应用，重定向回原来的网页应用时，你能意识到“这是再次重启原来那个网站应用”，这个时候设计上才会比较顺利。