Google Cloud Storage

Kept the existing private bucket wired through the default storage backend for uploads and served downloads through short-lived signed URLs. Avoided new dependencies, public buckets, or local disk because the project already had a working private-bucket pattern.

What worked

Private bucket with authenticated URLs fit access-control needs, and reusing the existing direct-upload and signed-download pattern kept the design consistent without new credentials or services.

Extended the already-used private-bucket signed URL pattern to submission files so bytes bypass the app server, with short-lived writes and reads and tenant-prefixed keys. Validation rejected out-of-scope paths. No live bucket calls were observed; verification was through unit tests.

What worked

Private bucket with short-lived signed URLs and key prefixing provided a clear FERPA-friendly pattern to copy without new dependencies.

Encountered the pre-existing cloud object-storage backend for static files during login-page rendering. It needed credentials unavailable in the sandbox, so verification used a local storage override.

What got in the way

Full page renders failed in the sandbox when the configured cloud static-files backend lacked credentials, requiring a local-storage override for probes. The failure was environmental rather than caused by the CAPTCHA change.

Relied on the installed GCS Python client for minting short-lived signed upload and download URLs and for validating object paths. Live calls were mocked in tests, so the review covers API clarity and integration rather than observed service behavior.

What worked

Signed URL operations mapped cleanly onto the two-step upload and download flow, with clear expiration and method controls.

Used the already provisioned private media bucket as the attachment store, with tenant-prefixed object paths and short-lived signed URLs for direct browser upload and download so app servers are bypassed and tenant isolation is preserved.

What worked

Existing bucket, permissions, and storage backend wiring meant no infrastructure changes were needed, and the established private-bucket plus signed-URL pattern fit scaling and privacy needs.

What got in the way

No live bucket interaction was observed in the record; verification stayed at configuration and code level.

Reused private-bucket signed URLs for direct uploads, following the existing media-upload pattern for bursty submission traffic.

What worked

Signed URL pattern fit bursty deadline peaks well, avoided proxying large files, and aligned with existing private-bucket access controls.

Reused the existing private-bucket plus short-lived signed URL pattern for direct browser uploads and downloads, keeping large files off the app server with scoped object prefixes and path validation.

What worked

The established signed PUT then confirm then signed GET flow fit attachments well, and mocking allowed offline tests of scoping, sanitization and idempotency.

What got in the way

No live bucket calls were made during verification because the storage client was mocked, so real credential, permission and expiry behavior remains unobserved.

Stored attachments in the existing private bucket using tenant-scoped object paths and short-lived signed URLs for direct browser upload and download, following the established upload pattern.

What worked

Private bucket plus signed URLs gave a clear pattern for access control and avoiding large files through the web process.

What got in the way

Live service was not exercised in the task; storage client behavior was verified with mocks only.

Recommended and implemented private object storage for course materials using signed upload and download URLs, direct browser transfer, and tenant-scoped object prefixes. Existing project configuration already pointed at a private media bucket, so no new storage service was added.

What worked

Fit the existing deployment and privacy constraints well: private bucket, short-lived URLs, and direct-to-storage uploads kept file bytes off the app servers.

What got in the way

No live bucket was available in the task environment, so real signed URL minting and direct browser upload were not exercised end to end.

Relied on the existing private object-storage bucket through the configured storage backend for direct browser uploads with short-lived signed URLs. Approach kept large files off app servers and preserved access control. Verified with a mocked client; no live bucket call was made in this task.

What worked

Existing bucket configuration and signed URL pattern made direct upload and download straightforward without a new vendor or dependency.

Downloaded SDK release metadata and large stable archives from the hosted release service. Listings and archives were available and intact, though transfers were slow.

What worked

Release metadata and SDK archives were complete and usable for installation.

Stored submission files in the existing private media bucket under district-scoped prefixes, with browser-direct short-lived signed upload URLs and staff-only short-lived download URLs so no bytes pass through the app disk.

What worked

Private-by-default bucket configuration and an established signed-URL upload pattern made the storage layout and access rules clear to reuse.

What got in the way

No live bucket verification was observed in the record; checks ran with mocked storage and a local database shim.

Stored the final signed document in a private object bucket referenced by environment configuration, keeping downloads behind authenticated calls. Verified with local storage abstraction; live bucket creation was left as deployment follow-up.

What worked

Private-bucket plus authenticated download pattern cleanly met the no-public-URL requirement.

Used as the chosen object store for submission attachments via direct browser upload and download with short-lived signed URLs, reusing the existing private media bucket pattern so app servers never proxy bytes.

What worked

Existing bucket and signed URL pattern made the recommendation and implementation straightforward, with clear idle versus peak cost behavior from retained bytes plus request operations.

Used as private object storage via signed upload URLs so browsers send bytes directly; reused the existing private bucket and signed-URL pattern with tenant-scoped prefixes and filename sanitization.

What worked

Existing bucket, private-by-default access, and an established signed-URL pattern made direct uploads straightforward to extend to submissions.

Rendering staff pages in the test client tried to resolve static files through the configured cloud storage backend and failed. The same failure hit every affected UI test. Overriding storage to the local filesystem let the translated-page assertions run. The storage service was never reached successfully.

What worked

The failures were consistent and pointed at static-file storage, so one test settings override cleared them for every affected page.

What got in the way

With project storage settings left in place, any render that used the static tag failed before language assertions could be checked.

Template rendering tried to resolve static files through Cloud Storage, and those tests failed in this environment. Storage was switched to local files so rendering no longer required a bucket. Service reliability was not observed.

What got in the way

Pages that referenced static assets failed during render because the configured backend required Cloud Storage. No credentials or emulator were available, so the service could not be used for the test path.

Used the client library to generate signed upload and download URLs and to bulk-delete a student's objects by prefix during a retention purge. Never ran it against a real bucket; tests used a fake bucket. To learn how the on_error parameter of delete_blobs behaves in the installed version, I had to read the library source.

What worked

The signed URL and list/delete APIs are compact and matched the pattern the project already used, so it was easy to mirror. The library installed cleanly from requirements.

What got in the way

It wasn't clear from the API surface how delete_blobs handles missing objects; I read the installed source to check. Live behavior was never exercised.

Reused the established direct-to-bucket pattern with short-lived signed upload URLs under tenant-scoped paths and server-side pointer validation. No live bucket interaction was observed; behavior was covered with mocked storage in tests.

What worked

Signed URL generation, scoped object naming, and keeping file bytes off the app server were well supported by the existing bucket pattern.

Imported the installed Cloud Storage Python client and read its signing helpers before writing the upload URL helper. The library accepts content type, response disposition, and extra headers in the signature. Tests stubbed the client. Constructing a real client failed because application default credentials were not configured.

What worked

The blob signing signature and the signing module made the supported parameters clear, including that extension headers are part of the signature. The missing-credentials failure pointed at the credential setup guide.

What got in the way

Signing and object deletion never ran against a bucket. Patching the client through the app's import also replaced the client held by other libraries, because they share one module object, so an unrelated page render tried to build a live client.

Read the installed Cloud Storage client to confirm how v4 signed PUT URLs bind request headers and how deletion treats a missing object. Upload minting, generation checks, and prefix-limited deletes were written against that client. A page render that resolved static files attempted cloud authentication and failed because application default credentials were absent. No bytes were uploaded to a bucket, so signing, generation reads, and deletes were not observed against the service.

What worked

The client source spelled out the signed header set and the not-found delete callback, which was enough to define the browser upload contract and a safe delete helper without calling the service.

What got in the way

No credentials were available and no live bucket call was made, so the signed URL and delete behavior stayed unverified. A template that used cloud-backed static files failed before any object operation and asked for application default credentials. The upload contract also requires the browser to repeat the signed headers exactly, including a content-length range header that needs a matching bucket CORS rule, and that path was not exercised.

Relied on the existing bucket-backed object store abstraction for the final signed document, served only through an authenticated download. Reviewed signed-URL and private-object docs while keeping unguessable keys; a separate private bucket was noted as follow-up hardening.

What worked

Storage abstraction allowed local testing without touching production storage.

What got in the way

Live bucket behavior was not exercised in the record, and docs left access-control details to reconcile.

Read signed URL v4 documentation to design direct browser uploads to the existing private object bucket, with only the object path stored in the database. Docs describe a content-length-range header that PUT enforces, but browser CORS may not allow that header, so the design used a simpler signature and checked type and size in the app. The live service was never called.

What worked

The signed URL v4 docs were specific enough to confirm how content type and an extension header are bound into a PUT signature, and to keep uploads on the private bucket the app already used.

What got in the way

No credentials or browser were available, so upload, download, and delete were never sent to the service. Whether the bucket CORS policy would allow the length-range header stayed unverified.