@siax/mobile-files (0.1.0)
Installation
@siax:registry=https://git.cloud.siax.io/api/packages/sax3l/npm/npm install @siax/mobile-files@0.1.0"@siax/mobile-files": "0.1.0"About this package
@siax/mobile-files
Presignerad, återupptagbar uppladdning till ST0RE/MinIO. Reimplementerar INTE objektlagring (MOB-02).
Status: implementerad och testad (29 tester). Aldrig körd mot en riktig ST0RE-bucket — se Vad som INTE är gjort.
Kärnbussgränsen (MOB-02)
Filen går aldrig genom appens API (FUNK-09). Appens API gör två saker: signerar adresser och kvitterar att uppladdningen är klar. Byten går direkt från telefonen till objektlagret. Att proxa en 500 MB-video genom en Node-process betyder att en enda användare kan äta hela tjänstens minne — och att ST0RE, som äger objektlagringen, får en konkurrent i appens backend.
Vad som faktiskt är byggt
| Fil | Innehåll |
|---|---|
src/magic.ts |
MIME-detektion på innehåll (magiska bytes) |
src/policy.ts |
Storleksgräns + typvitlista, POLICIES.avatar/document/video |
src/upload.ts |
uploadFile() — single + multipart, resume, omförsök, framsteg |
src/source.ts |
UploadSource — bytesSource() och rangeSource() |
src/errors.ts |
Problem Details + FileError med maskinläsbara koder |
MIME på innehåll, inte på filändelse
Filändelsen och Content-Type från en filväljare är användarstyrd indata.
faktura.pdf kan vara ett HTML-dokument. Om bucketen sedan serverar filen med
den påstådda typen har vi byggt en lagringsplats för lagrad XSS.
Detekterade typer: PNG, JPEG, GIF, PDF, WEBP (RIFF + undertyp), HEIC/HEIF, MP4,
MOV, ZIP, MP3. Okänt innehåll ger null — och avvisas, om inte policyn
uttryckligen sätter allowUnknownType. Vi gissar aldrig.
content-type på PUT:en sätts från den sniffade typen, så en förfalskning
kan inte vandra in i bucketen ens när uppladdningen tillåts.
Två lägen: validateUpload() flaggar en ljugande filändelse
(declaredTypeWasForged) men släpper igenom — en användare med en felnamngiven
bild ska inte blockeras. validateUploadStrict() avvisar. Flaggan är till
för att appen ska kunna rapportera händelsen vidare för AUD0-loggning.
Detta är inte ett virusskydd och inte en fullständig filtypsdetektor. Innehållsskanning hör hemma i ST0RE/N0D.
Återupptagbarhet (OFFL-13)
Servern — inte appen — väljer single eller multipart. Vid multipart sparas
en UploadSession efter varje färdig del via onSession; persistera den och
skicka in den som resumeFrom för att fortsätta. Färdiga delar laddas inte om,
och färska presignerade adresser hämtas för de återstående (de gamla har gått ut).
Ett billigt fingeravtryck (storlek + första 16 bytena) hindrar att en session återupptas med fel fil — annars blir objektet två filer hopklistrade, vilket upptäcks först när någon försöker öppna det.
Omförsök sker per del: en 500:a på del 37 av 80 startar inte om hela filen. En permanent 4xx (utgången signatur) försöks inte om alls.
Minne
Filen läses aldrig in i sin helhet. UploadSource kräver read(start, end), och
magisk-byte-kontrollen läser exakt 16 bytes. En 2 GB-video kan valideras och
laddas upp utan OOM.
Vad som INTE är gjort
- Aldrig körd mot en riktig MinIO/ST0RE-bucket. Alla tester använder en
fake-S3 med injicerad
fetch. ETag-hanteringen (citattecken) och multipart-kvittensen följer S3-API:t men är inte verifierade mot MinIO. UploadTransportär ett kontrakt, ingen implementation. Paketet innehåller ingen HTTP-klient mot appens API — apprepot kopplar in sin egen. Det är avsiktligt: presign-endpointens form ägs av appen, inte av SDK:t.- Ingen RN-filsystemsadapter.
rangeSource()tar enread-funktion; att kopplaexpo-file-system(eller RNFS) är apprepots jobb. Paketet importerar medvetet ingen RN-modul — annars vore det obyggbart i Node och i CI. - Ingen parallell deluppladdning. Delarna laddas upp sekventiellt. Det är långsammare än nödvändigt på bra nät, men gör framstegsrapporteringen och sessionstillståndet enkla att resonera om. Parallellism är inte implementerad.
- Ingen nedladdning, ingen radering, inga signerade läs-URL:er. Endast uppladdning.
- Ingen kryptering på klienten. Objekten skyddas av ST0RE:s serversidekryptering; klientsidig kryptering är inte byggd.
- Ingen typkontroll har körts (repot saknar byggberoenden — samma villkor som övriga paket).
Tester
cd packages/mobile-files && node --test # eller: npm test
29 tester, alla gröna. Kräver Node ≥ 22.18, inga beroenden.