Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

First-class playback on public share links

Aperta
  • Qualcosa non va?
#39 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
65/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
php
Ambito
api, backend

Direzione di ricerca

Look at the viewer source prop and the scoped listener on /s/ pages to understand current anonymous playback. Investigate save-state behavior for guests, BIOS and core fetching without a session. Add a test to prevent regression, likely in the test suite for share link functionality.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Anonymous playback via the Viewer on share links works today (the viewer's source prop, and the CSP kept on /s/ pages by the scoped listener in lib/Listener/CSPListener.php). Make it first-class.

Plan

Still valid, and the open questions now have answers worth recording:

Cores are fine. They are static files under img/cores/, served by the web server with its own .htaccess, so they need no session and already work.

BIOS is half fine. BiosService::readFor(?string $userId, $name) takes a nullable user id and, with null, skips the per-user folder and falls through to the instance-wide store — so the service layer already tolerates an anonymous caller. The blocker is the route, not the service: lib/Controller/BiosController.php carries no #[PublicPage], and in fact none of the app's own controllers do. So on a share page every one of /arcade/bios, /arcade/state, /arcade/states and /arcade/sram is refused before it reaches any of this. A BIOS-requiring system cannot currently be played anonymously at all.

That makes the shape of the work clearer than when this was filed:

  • Add a public route for BIOS reads only, scoped to a valid share token, serving the instance-wide store and never a user's own folder. The per-user path must stay unreachable from a share page — that is the one place this could leak something.
  • Decide save-state behaviour for guests. Probably none, with a friendly note: there is no user to own a state, and the alternatives (writing into the sharer's folder, or browser-local storage) are each a surprise to somebody. Saying plainly that progress will not be kept is better than a save button that half works.
  • Add a test so it does not regress. There is none today, and this is a path that breaks quietly — a share page either plays or shows a console error nobody sees.
Watch for
  • The CSP listener decides on the share token and on whether the share holds something playable, so a public BIOS route has to agree with it about what a valid token is rather than check separately.
  • A share of a single ROM file and a share of a folder are different cases; the viewer handles both, so whatever is added should be tried against both.
Lingua principale
JavaScript
Stelle
1
Fork
0
Merge medio
7h 9m
PR unite (30g)
2

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di RobLoach/nextcloud-arcade

Tutte le issue di RobLoach/nextcloud-arcade

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.