Skip to main content

Velox Web Repository TODO

Static review performed on 2026-07-05.

Scope:

  • Reviewed the ASP.NET Core web application, service layer, repositories, EF Core contexts, views, and project structure.
  • Did not modify application code.
  • Did not run the site or execute automated tests.
  • Stability focus was on upload handling, database access, security-sensitive defaults, concurrency, dead/stale code, and 32/64-bit deployment assumptions.

High Risk​

Webhook upload path trusts the request Filename header​

Files:

  • velox.web\Areas\Api\Controllers\TransactionController.cs
  • velox.service\Services\Num\WebHookService.cs

Evidence:

  • TransactionController.Upload reads Request.Headers["Filename"] and passes it to WebHookService.Upload.
  • WebHookService.Upload uses Path.ChangeExtension(filename, webHook.FileExt) and then Path.Combine(webHook.FilePath, filename).
  • The upload is written with FileMode.Create.

Risk:

  • If the header contains path traversal segments or an absolute path, the final output path may escape the intended webhook folder unless normalized and checked elsewhere.
  • FileMode.Create can overwrite an existing file.
  • Filename collisions and malicious filenames can cause data loss, security exposure, or failed integrations.

Suggested direction:

  • Treat all request-supplied filenames as untrusted.
  • Normalize the final path and verify it remains under the configured webhook directory.
  • Generate server-side unique filenames where possible.
  • Log rejected filenames with enough detail for operations, but avoid echoing unsafe paths to users.

Webhook upload buffers the full request body in memory​

Files:

  • velox.web\Areas\Api\Controllers\TransactionController.cs
  • velox.service\Services\Num\WebHookService.cs

Evidence:

  • TransactionController.Upload copies Request.Body into a MemoryStream.
  • Request/form limits are configured very high in velox.web\Program.cs.

Risk:

  • Large uploads can consume substantial memory and destabilize the web process.
  • Multiple concurrent uploads can amplify memory pressure.
  • This is especially risky for integration endpoints where callers may retry aggressively.

Suggested direction:

  • Stream uploads directly to a temporary file or bounded storage path.
  • Enforce per-endpoint size limits.
  • Add clear rejection behavior for oversized payloads.

Medium Risk​

Request and form limits are set to maximum values​

File:

  • velox.web\Program.cs

Evidence:

  • FormOptions values such as value length, multipart body length, and boundary/header limits are set to int.MaxValue.

Risk:

  • The app is more exposed to memory, disk, and CPU exhaustion from oversized requests.
  • The risk compounds with upload endpoints and request-body buffering.

Suggested direction:

  • Replace global maximums with endpoint-specific limits.
  • Size limits should match actual business payload expectations.

Sensitive EF Core logging is enabled unconditionally​

File:

  • velox.data\Infrastructure\DataModule.cs

Evidence:

  • Both VxConfigContext and VxDataContext enable EnableSensitiveDataLogging().

Risk:

  • SQL parameters and potentially sensitive business data can be written to logs.
  • Production logs can expose customer data, credentials, identifiers, or integration payload values.

Suggested direction:

  • Gate sensitive logging behind development-only configuration.
  • Confirm production logging sinks and retention before enabling any detailed SQL logging.

Identity password policy is weak for a customer-facing web app​

File:

  • velox.data\Infrastructure\DataModule.cs

Evidence:

  • Password length is configured to 5.
  • Digit, uppercase, lowercase, and non-alphanumeric requirements are disabled.
  • Unique email is not required.

Risk:

  • Weak passwords increase account compromise risk.
  • Duplicate emails can complicate account recovery, support, and audit trails.

Suggested direction:

  • Confirm whether this app is internal-only or customer-facing.
  • Strengthen defaults before production exposure.
  • Document any deliberate exception with compensating controls.

MVC component blocks on async work with .Result​

File:

  • velox.web\Areas\Transaction\Components\TransactionMenu.cs

Evidence:

  • Invoke calls _InterfaceService.GetActive().Result.

Risk:

  • Blocking async calls can consume thread-pool threads under load.
  • It can also create deadlock-style symptoms depending on synchronization context and future framework changes.

Suggested direction:

  • Convert to InvokeAsync and await the service call.
  • Keep data access asynchronous through the call chain.

Repository base classes contain NotImplementedException paths​

Files:

  • velox.common\Repositories\RepositoryBase.cs
  • velox.common\Repositories\RepositoryIdentityBase.cs
  • velox.data\Repositories\Num\DevExtremeRepositoryBase.cs

Evidence:

  • Base repository permission/default methods throw NotImplementedException.
  • Add, Update, or delete/default paths can call these methods depending on concrete repository behavior.

Risk:

  • A reachable base path can fail at runtime after deployment.
  • The failure mode is a 500-level error unless translated higher up.

Suggested direction:

  • Confirm which repository base methods are abstract-by-convention versus intentionally callable.
  • Prefer abstract methods or explicit unsupported-operation exceptions with targeted tests.

Manual number generation can race​

File:

  • velox.data\Repositories\Num\DevExtremeRepositoryBase.cs

Evidence:

  • Manual number generation uses a max-plus-one style query.

Risk:

  • Concurrent inserts can generate the same number.
  • Empty tables or filtered datasets may produce unexpected behavior depending on the exact query path.

Suggested direction:

  • Use a database sequence, identity, transaction with suitable isolation, or a locked allocation table.
  • Add concurrency tests around any externally visible number generation.

Legacy/root startup files create confusion​

Files:

  • Program.cs
  • Startup.cs
  • Program - Copy.cs
  • velox.web\Program.cs

Evidence:

  • Active application startup appears to be under velox.web\Program.cs.
  • Root-level startup files exist outside the active project and include incomplete or legacy startup code.

Risk:

  • Maintainers may patch the wrong startup file.
  • Security or logging changes can be applied to inactive code and missed in the deployed app.

Suggested direction:

  • Document active startup entry points clearly.
  • Move inactive startup examples out of normal search paths or mark them as historical.

Low Risk​

zUnneeded Code and static/vendor assets create high search noise​

Folder:

  • zUnneeded Code

Evidence:

  • The folder contains a large number of files that do not appear to be active app code.

Risk:

  • Search results and code metrics are noisy.
  • Maintainers can accidentally copy old patterns into active code.

Suggested direction:

  • Document whether the folder is reference-only.
  • Exclude it from normal code-review metrics if it remains.

Very large EF Core context files are generated/metadata-heavy​

Files:

  • velox.data\Context\VxDataContext.cs
  • velox.data\Context\VxConfigContext.cs

Evidence:

  • VxDataContext.cs is several thousand lines.
  • The context maps a large database schema used by web workflows.

Risk:

  • Large generated-style files are hard to review manually.
  • Schema drift between velox-data and EF mappings can produce runtime errors.

Suggested direction:

  • Treat context updates as schema-coupled changes.
  • Use migration/schema comparison checks or generated model validation.

Duplicate Code Areas​

  • Many administration/transaction CRUD controllers and views follow similar patterns.
  • DevExtreme grid/view helper code is repeated across views.
  • Root startup files duplicate older ASP.NET Core startup patterns.
  • Data repository patterns repeat across entity-specific repositories.

Dead Code / Stub Areas​

  • zUnneeded Code appears inactive or historical.
  • Root Program.cs, Startup.cs, and Program - Copy.cs appear inactive relative to velox.web\Program.cs.
  • Repository base methods that throw NotImplementedException should be treated as incomplete until call paths are proven unreachable.

Thread Safety / Concurrency Concerns​

  • Upload handling writes files with FileShare.None; concurrent uploads with the same name will fail or overwrite depending on path behavior.
  • Manual max-plus-one number generation can race under concurrent inserts.
  • Scoped EF Core DbContext registration is the expected pattern, but any singleton service that captures a context would be risky; no such capture was confirmed in static review.
  • Blocking .Result in MVC rendering can reduce request concurrency.

32-bit / 64-bit Concerns​

  • No direct pointer-size issue was identified in the .NET web code.
  • The app is likely Any CPU, but deployment depends on IIS/app-pool architecture and native SQL Server drivers.
  • If the web app shares native components or file paths with 32-bit Velox services, document the expected bitness and driver requirements.

Performance Concerns​

  • Full-body upload buffering can exhaust memory.
  • Global maximum form/request limits increase denial-of-service risk.
  • Large EF models and broad queries should be watched for slow startup or slow first request.
  • Synchronous blocking on async calls can reduce throughput.
  • Views with large server-rendered grids may become expensive as transaction volumes grow.

Areas Difficult to Maintain​

  • Large generated EF context files.
  • Repetitive CRUD controllers and Razor views.
  • Mixed active and inactive startup code.
  • File-upload path behavior split between controller and service layer.
  • Shared schema dependency with velox-data.

Open Questions​

  • Is velox-web currently customer-facing, internal-only, or experimental?
  • What upload sizes are expected for webhook transactions?
  • Is the request Filename header part of a documented external API contract?
  • Which repository base methods are intentionally abstract-by-convention?
  • What is the planned replacement path for this web app if it will be rebuilt in Angular or React?