Node.js AI 生成圖片儲存方案：簽名 URL 與物件保留的設計取捨

The operational constraint that changes this design is revocation: an expiring URL can stop future access after its deadline, but it is not a delete operation and it cannot make a file that somebody already downloaded disappear. Short answer: store AI-generated images as private objects, keep the object key rather than a public URL in the Node.js application database, and create a short-lived signed download URL only after the application authorizes a request.

That choice separates three lifetimes that teams often collapse into one: the database record, the private object, and the temporary credential embedded in the link. Treat them as separate state machines. A five-minute link doesn't imply a five-minute object, and deleting an object doesn't clean up a stale database row unless the application arranges that transition.

This is an architecture decision, not an SDK trick.

What should a Node.js service store for private AI-generated images and signed download URLs?

Store an opaque object key and the metadata needed to enforce your own policy. Don't store a previously signed URL as the durable location of the image; it is a temporary credential with a deadline, so persisting it as if it were an object identity creates a predictable expired-link failure later. A record can contain an internal asset ID, owner or tenant ID, object key, media type, creation time, lifecycle state, and any model-run identifier required for traceability. The bucket name can live in deployment configuration rather than every row if one bucket boundary is sufficient.

The invariants are more important than the exact schema:

• Objects are private by default, and only the authorization path can ask for a download link.
• Object keys are unguessable identifiers, not user-supplied filenames and not authorization claims.
• A database row becomes ready only after the upload operation has succeeded.
• Link expiry is shorter than the period for which the caller may retain access.
• Object retention is enforced independently through an explicit deletion workflow or a lifecycle policy.

The last point deserves suspicion. AWS documents lifecycle management as the mechanism for managing objects through defined lifecycle actions, including expiration; that is storage retention policy, not request authorization. A signed link answers “may this caller fetch this object until this time?” Lifecycle configuration answers “when should this object cease to exist?” Mixing those answers produces either data that vanishes too early or private files that remain forever because everybody assumed link expiry was cleanup.

Name the failure boundaries before choosing a library. Generation can succeed while upload fails, upload can succeed while the database write fails, a client can request an asset it doesn't own, and a legitimate link can expire during a slow handoff. These are ordinary distributed-state outcomes. The application needs an idempotent repair path for an uploaded object without a committed row, plus periodic reconciliation for rows stuck before ready; it doesn't need to pretend that a database transaction also covers a remote object store.

Record the boundaries before choosing an object storage option

The decision is between direct private-object access, an application proxy, and public objects with hard-to-guess names. The third option is rejected here: obscurity in a key is useful collision resistance, but it is not an access-control rule.

Decision: use private objects and request-time signed URLs for the normal path, with a deliberately short lifetime selected from the product's actual download behavior. Keep the proxy as a separate option for assets whose authorization must be evaluated on every read.

There isn't a universal expiry value. A browser displaying a freshly generated preview might need only 300 seconds, while a queued export delivered to another system may need longer because the consumer doesn't start immediately. I'm not sure what duration fits your system without a distribution of queue delay, client retry time, and clock error; measure those three, choose a percentile that matches the product promise, and add only a small operational margin.

Longer is easier.

It also enlarges the interval during which a copied link remains usable — a real security trade-off, not a configuration detail.

Provider compatibility needs the same caution. “S3-compatible” can reduce client changes, but the exact endpoint, signing configuration, request fields, and lifecycle behavior must be checked against the selected service's current documentation. DigitalOcean publishes its Spaces behavior and usage documentation, while AWS publishes S3 lifecycle rules; neither URL should be treated as evidence that every implementation has identical semantics. Your mileage may vary, particularly around optional features and defaults.

Put authorization and signing on one critical path

The critical path should be boring: parse an internal asset ID, load its row, authorize the current principal against that row, ensure the asset is ready, then ask a narrow storage adapter to sign a download for that exact object key. The browser never supplies a bucket or object key to the signer. This closes a common confused-deputy gap in which a valid user can persuade an otherwise legitimate signing endpoint to mint access to somebody else's object.

The following Python expresses the boundary as a small port. In a Node.js implementation, the controller, repository, and storage adapter map to the same operations; the storage adapter should call the selected provider's maintained Node.js signing API with values derived from server-side state. The example intentionally avoids a vendor route or hand-built signature because those details are provider-specific and an almost-correct signer is an authentication bug.

from dataclasses import dataclass
from datetime import datetime, timezone
from typing import Protocol


@dataclass(frozen=True)
class Asset:
    asset_id: str
    tenant_id: str
    object_key: str
    state: str


class AssetRepository(Protocol):
    def get(self, asset_id: str) -> Asset | None: ...


class PrivateObjectStore(Protocol):
    def sign_download(
        self,
        *,
        object_key: str,
        expires_in_seconds: int,
        response_media_type: str,
    ) -> str: ...


def create_download(
    *,
    asset_id: str,
    caller_tenant_id: str,
    repository: AssetRepository,
    storage: PrivateObjectStore,
    now: datetime | None = None,
) -> dict[str, str | int]:
    asset = repository.get(asset_id)
    if asset is None or asset.tenant_id != caller_tenant_id:
        raise PermissionError("asset is not available to this caller")
    if asset.state != "ready":
        raise RuntimeError("asset is not ready for download")

    ttl_seconds = 300
    checked_at = now or datetime.now(timezone.utc)
    url = storage.sign_download(
        object_key=asset.object_key,
        expires_in_seconds=ttl_seconds,
        response_media_type="image/png",
    )
    return {
        "url": url,
        "expires_in_seconds": ttl_seconds,
        "authorized_at": checked_at.isoformat(),
    }

Keep the response explicit about duration rather than making clients parse the signature query. A client can request a fresh link when necessary. Don't log the returned URL: query parameters may carry the temporary credential, so access logs, analytics events, exception payloads, browser history, and chat messages all deserve review. Log the asset ID, caller ID, authorization result, chosen TTL, and a request correlation ID instead.

Uploads need an equally clear ordering. Generate or receive the image, compute the final server-selected key, upload it as private content with the correct media type, and only then mark the row ready. If the process stops after upload but before the state transition, reconciliation can locate the pending record or remove an orphan according to retention policy. If it stops before upload completes, the record remains non-ready and no signing path exposes it.

No magic.

Just explicit states.

Test expiry, isolation, cleanup, and recovery separately

A happy-path browser test proves very little. The useful test matrix crosses tenant ownership, object state, and time: the owner can obtain a link for a ready asset; another tenant cannot; a pending asset cannot be signed; a link works before its deadline and is refused after it; requesting again produces a currently valid credential; and object deletion makes subsequent downloads unavailable regardless of an older link's nominal deadline. The exact storage response for a refused request is provider behavior, so assertions should target the security outcome rather than bake an undocumented error body into application logic.

Use a real isolated bucket or an accurate service fixture for signing tests. A mock can verify that object_key and expires_in_seconds reached the adapter, but it cannot prove that the provider accepts the signature, that endpoint configuration is correct, or that the downloaded bytes have the intended media type. Those belong in a small integration suite. Keep unit tests around authorization exhaustive because that boundary is fully under application control.

Observability should answer four questions without exposing credentials: how often link creation is allowed or denied, how old an asset is when requested, how many assets remain in intermediate states, and whether deletion or lifecycle cleanup matches the intended retention window. An HTTP 403 seen by a client can mean expiry or lack of access depending on the architecture, so the application-side authorization event and storage-side request identifier are more useful than a raw URL. Set alerts on stuck-state age and cleanup backlog, not on the mere existence of an expired link.

Deployment also has a quiet trap: changing buckets, regions, endpoints, or signing identities can invalidate assumptions held by old application instances. Roll configuration as a versioned unit, exercise a signed download in the target environment before shifting traffic, and keep TTL short enough that a rollback doesn't leave a long tail of credentials tied to the rejected configuration. This won't replace a migration plan for the objects themselves.

Why reject permanent links, and when should a proxy win?

Permanent public links are rejected for private generated files because access cannot be made temporary; rotating an opaque filename after a leak is deletion-and-rewrite under a new identity, with every referencing row and cache now part of the incident. They remain valid for content deliberately published to anyone, such as a public gallery asset, where caching and stable identity matter more than caller-specific authorization. Stick with public delivery only when “anyone who finds the URL may keep using it” is the actual policy.

Signed URLs have a different catch: they are bearer credentials until expiry. They are not suitable when a permission change must take effect immediately, when each byte range needs a fresh policy decision, or when the server must transform or inspect every response. Use an authenticated streaming proxy in those cases. The proxy can reevaluate the session per request, but the team must then own streaming limits, cancellation, backpressure, bandwidth cost, and denial-of-service controls — responsibilities that direct object delivery keeps outside the application process.

The durable decision is therefore conditional. Use request-time signing when bounded delegation matches the policy and direct delivery is valuable; use a proxy when continuous application control outweighs its operational load; use public objects only for intentionally public material. Whichever path wins, preserve the same asset identity, private-by-default upload discipline where applicable, explicit retention state, and tests around the failure boundaries. SDK syntax will change sooner than those invariants.

Sources

• https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html
• https://docs.digitalocean.com/products/spaces/