"Down for maintenance" feature
The AuthP's multi-tenant code contains features to update, delete, move (hierarchical only) and move database (sharding) - see Additional resources
All of these changes are done while the application is running, but any user that can change a tenant data could cause problems, which with worse could be corruption of the tenant data! Also, user reading a tenant during a change might contain invalid data. In version 4.3.0 of the AuthP library a feature called "Down for maintenance" feature (sometimes shortened to "down") was added. This document explains how this feature works and what you need to do to use this optional feature.
NOTE There is an article called "How to change / move databases on a live ASP.NET Core web site" which covers this topic in more detail.
The "Down for maintenance" feature contains a way to divert a user's HTTP request to a "please wait" type page, if the data they want to access is set as "down". The figure below shows the case where "tenant 123" is changed / moved within "Down" section which will divert any users linked to "tenant 123" to a "please wait" page, while users not linked to “tenant 123” would work normally.
There are four types of "downs", some are
This is triggered by the ISetRemoveStatus service SetTenantDownWithDelayAsync before a tenant move is run and released when the move has finished. Any tenant users linked to the tenant being moved will diverted to a "please wait" page while the "down" is in place.
NOTE: if there is a exception in the move command, then the tenant "down" will still be in place and must be manually removed via the Status controller.
Allows an admin user to manually “down” a tenant database, thus diverting all users linked to the tenant database to a page saying, “stopped by admin”. Access to the tenant can be restored by an admin manually removing this this “down”.
This permanently diverts all users linked to the deleted tenant to a page saying, “the tenant is deleted”. This is a permanent divert, but it can be removed manually.
In AuthP you can't delete a tenant until all of its users are deleted, but an already logged-in tenant user could try to access the tenant. This "down" version makes sure an already logged-in tenant user is caught.
This allows an admin user to manually “down” the whole application. Every user apart from the admin who took the app “down” will be diverted to a page with an explanation and expected time when the app will be available.
There are three
- Startup: Registering the services / middleware
- Adding a StatusController (or an equivalent Web API)
- Using the ISetRemoveStatus service to set / remove a “down” state Understanding the “down for maintenance” middleware
There are two parts to setup the register the “down for maintenance” feature:
- Registering the “down for maintenance” services
- Adding the “down for maintenance” middleware.
_NOTE: See Example4's Program's file (hierarchical tenant design) or Example6's Program's file (single-level + sharding) for examples of the setup.
Both parts are applied in the ASP.NET Core Program / Startup code. First is the registering of the FileStore cache, which holds the various “down” statuses, and the ISetRemoveStatus service, which provide simple methods to add / remove “down” statuses. The code below is added in the startup section that registers services with the .NET dependency injection provider.
builder.Services.AddDistributedFileStoreCache(options =>
{
options.WhichVersion = FileStoreCacheVersions.Class;
}, builder.Environment);
builder.Services.AddTransient<ISetRemoveStatus, SetRemoveStatus>(); The “down for maintenance” middleware is added in the “app” part of the ASP.NET Core startup code – see the highlighted line that adds the extra middleware.
var app = builder.Build();
//other app code left out
app.UseAuthentication();
app.UseAuthorization();
app.UseDownForMaintenance();
//other code left outYou need a