Skip to main content

Upload Token System

Upload Token System

Upload Token System

This is the authoritative reference for the generic public upload-token product implemented in skyhawk_site_fixes.

Architecture

  • Public route: /upload/{token}.
  • Admin route: /admin/skyhawk/upload-tokens.
  • The public route is owned by UploadTokenForm.
  • Drupal core managed_file owns file selection, AJAX transfer, validation, and temporary file entities.
  • Files are stored under private://uploads/[token]/.
  • No custom synthetic mouse event or parallel direct-upload controller participates in the live product.

Public Upload Page Workflow

  • The public page identifies the invitation by its human-readable token label as Upload Files: [label]. The secret token value itself is not displayed.
  • Selecting files is the upload action. Drupal core managed_file immediately starts its AJAX transfer from the file-input change event; there is no second human Upload action.
  • A successful initial upload creates temporary Drupal managed-file entities and stores the physical files under private://uploads/[token]/.
  • The final button is labeled Finish submission. It does not perform the initial transfer. It finalizes the already-uploaded temporary files, records each file in skyhawk_upload_file, increments cumulative accounting, and sends the configured batch notification.
  • Server-side temporary file entities and token-specific private files are authoritative proof of the initial upload; browser presentation alone is not.

Token Lifecycle

  • A token is valid when it exists, has status active, and has not expired.
  • Generated tokens have a minimum lifetime of seven days.
  • A token may be used for multiple upload sessions until expiry or explicit administrative revocation.
  • A successful upload does not consume or invalidate the token.
  • uses_count records cumulative finalized files for administrative information only.
  • uses_allowed = 0 is retained as the unlimited-until-expiry/revocation sentinel for schema compatibility.

Upload Rules

  • Multiple files may be selected.
  • Maximum individual file size is 511 MiB (535,822,336 bytes).
  • The hosting transport ceiling remains 512 MiB for an HTTP POST, so exceptionally large batches may need to be selected/uploaded separately even though each individual file is legal.
  • After Drupal receives temporary managed files, final submission makes them permanent, records each file in skyhawk_upload_file, increments cumulative file accounting, and sends the configured batch notification.
  • Completion notifications contain only the files finalized in that batch, not every historical file associated with the token.

Administration

  • The admin form creates reusable tokens and sends the upload URL by email.
  • The admin form can explicitly revoke an active token.
  • Existing contact and purpose data are reused.
  • The current history table remains operational; conversion to a Drupal View is a later Views-first improvement, not part of the uploader replacement.

Replacement State

The public and admin upload forms were replaced in toto after a discovery audit found contradictory one-use lifecycle logic, a redundant unrouted direct-upload controller, and a custom mobile workaround that duplicated Drupal core behavior.

The old UploadTokenController and upload_token_mobile_fix.js are retired into the timestamped replacement backup rather than destroyed during initial acceptance testing.

Functional acceptance remains pending until the Pixel test verifies: legal multi-file upload, final submission, private storage, history rows, notification, reuse of the same token, explicit revocation, expiry rejection, and oversize rejection.

Current Functional Failure

Generic initial upload: ACCEPTED. A format-blind Pixel selection has been verified through Drupal core managed_file AJAX, creation of a temporary managed-file entity, token-scoped storage under private://uploads/[token]/, physical-file existence, and exact database/filesystem size agreement.

PNG, JPG, MP4, and HEIC occurred as diagnostic samples. They are not product categories. File format is not a product restriction. Extension/MIME enumeration, image-versus-video diagnosis, custom queue/serializer transport, and a separate human Upload action are closed branches.

Current acceptance boundary: Finish submission. Before that device action is authorized, the actual live finalization contract must be derived from the current UploadTokenForm and actual database schema. Do not assume history-table column names or accounting fields.

The next finalization test must then prove the behavior implemented by that discovered contract: temporary-to-permanent transition, upload history, cumulative accounting, configured notification, and reusable-token behavior.

Current Regression Token

No token label is permanently reserved as the regression token. Use a currently active, unexpired test token from the existing token system. Do not create a replacement token merely because an upload test fails.