User Authentication Without a Logon Window in ASP.NET Web Forms Applications
- 4 minutes to read
This topic details the steps performed from the moment when the WebApplication object has been created and initialized, until the moment an end-user has been authenticated to the application. In accordance with the Authentication Strategy that is used by the Security System in your application, end users can be asked to type credentials in a logon window to be authenticated. There are two built-in Authentication Strategies in XAF. The AuthenticationStandard authenticates end-users with the information typed in the logon window. The AuthenticationActiveDirectory does not require the logon window to be displayed. It takes the required information from the system’s active directory. This topic details how end-users are authenticated when the built-in AuthenticationActiveDirectory strategy is used. You can customize the AuthenticationActiveDirectory so that a logon window is displayed and the information typed in it is used for authentication. In this instance, read the User Authentication using a Logon Window in ASP.NET Web Forms Applications topic to learn how the logon window is displayed.
Ways to Interfere
To start the authentication process, an Object Space is created to check whether or not a record defining the user logging on exists in the application database. Before accessing the database, the compatibility of the module versions in the database and their actual versions is checked. If the versions in the database are greater than the actual ones, an exception is raised, which requires that you increase your application’s version. If lower, the XafApplication.DatabaseVersionMismatch event is raised. By default, this event is handled in XAF solutions. The event handler calls the Database Updater’s Update method, which updates the database to the required version. However, this method is called when the application is run in debug mode. In release mode, an exception is raised (you can see the entire code in your application).
Before the authenticating process is started, you can access the LogonParameters object modified by the logging on user. For this purpose, handle the XafApplication.LoggingOn event.
You can perform a custom process of checking the database and application compatibility. For this purpose handle the XafApplication.CustomCheckCompatibility event. In this instance, you should raise the XafApplication.DatabaseVersionMismatch event in this code as well, to update the database when required.
If you do not need the scenario implemented in the XafApplication.DatabaseVersionMismatch event handler, which is generated automatically in your application, write a custom event handler. For instance, you can implement a custom DatabaseUpdater class and call its Update method in the DatabaseVersionMismatch event handler.
Use the XafApplication.DatabaseUpdateMode property to set the required behavior for the updating database mechanism. For instance, you can set the UpdateDatabaseAlways value so that the database’s version is updated each time the application runs. This is useful in applications written using VB, because of the difficulty in incrementing versions in VB projects.
When the AuthenticationActiveDirectory is used, authentication is accomplished immediately after the application is started. A user is authenticated if their account has been found in the system, and the corresponding object in the database exists.
If the default authentication performed by a built-in Authentication class does not satisfy your requirements, implement a custom class. For instance, inherit from one of the built-in authentication classes: AuthenticationStandard or AuthenticationActiveDirectory. Alternatively, inherit from the base AuthenticationBase class. In your class, override the AuthenticationBase.Authenticate method. It returns the user object that is found in the database by the credentials specified by the end-user who is logging on. To see an example, refer to the How to: Use Custom Logon Parameters and Authentication topic.
The end-user customizations layer is created. In XAF ASP.NET Web Forms applications, this layer is not used, because user customizations are not stored anywhere, by default.
You can store the customizations made to a List View in the web browser cookies by setting the IModelOptionsStateStore.SaveListViewStateInCookies property of the Options node and the IModelListViewStateStore.SaveStateInCookies property of the corresponding Views | <ListView> node to true.
Handle the XafApplication.LoggedOn event to perform custom actions after the logging on procedure has completed.