sora digital photo frame

The Problem

This repository turns any device with a web browser into a smart digital photo frame, featuring a remote admin panel for photo management and a full-screen slideshow. While the functional scope is clear, the codebase exhibits significant technical debt that impacts security, maintainability, and deployment readiness for a client engagement.

What This Does

The project splits concerns between a React frontend located in server/public/ and an Express backend in server/. The frontend (server/public/admin.js, server/public/js/) handles the UI, slideshow logic, folder selection, and admin panel interactions. The backend (server/server.js, server/routes/) manages API routes, authentication, and file operations. A Dockerfile and docker-compose.yml are present, indicating the intent for containerized deployment. Core features include a Material Design 3-styled UI, keyboard navigation for the slideshow, and a "wake lock" to prevent screen sleeping during display.

How It Is Wired

Execution starts at init defined in server/public/access-accounts.js:9, which reaches 29 functions and triggers loadAccounts to read the filesystem via fs.readFile. The most connected module in the internal call graph is server/routes/api (instability 0.88), with 7 outgoing import edges, making it a high-impact hub for changes. A critical wiring issue exists in server/server.js, which configures CORS with a wildcard origin paired with credentials; this allows any website to make authenticated requests with a user's browser cookies attached. The call graph shows high-frequency utility functions like showToast (called from 18 places) and loadFolderContents (called from 12 places), indicating these are chokepoints for user feedback and data loading.

How To Use It

Setup: Install dependencies using npm install (inferred from package.json files present in root and server/). Configuration: Environment variables are defined in server/.env.example. Notably, the OAuth setup and any API keys required for Google Photos integration would be configured here. Running it: The project can be started via docker-compose up using the provided Dockerfile and docker-compose.yml, or directly with node server/server.js to start the Express server. The admin panel is accessed at http://your-server-ip:3000/admin.

Real-World Use

A consultant deploying this for a client would spin up the Docker container to display a slideshow on a lobby screen. Staff would then navigate to the admin panel to drag-and-drop new photo folders, organizing the library without touching the server filesystem directly. The folder selector would remember the last viewed path across sessions, allowing targeted slideshows for specific departments or events.

Code Health & Issues

The static analysis identified 7 findings ranked by severity:

[HIGH] Add a LICENSE - No licence file exists at the repository root, making redistribution rights undefined. Evidence: root directory.
[HIGH] Add a workflow that builds and tests this repository - No CI configuration detected across 27 source files.
[HIGH] Add a build gate for the deployable artifacts here - Dockerfile - Deployment artifacts exist with no automated workflow to validate builds.
[HIGH] Replace the wildcard CORS origin with an explicit allow list - server/server.js uses cors() with a wildcard, combined with credentials, which browsers block for security reasons and creates an attack surface.
[MEDIUM] Enable Dependabot or Renovate - 1 manifest present, no update bot configured.
[MEDIUM] Pin the container base image by digest - Dockerfile uses node:18-alpine, a mutable tag.
[MEDIUM] Expand the test suite - 1 test file against 27 source files (ratio 0.037).

The Bottom Line

This is a functional prototype with a clear feature set for digital signage, but it requires significant polish before it is suitable for a production client deployment. The absence of a licence, CI/CD, and the wildcard CORS misconfiguration are blocking issues for professional use. The codebase would benefit from splitting the oversized frontend files and establishing a build gate. It is viable for internal tooling or a proof-of-concept, but not yet for client-facing delivery without remediation.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

47 files

JavaScript27
HTML5
JSON4
Markdown3
YAML1
CSS1

ReactExpressDocker

Module dependencies

The 10 most depended-upon modules of 27, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_server_middleware_auth["auth"] n1__controllers_imageController["imageController"] n2_server_routes_api["api"] n3_server_server["server"] n4_llers_googlePhotosController["googlePhotosController"] n5_server_routes_index["index"] n6_server_routes_views["views"] n7_r_controllers_authController["authController"] n8_controllers_folderController["folderController"] n9_server_routes_auth["auth"] n7_r_controllers_authController --> n0_server_middleware_auth n8_controllers_folderController --> n1__controllers_imageController n2_server_routes_api --> n1__controllers_imageController n2_server_routes_api --> n8_controllers_folderController n2_server_routes_api --> n4_llers_googlePhotosController n2_server_routes_api --> n0_server_middleware_auth n2_server_routes_api --> n9_server_routes_auth n9_server_routes_auth --> n7_r_controllers_authController n5_server_routes_index --> n2_server_routes_api n5_server_routes_index --> n6_server_routes_views n6_server_routes_views --> n0_server_middleware_auth n3_server_server --> n5_server_routes_index

Findings

MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config
MediumNo LICENSE file - unclear usage/redistribution rights root

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high4

medium3

Add a LICENSE; redistribution rights are undefinedhigh

no licence file at the repository root

Fix: Add MIT or Apache-2.0 at the repository root.

Add a workflow that builds and tests this repositoryhigh

27 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Add a build gate for the deployable artifacts herehigh2 occurrences

Dockerfile

deployment artifacts with no workflow

Something in the repo is meant to reach a server and no automated step has ever validated it, which is the state of 125 repositories here.

Fix: Add a workflow that at least builds the image and validates the manifests.

Replace the wildcard CORS origin with an explicit allow listhigh

server/server.js

cors()

Any page on the internet can call the API with the browser's cookies attached, so a logged-in visitor to an unrelated site performs authenticated requests without knowing, and the wildcard combined with credentials is the exact configuration browsers refuse for that reason.

Fix: List the origins the API actually serves, and never pair a wildcard with credentials.

Enable Dependabot or Renovatemedium

1 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Pin the container base image by digestmedium2 occurrences

Dockerfile

node:18-alpine, node:18-alpine

An untagged or mutable base means today's build and last month's contain different libc and a different CVE set, with no record of which shipped.

Fix: Use image:tag@sha256:<digest> and enable Dependabot's docker ecosystem.

Expand the test suite; it cannot cover this codebasemedium

1 test files against 27 source files (ratio 0.037)

A reviewer reads "has tests" and assumes a safety net that covers two files out of eighty-five, which is how untested paths ship behind a green badge.

Fix: Add tests for the highest fan-in modules first.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.