1, http://10.90.19.109:701/iframeapprove.html? Eip_title=common applications & amp; Url=http://localhost:63888/home? Taburl=DomainGroup/DomainGroup_Apply/Audit? Id=2 e0094d4-3 ef7-438 - a - bca0-52 c0c5012cd6 & amp; Urltype=index, through the above address in the web site http://10.90.19.109:701 to cross-domain access the Core http://localhost:63888/home/Index page
2, access to the Home in a controller Action, need to check whether the Login in CheckSessionFilter first, if the user Login but not through the other system single sign-on access to the system page will request the address saved to the Session key=currentUrl, then jump to the Login/Index
3, in the/Login/Index page reads the value of the Session key=currentUrl but/Login/Index page Session and the http://localhost:63867/home/Index page Session is not the same object, result in unable to get the value of the Session key=currentUrl

Could you tell me why the Core site page jump SessionId will change? Troublesome everybody bosses to look at,

CodePudding user response:

Services. Configure (options=& gt;
{
//This lambda determines been user consent for non - essential cookies is men for a given request.
Options. CheckConsentNeeded context of==& gt; False;
Options. MinimumSameSitePolicy=SameSiteMode. None;
});
This kind of situation only by other systems cross domain access, only when the system normal landing store, read the Session is no problem

CodePudding user response:

Previous experience: browser cross-domain request post will not send cookies, only in the browser can share a cookie

CodePudding user response:

You all say cross-domain access visited ah,,,
Do you want to bring their own cookies, or server can not find the sessionID

CodePudding user response:

Your session is a process within the session, is another process after the cross-domain, so the generated sessionid must be the same,
The cross-site authentication, the session could not be used in the session, or use independent certification center, or use redis, memached, in-memory database performance such as better cache container to achieve the function of independent session,

Cross-site certification, also can need not the session technology, can be converted to a token, after login system authentication, to generate the token, carrying the token to jump to third party sites, third-party websites directly decryption token, check whether the token information is effective, judge the user logged in,

CodePudding user response:

Your session is a process within the session, is another process after cross domain, so the generated sessionid sure ,
Write wrong,

CodePudding user response:

reference 4 building small fly reply:

your session is a process within the session, is another process after cross domain, so the generated sessionid must be the same,
The cross-site authentication, the session could not be used in the session, or use independent certification center, or use redis, memached, in-memory database performance such as better cache container to achieve the function of independent session,

Cross-site certification, also can need not the session technology, can be converted to a token, after login system certification, to generate the token, carrying the token to jump to third party sites, third-party websites directly decryption token, check whether the token information is effective, judge the user logged in,

truth bang-bang dalai

CodePudding user response:

Traditional (basic) asp.net mechanism, the page is generated and the client to access for the first time, assuming that the program written like the Session collections and Session state data, so this time fixed SessionID is produced, and put the SessionID in cookies, so the next time "refresh" problems have SessionID,

If you don't conform to the mechanism, so natural, looks like the "refresh" to visit and actually there is no Session,

CodePudding user response:

In addition, each technology has its suitable and unsuitable places, for the most should not do is with originally pure UI objects to hold the background data, UI is to display, and more easily with outdated, obsolete and early, and UI part can be changed by the user's protean demand, so don't take it for granted to put data into the UI components, and then from the UI components in other places to "get" data, UI components to rely on the underlying data, rather than the
UI control as the underlying data,

You use the Action such as "again to refresh the rebuild HTML page" asp.net MVC mechanism as a pure data services, it is as if the elephant as ants, is a very bad,

CodePudding user response:

In theory, every time the front-end HTML page background, are in fact quite so restarting an application in the background, be sure to put each "page" is regarded as an independent application, so you can see the asp.net MVC pattern is how burdensome and low efficiency, realize the need to consider how much redundancy to ensure rich page state! So the last 8 or 9 years, specializing in the HTML/js application is pure front independent application, interact with the server side just pure data service, rather than on the server over and over again to refresh the new HTML page,

When you are in another application, redirect back to the original web application, you can realize "it will be a restart again the same site application", this time design will go smoothly,