Dependency injection (DI) is a technique whereby one object supplies the dependencies of another object. It decouples the objects so that no client code has to be changed simply because an object it depends on needs to be changed to a different one. MVC Framework already supports dependency injection, but has been very difficult to use this technique in ASP.NET Web Forms application. This new feature will make it much easier to use dependency injection in ASP.NET Web Forms application. This feature enables the following:
- Support setter-based, interface-based and constructor-based injection in web application project in Handler, Module, Page, User control and Custom control.
- Support setter-based and interface-based injection in web site project in Handler, Module, Page, User controls and Custom controls.
- Be able to plug in different dependency injection frameworks.
Here’s a simple example of how you can use this feature.
Step 1 – Implement IServiceProvider. You can implement your own DI logic in it or plug in third party DI framework, e.g. Unity, Ninject. Below is an example to inject ILog object through constructor.
Step 2 – Set WebObjectActivator in Global.asax.
Step 3 – Use Dependency Injection in your Webform page.
ASP.NET – SameSite Cookie
SameSite prevents the browser from sending this cookie along with cross-site requests. In .NET Framework 4.7.2, a new property SameSite is added in HttpCookie type and ASP.NET will add SameSite attribute into the set-cookie header if HttpCookie.SameSite is set to SameSiteMode.Strict or SameSiteMode.Lax. The support for SameSite cookie is two-fold in this case:
- In HttpCookie object
- In FormsAuthentication and SessionState cookies
You can set SameSite for a HttpCookie object as follows.
You can configure HttpCookie SameSite at application level through web.config as follows.
You can add SameSite for FormsAuthentication and SessionState cookies through web.config.
SQL – Azure AD Universal and Multi-factor Authentication Support
Growing compliance and security demand requires many customers to use Multi-Factor authentication (MFA). In addition, current best practices directs developers from not including any user password directly to the connection string. We have extended SqlClient Connection String by introducing a new Azure AD Interactive authentication keyword to support MFA. This also enables support of Azure AD Authentication.
This feature introduces a new value for the existing “Authentication” keyword, specifying a new authentication method called “Active Directory Interactive”. The new interactive method supports native and federated Azure AD users as well as Azure AD guest users. When this method is being used, the MFA authentication imposed by Azure AD is supported for SQL DB. In addition, a user password is requested as part of an interactive dialog enabling us to adhere to security best practices.
Originally SQL connectivity in .NET Framework supported only ActiveDirectoryPassword and ActiveDirectoryIntegrated. Both of these are part of the non-interactive ADAL protocol which do not support MFA. With the new ActiveDirectoryInteractive keyword, the SQL connectivity supports MFA as well as existing authentication methods (password and integrated authentication) allowing users to enter user password interactively without the need to persist passwords in the SQL connection string.
This feature can be configured with tools like SQL Server Data Tools (SSDT), as illustrated below. In the latest Visual Studio preview, a new authentication option called “Active Directory Interactive Authentication” can be used to support MFA authentication to SQL database.
The following sample shows how to instantiate the communication provider that is required to register it to a specific authentication method. It also shows creating connections to SQL database using the different authentication methods, of which two are existing ones: ActiveDirectoryPassword, ActiveDirectoryIntegrated and the latest ActiveDirectoryInteractive.
0 Comments
If you have any doubts,please let me know