encapsulate project to injectable parts

[snys98]

I'm wondering if it is possible to change the structure of this project to two different projects(or nuget packages would be better).

• IdentityServer4.Admin
  this project will register all operations to a specific endpoint(like "/identity-server-admin") as a rest api.

• IdentityServer4.Admin.UI
  this project will register all default page to a specific endpoint(like "/identity-server-admin-ui") and it would be possible to inject some css or js or something.

Just like what swagger&swagger-ui has done.

Besides, thanks for your huge efforts for this repo.

[skoruba]

Great idea @snys98.

I think it's absolutely possible. I want to prepare the REST api like you mentioned.

What do you suggest with UI part?

Thank you for your feedback. :)

[snys98]

@skoruba
I used to modify something of injecting a UI.

Here register a middleware which serves the index.html and enable directory browse into the assembly(where we can put pages there):
https://github.com/microexs/Microex.Swagger/blob/8159f6ac84c9672ea938a0f1d760035436641e62/Microex.Swagger/SwaggerUI/SwaggerUIBuilderExtensions.cs#L19

And here to inject things we need to customize the pages.
https://github.com/microexs/Microex.Swagger/blob/8159f6ac84c9672ea938a0f1d760035436641e62/Microex.Swagger/SwaggerUI/index.html#L30
https://github.com/microexs/Microex.Swagger/blob/8159f6ac84c9672ea938a0f1d760035436641e62/Microex.Swagger/SwaggerUI/SwaggerUIIndexMiddleware.cs#L47
https://github.com/microexs/Microex.Swagger/blob/605c57d1843c53a55738ac499f4bc35bc3ea7a32/Microex.Swagger/SwaggerUI/SwaggerUIOptionsExtensions.cs#L14

But considering there are multiple pages and all these pages requires authentication of a role like "IdentityServerAdmin", it would be much more harder to achieve this.

Besides, IdentityServer has already provided some model like IdentityServer4.Model.Client. So, I'm wondering can these models be used as dtos?

[skoruba]

I am working on REST api, but I am wondering how distribute the set of controllers as nuget package - what do you think about it @snys98?

I think - it is possible to add into nuget package some repositories and services that are connected with database model but what about api endpoints? :)

[snys98]

Maybe we should forget about the MVC pattern but try to implement a middleware instead.

I suggest all these could be done with a single line in the pipeline, like:

app.UseIdentityAdmin(options=>{
        option.EndPoint = "identity-admin";
        // more configs...
}

Then the api endpoint("/identity-admin") should deal with all the request that has the url prefix of "identity-admin" then map the sub-urls to corresponding handler functions.

[skoruba]

I've found the solution, that it's possible to add controllers from another assembly like this:

services.AddMvc()
                .AddApplicationPart(typeof(ClientController).Assembly)
                .AddControllersAsServices();

This post describes how to implement dynamic routing with another assembly.

I've built extension method like this:

public static IServiceCollection AddIdentityServerAdminApi(this IServiceCollection services, Action<ApiRouteConfiguration> configureRoute)
        {
            var options = new ApiRouteConfiguration();
            services.AddSingleton(options);
            configureRoute?.Invoke(options);

            var serviceProvider = services.BuildServiceProvider();
            var apiRouteConfiguration = serviceProvider.GetService<ApiRouteConfiguration>();

            services.AddMvc()
                .AddApplicationPart(typeof(ClientController).Assembly)
                .AddControllersAsServices()
                .AddApiRoutingConfiguration(apiRouteConfiguration); //based on the SO post

            return services;
        }

In Startup.cs:

services.AddIdentityServerAdminApi(configuration =>
            {
                configuration.ApiPrefix = "admin-ui/api/";
            });

What do you think about it?

I've wondered about custom middleware and I think this approach above it's better because in custom middleware you are working with "raw" http request and you need implement everything from scratch. :)

[snys98]

@skoruba
That's great. It's actually the way of Microsoft.AspNetCore.Identity.UI.

I know little about this kind of implemention. But I guess this may help.

[skoruba]

@snys98 Great point. I am working on it but I can't find any solution how to share the resources for localization. Razor class library provides great posibilities how to share UI across among multiple projects, but all available samples are without localization. Any idea? :)

[skoruba]

Similiar use case with sharing resx files from class library - aspnet/Localization#328

• Or use Resources (*.resx) as a part of nuget package that will be unpack in the solution - something like this:

.nuspec:

<?xml version="1.0"?>
<package>
    <metadata>...
    </metadata>
    <files>
        <!-- Add all resource files -->
        <file src="Resources\**\*.resx" target="content\Resources" />
    </files>
</package>

[snys98]

@skoruba
Sorry, I had a busy time in the last few days. Sounds like you've solved it. Congratulations.

[skoruba]

@snys98 Yes, it seems the combination of Razor Class Library and Resources for localization working well.

I am currently working on splitting the solution into three parts:

• UI
• EntityFramework
• Services (or Business Logic)

After that I'll create some nuget packages.

Again - thank you for your good ideas. 👍