Source-derived document; review findings and open questions with the application owner.

10. Deployment and Operations

In this document

10.1 Purpose and operational scope

The application is an ASP.NET MVC web system for managing waste-shipment notifications, supported by API components, external service clients, file scanning, database access, and background operational controls. The supplied source shows operational mechanisms for authentication, dependency injection, request filtering, error routing, logging, retry policies, virus scanning, maintenance mode, and database migration/test execution. It does not establish the complete production topology, deployment pipeline, hosting platform, database connectivity, or release procedure. E0520 E0510 E0513

Operationally, the system’s purpose is to keep requests within the expected security and application preconditions, provide controlled failure responses, and support the maintenance of application data and schema. The evidence supports these mechanisms as source-level behaviour; it does not prove that every mechanism is enabled in a particular environment.

10.2 Actors and operational responsibilities

The principal operational actors evidenced by the source are:

An authenticated web user, whose request is subject to cookie authentication and application-wide request filters.
An administrator, who can access administrative functions and, according to API tests, protected error-log and mediator endpoints.
A deployment or support operator, who can configure maintenance mode and run the database migration utility interactively.
The application process, which creates controllers and services through Autofac, calls configured API clients, applies retry policies, and handles selected request errors.
The virus-scanning service or implementation, which receives uploaded file content through the scanning API.
The database migration operator/toolchain, which invokes AliaSQL.exe to apply or test database scripts. E0520 E0506 E0504 E0513

The source does not identify named production roles, separation-of-duties controls, deployment approvals, or who is permitted to change environment configuration.

Open question for Harten: The inspected artifacts are FilterConfig.cs, MaintenanceModeFilterTests.cs, Program.cs, and the project configuration files. Evidence of production role ownership, deployment permissions, and operational runbooks would resolve who is accountable for enabling maintenance mode, applying migrations, and responding to failures.

10.3 Application startup and dependency configuration

At application startup, Autofac registers MVC controllers, model binders, HTTP abstractions, custom modules, MVC filter providers, and assembly modules. The API client module registers clients including IwsClient, OAuthClient, UserInfoClient, and CompaniesHouseClient. The visible lifetimes are not uniform: IWS and user-information clients are reported as request-scoped, OAuth clients as singletons, and the Companies House client has no established lifetime in the supplied evidence. E0520 E0510

The application also uses OWIN cookie authentication. The identity-validation logic rejects an identity when the access-token expiry cannot be parsed or has already passed, and signs the user out in that situation. Sliding expiration is configured, but the evidence does not establish the duration or how it interacts with token expiry. E0520

API interaction is configured with Serilog and Polly-related retry support. This establishes that logging and retry abstractions are part of the client composition; it does not establish which calls are retried, the retry count, the back-off interval, or the destination of production logs. E0520 E0510

Source-derived diagram. Some relationships may be inferred and require review.

Preparing diagram…

View Mermaid diagram source

flowchart LR
    Request[HTTP request] --> Auth[OWIN cookie authentication]
    Auth --> Filters[Global request filters]
    Filters --> MVC[MVC controller]
    MVC --> DI[Autofac dependencies]
    DI --> Clients[Configured API clients]
    Clients --> External[External services]
    Clients -. retry details unresolved .-> Policy[Polly policy]

10.4 Request gates and maintenance mode

The global filter configuration registers an optional maintenance-mode filter followed by HTTPS enforcement, email verification, organisation requirements, administrator approval, API error handling, anti-forgery error handling, and virus-found handling. The source identifies nominal filter ordering, but the implementations of the filters and their bypass conditions are not included. E0510

The API test suite provides stronger evidence for maintenance mode: MaintenanceModeFilterTests.cs verifies that the Web API filter returns HTTP 503 ServiceUnavailable when executed. FilterConfigTests.cs verifies that the filter is conditionally included according to IAppConfiguration.MaintenanceMode. Therefore, the observed operational pattern is configuration-controlled service unavailability for API requests when the filter is registered and active. E0506

Whether the MVC web application, static content, health checks, or administrative bypasses are also blocked is unknown. A 503 response from the tested API filter should not be generalized to every application route.

Requirement OPS-REQ-001 — Maintenance response: When the configured maintenance-mode condition causes MaintenanceModeFilter to execute for an API request, the application shall return HTTP 503 ServiceUnavailable. E0506

Characterisation scenario candidate

Given MaintenanceMode is enabled in IAppConfiguration
When an API request passes through the registered MaintenanceModeFilter
Then the response status is 503 ServiceUnavailable

Open question for Harten: The inspected artifacts are FilterConfig.cs, FilterConfigTests.cs, and MaintenanceModeFilterTests.cs. A deployed configuration example and integration tests covering MVC routes, anonymous endpoints, health checks, and administrator access would establish the full maintenance boundary.

10.5 Error handling and request failure behaviour

The application defines routes for custom 403, 404, and 500 error pages. It also registers HandleApiErrorFilter, AntiForgeryErrorFilter, and VirusFoundFilter. The source supports the existence of these error-handling components and routes, but not the exact response body, logging behaviour, retry interaction, or whether sensitive exception details are suppressed in production. E0520

The application includes a virus-scanning module that selects between local and client-based scanner implementations according to configuration. The API controller is protected by authorization by default, while its parameterless scan action is explicitly anonymous in the tested source. The byte-array scan action delegates to IVirusScanner.ScanFileAsync; the tests verify the controller shape and delegation, not the scanner’s detection policy or storage behaviour. E0504

This creates an operational distinction between a scan request that is exposed anonymously and the controller’s default authorization requirement. The source does not establish why the anonymous action exists or whether it returns sensitive information.

Requirement OPS-REQ-002 — Virus-scan delegation: When the byte-array scan operation receives file content, it shall invoke IVirusScanner.ScanFileAsync and return the scanner result through the API response. E0504

Characterisation scenario candidate

Given a ScannerController with an injected IVirusScanner
When the byte-array Scan action receives file bytes
Then IVirusScanner.ScanFileAsync is called with those bytes
And the returned scan result is returned by the action

Open question for Harten: The inspected artifact is ScannerControllerTests.cs. Evidence of scanner implementation, maximum upload size, timeout, quarantine behaviour, and handling of a virus-positive result would resolve the operational safety model.

10.6 Database migration and test-data operations

A separate console executable supports database migration and test-data operations through AliaSQL.exe. Its title identifies it as the “AliaSQL Database Migrations Visual Studio Runner”. The Main method presents a menu: Update, Create, Rebuild, TestData, Baseline, and Exit. For a selected operation, it constructs command-line arguments containing the verb, database server, database name, and script path, starts AliaSQL.exe, captures standard output, prints it, and pauses for user confirmation. E0513

The script path is resolved by moving two parent directories from the current working directory and appending Scripts. This is an observed implementation detail and means the tool depends on a particular working-directory/build-output layout. The supplied source does not show a migration lock, transaction policy, backup step, dry-run mode, or explicit exit-code handling. E0513

Configuration uses the DatabaseServer and DatabaseName app settings. An empty server value falls back to .\sqlexpress; an empty database name is derived from the executable filename after removing database-related suffixes. The default database name reported by the configuration is EA.CoreTest. These defaults support local or test use, but do not establish production configuration. E0513

Source-derived diagram. Some relationships may be inferred and require review.

Preparing diagram…

View Mermaid diagram source

flowchart LR
    Operator[Operator input 1-6] --> Runner[Migration runner]
    Runner --> Args[AliaSQL verb/server/name/scripts]
    Args --> AliaSQL[AliaSQL.exe]
    AliaSQL --> Output[Captured standard output]
    Output --> Console[Console display]
    Runner -. exit-code handling unresolved .-> Result[Migration result]

Requirement OPS-REQ-003 — Migration operation selection: The migration runner shall map menu selections 1 through 5 to Update, Create, Rebuild, TestData, and Baseline, and selection 6 to exit. E0513

Requirement OPS-REQ-004 — Database-server fallback: When DatabaseServer is empty, the migration runner shall use .\sqlexpress as the database server. E0513

Characterisation scenario candidate

Given DatabaseServer is empty
When the operator selects a migration operation
Then the AliaSQL command arguments contain .\sqlexpress as the server

Open question for Harten: The inspected artifact is Program.cs and App.config. Migration logs, AliaSQL documentation, and deployment scripts would resolve whether failures stop releases, whether commands are transactional, and whether production migrations require backups or approval.

10.7 Deployment evidence gaps

The evidence confirms .NET Framework targets in the web and supporting projects, including .NET Framework 4.8 for the database integration executable and virus API test project. It also confirms ASP.NET MVC/Web API, OWIN, Autofac, bundling/minification, and resource-based localisation. E0520 E0513 E0504

It does not establish the hosting model, IIS site configuration, application-pool identity, TLS certificate management, secrets storage, database server topology, scheduled jobs, monitoring, alert thresholds, rollback procedure, or release artefact naming. These are consequential operational behaviours and should not be inferred from project references or configuration declarations alone.

Open question for Harten: The inspected artifacts are the project files, App.config, Startup.Auth.cs, FilterConfig.cs, and Program.cs. Deployment manifests, IIS configuration, environment-specific settings, CI/CD definitions, infrastructure code, and production runbooks would resolve the remaining deployment and support model.

Contains public sector information licensed under the Open Government Licence v3.0. Original public repository. This independent Harten analysis was not commissioned, approved or endorsed by DEFRA or the Environment Agency.

Analysed source-archive hash is recorded; its exact upstream Git commit has not been established. The generated material does not establish complete requirements, operational security or functional equivalence.