Multiple Asp.net programs share the session (the peripheral interface of the SSO Program)

In the recent period, some customers have to perform SSO Single Sign-On.

I have previously designed a page specifically for clicking login. The address of the verification center can be modified in Web. config. In this way, if many customers use the same single sign-on request method, different customers only need to modify the address of the Verification Center in Web. config.

But the plan will never keep up with changes. User requirements are always diverse, and the program cannot meet the requirements. In this way, you must constantly modify the program for every customer who cannot obtain the SSO interface.

So I want to write an SSO Single Sign-On page if the current program remains unchanged. In this case, I encountered a problem, that is, if two virtual directories (or websites) were deployed, the cross-web session was encountered.

See the following article on the Internet:

Some time ago, I was troubled by the problem of general sessions of different web projects on the same site. I have been thinking about this problem for many days. With the help of my friends, I found a solution and read some related articles online. However, the descriptions in these articles are not detailed enough. I will sort out the relevant knowledge so that I can search for them in the future and help people who encounter such problems in the future.

The following are some notes:
1. Different Sites or virtual directories cannot share sessions.
2. By default, vs. Net creates a web project as a virtual directory of a project.
3. It is best to have only one set of web. config and Global. asax for multiple projects.
For the above reason, we cannot share sessions when manually creating multiple projects, but use.. Net-> other projects-> enterprise-level template projects will not have such problems.

It is not difficult to solve this problem. Pay attention to the following two points:
1. It is best to have only one set of web. config and Global. asax for multiple projects.
Merge these projects into a virtual directory. config and global. asax, although one project can be configured, we recommend that you use a set of configurations for the entire web site, and the Web under different directories. config affects the aspx configuration in different directories. If both the root directory and the web application directory have web. the config file is also set. sessionstate mode = "inproc" obviously the sessions of the two applications cannot be shared.
2. Merge multiple virtual directories or use only one site.
The specific method is to open the sub-project directory in IIS settings to view properties-> directory-> application settings, there is a delete button, click Delete to remove the virtual directory of the directory.

The problem I encountered was that I did not notice the second point.
My approach is:
In the resource manager, right-click the project directory and choose share> Web Sharing> specify a name. Then, open it with vs. net, but the session cannot be shared. I didn't notice that IIS also set the Child project to a virtual directory. When it was originally opened, vs. NET would set another project as a virtual directory, so the session could not be shared. The only thing I do is delete the virtual directory. I haven't slept well for many days because of this small problem. Hope you don't want to learn from me

Here we call the original program A, and the new program is called B.

I created a new web project (verification center is not called because of the test ).

Its function is to create a user session and jump to the management background of program.

I put the page in program B under the corresponding program. DLL files generated by program B are stored in the bin directory of program.

(To put it bluntly, it is to copy program B to program a, but do not replace the original web. config, global. asax, etc)

Note: after such processing, the Web. config called by program B is the same as the Web. config called by program. When designing program B, pay attention to it.

Test it in IIS and directly browse the page in program B. We can see that the page is directly managed in the background of program. The logon page of program a is skipped.

Successful.