Closed NinoFloris closed 6 years ago
Why? It's very much part of identity, it's not stand alone.
Yes this was intentional as we wanted to expose the API from IdentityCookiesBuilder to customize the cookies further
@blowdart You might not use this day to day but it breaks normal AddAuthentication fluent builder flows. There is this expectation around certain service builders that they don't branch into different builder instances as it breaks your configuration chain.
All the libraries I know of, even big ones like aspnet-contrib openid server just provide you with the option of their own configuration inside a lambda and then correctly return with the AuthenticationBuilder they work on.
The pattern of returning a custom builder is also used with the AddMvc() extension method which reutrns the IMvcBuilder. While I personally don't mind either approach I do prefer the case of returning a custom builder as it promotes a chain of configuring one service and then moving on to the next with clear separation as shown below.
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_1)
services.AddIdentity<TUser, TRole>()
.AddDefaultTokenProviders()
.AddEntityFrameworkStores<ApplicationDbContext>();
@NinoFloris You are entirely correct that a lot of libraries use the approach of providing an action to configure the service examples of this would be EF's AddDbContext as shown below.
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(
Configuration.GetConnectionString("DefaultConnection")));
In the end this is properly a question of personal preference and expectation.
We periodically close 'discussion' issues that have not been updated in a long period of time.
We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.
Consider changing AddIdentityCookies to be in line with other authentication builders by returning the AuthenticationBuilder instead of IdentityBuilder