Skip to main content

Velox Web2 Repository TODO

Static review performed on 2026-07-05.

Scope:

  • Reviewed the .NET Aspire host, Blazor web project, API service, EF Core contexts, dynamic endpoint mapping, service defaults, and proxy/auth services.
  • Did not modify application code.
  • Did not run the solution or execute tests.
  • Stability focus was on startup behavior, dynamic database-driven routes, proxy forwarding, auth failure handling, logging, and deployment assumptions.

High Risk​

API service startup depends on database rows and can fail hard​

File:

  • Velox.ApiService\Program.cs

Evidence:

  • Startup reads setup data from VxSetup using .First().
  • Startup then reads API/action configuration from the database and maps endpoints before app.Run().
  • URL segments and REST endpoint paths are derived from database values.

Risk:

  • Missing setup rows can crash startup.
  • Empty, invalid, duplicated, or conflicting route data can prevent the API service from starting or can map unexpected endpoints.
  • A bad database configuration can become a full API outage.

Suggested direction:

  • Validate setup/config rows before route registration.
  • Fail with clear diagnostics when required data is missing.
  • Detect duplicate or empty routes and report them explicitly.
  • Consider a health check that reports dynamic route configuration state.

Dynamic route values are not clearly validated or deduplicated​

Files:

  • Velox.ApiService\Program.cs
  • Velox.ServiceDefaults\Tools\UrlHelpers.cs

Evidence:

  • UrlHelpers.GetLastSegment returns an empty string for null/whitespace values and also returns an empty string on parsing exceptions.
  • Route registration uses database-derived base URL and REST endpoint values.
  • Dynamic endpoints are mapped once at startup.

Risk:

  • Invalid URL data can collapse into an empty route segment.
  • Duplicate routes can conflict at startup or route requests incorrectly.
  • Changes in the database after startup are not reflected until restart.

Suggested direction:

  • Make invalid URL parsing explicit instead of silently returning an empty segment.
  • Add route normalization, validation, and duplicate detection.
  • Log the final route map at startup.

Proxy endpoint downgrades HTTPS to HTTP​

File:

  • Velox.ApiService\Endpoints\VeloxAPI.cs

Evidence:

  • The proxy derives a base URL using veloxApiServiceEndpoint.Replace("https", "http").
  • The comment indicates this is temporary.

Risk:

  • Requests intended for TLS can be forwarded over cleartext HTTP.
  • In production, this can expose integration payloads, bearer tokens, user identifiers, and session data.
  • String replacement can also alter unexpected parts of a URL.

Suggested direction:

  • Remove protocol rewriting before production use.
  • Validate the configured upstream URI with Uri.
  • Make TLS requirements explicit in configuration.

Medium Risk​

Proxy/auth exceptions can leak implementation details or return incorrect status codes​

Files:

  • Velox.ApiService\Endpoints\VeloxAPI.cs
  • Velox.ApiService\Service\UserService.cs

Evidence:

  • UserService.AuthBearer throws general Exception values for authentication failures.
  • The proxy writes upstream exception messages into the HTTP response.
  • The success value returned from AuthBearer is not visibly used after authentication.

Risk:

  • Authentication failures can become 500 errors instead of 401/403 responses.
  • Exception messages can expose implementation details to callers.
  • Future changes may assume the returned success flag is meaningful even though exceptions currently drive failure behavior.

Suggested direction:

  • Use typed auth results or typed exceptions.
  • Translate auth failures into explicit HTTP status codes.
  • Avoid returning raw exception messages to API clients.

Proxy forwards sensitive or questionable headers​

File:

  • Velox.ApiService\Endpoints\VeloxAPI.cs

Evidence:

  • The allowed header list includes values such as Cookie, Host, and Referer.
  • The proxy injects X-UserNum and Forwarded headers.

Risk:

  • Forwarding Host or cookies can confuse upstream routing or auth behavior.
  • Injected identity headers must be trusted only when the upstream service is not directly reachable by untrusted clients.
  • RemoteIpAddress may be null in some hosting/test contexts.

Suggested direction:

  • Define a strict proxy header policy.
  • Avoid forwarding client cookies unless required.
  • Ensure upstream services reject spoofed identity headers from untrusted network paths.

Sensitive EF Core logging is enabled unconditionally​

File:

  • Velox.ApiService\Program.cs

Evidence:

  • Both VxConfigContext and VxDataContext are configured with EnableSensitiveDataLogging().

Risk:

  • SQL parameters and customer/integration data can appear in logs.
  • Production log retention can turn this into a data exposure issue.

Suggested direction:

  • Gate sensitive data logging behind development configuration.
  • Confirm whether Aspire logging/exporters capture these values.

API configuration is snapshotted at startup​

File:

  • Velox.ApiService\Program.cs

Evidence:

  • API/action rows are loaded into lists before route mapping.
  • Routes are registered before the application starts serving requests.

Risk:

  • Changing Velox API configuration in the database requires a service restart.
  • Operators may believe a database change is live when it is not.

Suggested direction:

  • Document restart requirements.
  • Consider a route reload mechanism only if runtime changes are required.
  • Add a startup log containing the loaded API route count.

API service has limited defensive checks around upstream configuration​

Files:

  • Velox.ApiService\Program.cs
  • Velox.ApiService\Endpoints\VeloxAPI.cs

Evidence:

  • The upstream Velox API service address comes from setup/config data.
  • Proxy URL construction assumes the configured address is valid enough to transform.

Risk:

  • Null, malformed, or unreachable upstream URLs can fail startup or produce noisy runtime errors.
  • Misconfiguration can look like a code defect unless diagnostics are clear.

Suggested direction:

  • Validate configured upstream URI at startup.
  • Add health checks for upstream reachability.
  • Make configuration errors distinct from request forwarding errors.

Low Risk​

Blazor web project appears template-like​

Folder:

  • Velox.Web

Evidence:

  • The web front end is small compared with the API service.
  • Static review found limited domain behavior in the Blazor project.

Risk:

  • If this is a future front end, current scaffold code may create search noise.
  • If it is already published, domain behavior may be incomplete.

Suggested direction:

  • Document whether this project is experimental, internal, or intended for customer use.

Large generated EF Core context files are maintenance-heavy​

Files:

  • Velox.ApiService\DBContext\VxDataContext.cs
  • Velox.ApiService\DBContext\VxConfigContext.cs

Evidence:

  • The contexts map large Velox databases.

Risk:

  • Schema drift between velox-data, Delphi services, and web2 can cause runtime failures.

Suggested direction:

  • Keep EF model updates tied to database schema changes.
  • Add startup model validation or integration checks where possible.

Duplicate Code Areas​

  • EF Core context/model mapping overlaps conceptually with velox-web.
  • Service-default/Aspire plumbing is template-like and should remain aligned with active project needs.
  • Dynamic route mapping branches repeat similar code for HTTP verbs.

Dead Code / Stub Areas​

  • The Blazor front end may be scaffold/future work; status is unclear from code alone.
  • Some template/service-default code may be present because of Aspire scaffolding rather than Velox-specific needs.

Thread Safety / Concurrency Concerns​

  • No obvious static mutable shared state was identified in the .NET services.
  • Scoped EF Core contexts and IHttpClientFactory are appropriate patterns.
  • The main concurrency risk is operational: dynamic API route configuration is fixed at startup while the database can be changed independently.
  • Proxy streaming should be reviewed for request cancellation, large body behavior, and upstream timeout policy before production load.

32-bit / 64-bit Concerns​

  • No direct pointer-size issue was identified in the .NET code.
  • Deployment is likely Any CPU, but it depends on the upstream Delphi VeloxAPIService and database drivers being correctly installed.
  • If the API service is hosted beside 32-bit Velox components, document expected process architecture and native dependency requirements.

Performance Concerns​

  • Startup queries and route generation run before the API starts serving traffic.
  • Proxy forwarding creates an extra hop for every dynamic endpoint request.
  • Large request/response bodies should be tested through the proxy for streaming behavior and memory pressure.
  • Route conflicts or a very large number of mapped endpoints can increase startup time and troubleshooting complexity.

Areas Difficult to Maintain​

  • Database-driven endpoint registration.
  • Proxy/auth behavior that bridges web2 to the Delphi VeloxAPIService.
  • Large generated EF contexts.
  • Aspire/template code mixed with product-specific API behavior.

Open Questions​

  • Is velox-web2 intended to replace, merge with, or run beside velox-web?
  • Should dynamic API route changes require restart, or should they reload at runtime?
  • Is HTTPS-to-HTTP rewriting only for local development?
  • Which headers must be forwarded to VeloxAPIService, and which should be stripped?
  • What authentication contract should callers receive for expired, invalid, or missing bearer tokens?