The year before last I wrote an essay complaining about Microsoft's handling of Session_End events in the ASP.net architecture, and I was ashamed to say that I didn't understand the complexity of the ASP.net runtime. To be honest, capturing authentication and logoff authentication means a lot to me. For example:
Check to see if the SSO provider already exists before you log on;
Load the relevant permissions after the login completes, which may be completely unrelated to the specific application project;
Notifies the SSO provider to clear the cookie content after the login is completed;
......
The solution provided by the current ASP.net is to add the Formsauthentication_onauthenticated method to the Global.cs to catch the validated event. The drawbacks of this approach are:
1. Only forms authentication can be captured, and Windows and Passport authentication methods cannot be captured;
2. Can only catch identity cancellation events that have been authenticated events;
3. The Global.cs file must be modified.
Any one of these flaws is unacceptable to me. At the time, asp.net1.1 solved the problem with five or six interfaces, more than 10 classes, and an output class that required access to the appropriate method when the application was logged in and out of the log, rather than using the FormsAuthentication method freely. Now the problem is solved satisfactorily. The idea is this:
Create two session tables in one HttpModule, one for authenticated sessions, and another for unauthenticated sessions, so that In the Httpapplication.acquirerequeststate event, find the state of each session in both tables:
None of the state one or two tables. This is a new session
Status two authenticated in a session table that has been authenticated
State three is not authenticated in a session table that is not authenticated
If it is state one, the authentication method for all SSO providers is called immediately, and if any one of the SSO providers confirms that authentication has passed, the status is immediately adjusted to state two, and all handler that subscribe to status changes are notified. If it is state two or state three, the actual status of the session will be compared immediately. The actual status status of the session can be obtained by querying the HttpContext.User. If they are different, the status of the records in the table is adjusted according to the situation, and notifications are issued to the handler that subscribe to the identity change.
There is a problem: The session list query frequency is very high, each request will inevitably query once. So the choice of algorithm is higher here. I chose the BinarySearch algorithm for the string array in the actual project. This will inevitably adjust the position of the string in the array each time you add or remove a new session to keep the sort state. Of course, in the alignment process also need to adjust the ratio of hit rate, such as three states, obviously the highest proportion of state two (of course, the array is often the largest), should be preferred.
The Final solution is: only three interfaces, one HttpModule and several internal classes are implemented, There is no need to modify the Global.cs, and there is no output class to be invoked by the login authentication module, and all SSO providers only need to be configured through Web.config, completely transparent to the business layer. These three interfaces are: A configuration parameter Context interface, an SSO provider Interface (handler interface that captures identity state changes simultaneously), a factory interface for a handler interface ( To keep the constructor freedom of the handler interface and to decide whether to establish an implementation class instance of the handler interface.