Nederlands-Duits bedrijf brengt opensourcebestandsuploader voor browsers uit

Transloadit heeft Uppy 1.0 uitgebracht, een opensourcebestandsuploader voor browsers. Het Nederlands-Duitse bedrijf heeft de JavaScript-uploader gebaseerd op zijn 'resumable upload'-protocol Tus.

Transloadit, mede opgericht door de Nederlander Kevin van Zonneveld, heeft na drie jaar ontwikkelen Uppy 1.0 uitgebracht. Het gaat om een modulair opgezette fileuploader die onder een MIT-opensourcelicentie beschikbaar is en die ontwikkelaars kunnen integreren in hun sites en diensten.

Het voordeel van Uppy ligt volgens de makers onder andere bij het kunnen vervolgen van uploads na bijvoorbeeld verbindingsproblemen of browsercrashes. In feite is Uppy een user interface die onder de motorkap Tus draait, het protocol voor het vervolgen van uploads dat Transloadit heeft ontwikkeld en dat onder andere door Vimeo wordt gebruikt. De module biedt bij het uploaden previews van bestanden en hij toont de progressie.

Uppy 1.0 maakt dankzij server-naar-server-functionaliteit importeren van bestanden vanaf Instagram, Dropbox en Google Drive mogelijk zonder dat gebruikers deze eerst naar hun toestel hoeven te downloaden. Dit bespaart bandbreedte en accucapaciteit. Ook is direct uploaden naar S3 mogelijk en is webcam-ondersteuning aanwezig.

Momenteel ondersteunt Uppy Chrome, Edge, Firefox, Opera, Safari en Internet Explorer. In de toekomst wil het bedrijf onder andere een WordPress-plugin en het kunnen croppen van afbeeldingen mogelijk maken.

Reacties (53)

[locke960]

Uppy 1.0 maakt dankzij server-naar-server-functionaliteit importeren van bestanden vanaf Instagram, Dropbox en Google Drive mogelijk zonder dat gebruikers deze eerst naar hun toestel hoeven te downloaden.

Hoe werkt dat dan als de javascript alleen maar op je eigen device loopt? En waar blijven je account gegevens voor die diensten dan?

[kevinvz]

Uppy heeft een server component: Companion. Die praat met Dropbox en de eindbestemming, en coördineert ook de oAuth authenticatie. De token wordt op de client opgeslagen en met elk request naar Companion gestuurd, zodat Companion zelf geen geheimen hoeft te bewaren. Companion is ook open source en website bouwers installeren dit op hun server, of bijvoorbeeld 'Serverless' op AWS Lambda. Voor hen die tijd belangrijker vinden dan geld, biedt Transloadit dit ook aan als dienst.

Als je niet geïnteresseerd bent in Dropbox/Instagram/etc integratie, dan heb je Companion niet nodig, en is Uppy installeren dus een kwestie van een regel JavaScript toevoegen aan de website.

[Rob Coops]

Dus als ik het goed begrijp is het niets meer dan op het moment dat ik Companion installeer geeft de client mijn gebruiker die ik binnen AWS bijvoorbeeld aangemaakt heb met een token het recht om een bestand te downloaden.
Ik vraag me alleen af of op het moment van het generen van de token het oAuth protocol ook weet wie die andere gebruiker is die de download zal uitvoeren en dus het token alleen voor die gebruiker geschikt is. Het lijkt me anders een security probleem als dat niet het geval is. Ik zou immers dat token kunnen onderscheppen de met een andere AWS user bestanden kunnen downloaden die niet voor mij bedoelt zijn.

Nu zal dat vast en zeker iets zijn waar al lang over na gedacht is maar de documentatie rond het project is er niet er duidelijk in hoe de beveiliging geregeld is en lijkt ervan uit te gaan dat eindgebruikers oAuth2 redelijk goed kennen (wat voor een redelijk aantal mensen wat veel gevraagd is). Ik zou het zeker niet erg vinden als er wat meer informatie rond de beveiliging van het geheel zou zijn (of als die er wel is dat deze wat prominenter aanwezig is ik kan het zo snel niet vinden)

[kevinvz]

Ik kan de AWS gebruiker uit je voorbeeld niet helemaal plaatsen dus wellicht hebben we een misverstand. Misschien is het handig als ik gewoon de hele flow opschrijf, en dan kun jij aangeven of het onduidelijk/onveilig is.

• De bezoeker van een website met Uppy klikt "bestand uit Dropbox" *
• Uppy stuurt een signaal naar Companion, welke zich identificeert met Transloadit’s ** keys bij Dropbox
• Dropbox vraagt de bezoeker in te loggen, en of Transloadit bij de bestanden mag
• Als de bezoeker instemt krijgt Companion een token van Dropbox, waarmee we tijdelijk bestanden kunnen downloaden. Deze token is dus een risicofactor.
• Companion encrypt de token met een key die uniek is voor de bezoeker/sessie en stuurt hem naar Uppy (client)
• Elke keer dat de bezoeker in Uppy op een map klikt, vraagt het de nieuwe lijst met bestanden aan Companion, bij deze vraag wordt de (nog steeds door Companion ge-encrypte) token meegestuurd
• Companion decrypt de token, vraagt daarmee de lijst met bestanden op bij Dropbox en stuurt deze naar Uppy
• Wanneer het bestand is gevonden, krijgt Companion volgens deze procedure opnieuw de token, decrypt hem ook opnieuw, en download daarmee het bestand van Dropbox
• Terwijl de bytes binnenkomen, upload Companion de bytes naar de eindbestemming (afhankelijk van de configuratie: Apache, een Tus server, S3 bucket, etc)
• Companion geeft progress door aan Uppy, alsof het een lokale upload betreft
• Voltooid

* Waar ik Dropbox zeg kun je ook Instagram, etc, invullen, de flow is hetzelfde
** Transloadit als je onze Companion dienst gebruikt. Als je zelf Companion host, vraag je je eigen app keys aan bij Dropbox, en gebruik je die, staat dus ook jouw bedrijfsnaam daar

Zoals je ziet sturen we de token over het internet, dat is tricky. We weigeren wel als dit gebeurt over HTTP (geen HTTPS). Maar zoals we met Poodle, Heartbleed, and friends hebben kunnen zien, kun je vandaag een beveiligde verbinding denken te hebben (die zelfs van ssllabs aan A+ rating krijgt) die eigenlijk toch niet zo veilig is. Daarom doen we dus security in layers, met een extra encryptie slag. De client heeft alleen de ge-encrypte versie van de token, en geen keys om te decrypten, dus daar is geen ‘jackpot’ als het een XSS attack zou lukken in de LocalStorage van de browser te vissen. Companion kan uiteindelijk wel de echte token inzien (daar is geen ontkomen aan, als je deze functionaliteit wilt ondersteunen) maar slaat die dus nergens op, waardoor er ook geen jackpot op de server is. Zo houden de attack surface en de aantrekkelijkheid om Companion te hacken, zo klein/laag mogelijk.

Ik ben het helemaal met je eens dat we dit best even in het Engels, en wat gepolijst, in de Companion documentatie onder een kopje ‘Security’ zouden kunnen/moeten zetten.

[Reactie gewijzigd door kevinvz op 22 juli 2024 22:55]

[Rob Coops]

Ok dus eigenlijk is mijn AWS gebruiker niets anders dan het dropbox account dat jij beschrijft. En de token wordt inderdaad tussen client en companion op en neer gestuurd maar dankzij de extra encryptie laag is het, ook al kan iemand mee luisteren, nog steeds niet meteen een probleem omdat de decryptie sleutel alleen aan de companion kant bekend is.

Om te voorkomen dat Companion tokens moet opslaan wordt de token ge-encrypt en naar de client gestuurd zodat Companion deze kan vergeten, veiligheid wordt niet echt vergroot maar je hoeft een potentieel security risk zo als deze token niet op te slaan en kan hoeft dus ook geen geheugen of andere opslag te gebruiken.
Omdat de sessie data wel opgeslagen wordt en de key encrypted is waarschijnlijk met de session key en een salt of iets dergelijks zou opslaan van de key bij de session data het zelfde zijn als de key opslaan zonder encryptie dus ook van uit dat oogpunt is dit een elegantere oplossing ook al loop je dan wel weer de kans dat de encrypted key onderschept zal worden maar dankzij SSL wordt het een aanvaller moeilijk mogelijk gemaakt omdat als een acceptabel risico te beschouwen zo lang SSL nog als redelijk veilig gezien kan worden.

Een elegante oplossing, en erg handig zo'n kant en klare tool. Ondanks dat ik op het moment geen project kan heb om de tool te gebruiken (doe veel backend werk tegenwoordig) zal ik hier zeker gebruik van willen maken als ik weer eens met wat front-end spul mag spelen.

[dez11de]

APIs tussen de verschillende services en iets als oAuth2.

[Olaf van der Spek]

Het Nederlands-Duitse bedrijf

Wat is het business model?

[tedvg]

Je kúnt natuurlijk even op hun site kijken: https://transloadit.com/
En hun redenen om het open source te maken kun je hieruit afleiden: nieuws: Vimeo gaat 'resumable upload'-protocol van Nederlandse start-up gebru...
(alineatje 4)

Zo voldoende voor u opgediend?

[kevinvz]

Anders dan dat https://uppy.io/support/ doet vermoeden is paid-support voor Transloadit niet het business model achter Uppy. Het is slechts een poging om geen verlies op support te lijden. Veel bedrijven willen nu eenmaal support, het team is maar klein en zou geen ontwikkeltijd meer over houden. Gratis uitgebreide support voor iedereen is dus niet sustainable. Met paid-support kan er een support team groeien, naar mate de vraag ook groeit. We schreven iets meer over het daadwerkelijke verdienmodel op Hacker News:

We provide tus & uppy for free, hoping that a fraction of our open source communities will use our hosted versions (of companion and tus) and optionally our commercial encoding service because they work well together.

That could make our public coding efforts worthwhile financially. It’s a bit of a gamble. We’re believers/biased in part because we just enjoy working on oss, and in part because we’re quite a lean company and don’t need to make boatloads of money to make investors happy or anything (we’re bootstrapped since 2009, so no investors, and ramen profitable since 2012. Me and my cofounder are both devs and not in it to get yachts, but rather to have nice and rewarding work, basically)

Whether it really also becomes a financial success remains to be seen. 3y of devtime isn’t cheap so it'll be a bit sad if there is no ROI at all, but we'll comfort ourselves with the thought that we'll be able to provide a better and more reliable uploader to Transloadit's existing encoding customers (because going open has made these projects better thanks to exposure to more minds and environments), and making them very happy, even if there’s 100x more people that don’t make us money.

[Reactie gewijzigd door kevinvz op 22 juli 2024 22:55]

[hans3702]

Een blik op de bron / https://uppy.io site geeft je de volgende info:

There is also a different category of support that we like to call Integration Help: assistance to make things work for your environment, that have already been reported as working for the larger community.

• included with all Transloadit Plans, which start at $49/mo
• Enterprise addons, starting at $1499/mo

https://uppy.io/support/

[Reactie gewijzigd door hans3702 op 22 juli 2024 22:55]

[Terrestrial]

En wat is nu het grote voordeel hier van afgezien van een resumable upload?? Wat misschien handig bij slechte trage verbindingen maar verder echt totaal niet interessant.

[kevinvz]

Je zet het in als bouwer van websites waarbij uploaden van content een belangrijk onderdeel is. Dan wil je ook dat dat goed werkt voor bezoekers die een mindere verbinding hebben. Bijvoorbeeld een goedkope WiFi router, ze zitten op zolder, zijn onderweg, wonen in landelijke gebieden. Het beschermt ook tegen crashende tabjes of per ongeluk op de back button drukken. Dat overkomt iedereen wel eens en vooral bij grote bestanden kan het dan het verschil zijn tussen of zo'n bestand aankomt, of dat iemand gefrustreerd de tab helemaal sluit.

Het is lastig uitleggen zonder dat je het gezien hebt, maar er is wel een filmpje van opgenomen toen de technologie voor het eerst bedacht en getest werd: https://uppy.io/blog/2017/07/golden-retriever/

Buiten hervatbare uploads biedt het andere voordelen die op de homepage staan (https://uppy.io/), bijvoorbeeld:

Saves battery and data plan by letting users pick files from Webcam, Dropbox, Google Drive and Instagram, while letting servers do the heavy lifting

Maar als uploads weinig gebruikt worden op je site, of je kunt er van op aan dat iedereen een goede verbinding heeft, dan kun je natuurlijk de afweging maken gewoon een <input type="file"> te gebruiken. Niks mis mee, en het scheelt weer wat JavaScript Dat geeft Uppy overigens zelf ook aan in de FAQ.

[Reactie gewijzigd door kevinvz op 22 juli 2024 22:55]

[krazzer]

Wow! Dit is geweldig, ga ik zsm in mijn CMS integreren. @ACM ook wat voor Tweakers?

[djwice]

Ik vat nog even niet wat er geweldig aan is.
https://uppy.io/docs/aws-s3-multipart/

Waarom zou je niet gewoon direct een multipart-upload via een service worker gebruiken?

Of iets als deze link gebruiken http://www.resumablejs.com

[Reactie gewijzigd door djwice op 22 juli 2024 22:55]

[kevinvz]

Als het je alleen om resumable uploads te doen is, zou je tus-js-client kunnen overwegen, het voordeel ten opzichte van resumablejs is dan dat je een open protocol gebruikt waarvoor meer (server-side) implementaties beschikbaar zijn. Uppy biedt een grafische schil rondom Tus, en als extraatje dat het ook uploads kan hervatten na een browsercrash / per ongeluk weg navigeren. Dat bestond nog niet. Wat ook nieuw is is dat je bestanden van Dropbox kunt plukken zonder ze eerste naar je device te hoeven downloaden. Dat konden sommige betaalde uploaders al, maar open source bestond dit nog niet.

Of dat iets is wat je nodig hebt voor je app is de vraag, maar dit zijn de grootste vernieuwingen die Uppy brengt.

[djwice]

Thanks!

Ik denk bij nieuwe dingen altijd hoe zou het exploitable zijn, zodat maatregelen kan nemen om die exploits onmogelijk te maken.

Als ik kijk naar de go-lang server side die schtijft naar S3 en kijk naar serverless infrastructuur, dan lijkt het er op dat als de client besluit een file nooit te completeren - maar dit latent doet (dus niet actief in de sturingssoftware), dat de de server kant actief blijft.

Je moet dus zorgen dat een (gedistribueerde) overflow attack door incomplete uploads goed wordt opgevangen.

[Reactie gewijzigd door djwice op 22 juli 2024 22:55]

[kevinvz]

Ik hoop dat ik je goed heb begrepen! Ik geef wat achtergrond waarvan ik denk dat het aansluit op je zorg, laat het weten als ik de plank mis sla

Uppy kan naar verschillende backends uploaden:

- direct naar S3/GCS (S3 Plugin)
- naar je bestaande Apache/Nginx server (Xhr Plugin)
- naar een tus server (Tus Plugin) (Tus kan lokaal opslaan, of zelf weer naar S3 of Google Cloud wegschrijven)

In de gevallen dat je naar S3 schrijft doe je dat vaak door requests te signen met een private key. Dat doe je alleen voor clients die je vertrouwt, bijvoorbeeld: doordat ze ingelogd zijn, of een ander criterium dat voor jouw app belangrijk is. Alleen dan geeft je server een correcte signature aan de client, en wordt de opdracht geaccepteerd. Clients die je vertrouwd, zullen niet snel misbruik van de genoemde attack maken, en doen ze dat toch, dan zijn ze eenvoudig te bannen.

Uploads naar Tus servers kun je op dezelfde manier beveiligen, maar ook op tal van andere manieren. Sommige mensen zetten er een Proxy voor. Anderen kiezen ervoor om bijvoorbeeld een Tus PHP server te gebruiken, dan kunnen ze direct in de code van hun site uploads weigeren.

tusd bevat daarnaast ook methoden/aanbevelingen om incomplete bestanden op te schonen nadat er X uur geen wijzigingen zijn aangebracht. Normaal gesproken gebruik bij Tus namelijk een tijdelijke directory, en pas als de upload compleet is, triggert er een hook die hem voor je onder de juiste naam/map zet. De tijdelijke map wordt dan periodiek op oude files gecontroleerd en opgeschoond.

Als de zorg uitsluitend om Serverless is, dan zijn daar (naast alleen opdrachten van clients te accepteren die je vertrouwt) ook timeouts en maximum execution times in te stellen (alsmede dat bij AWS Lamda bijvoorbeeld, functies sowieso niet lang mogen draaien?)

[Reactie gewijzigd door kevinvz op 22 juli 2024 22:55]

[gertvdijk]

Voor als je ook de sources zoekt - GitHub: transloadit/uppy.

Reagerend op de inhoud van het nieuwsbericht

Nederlands-Duits bedrijf brengt opensourcebestandsuploader voor browsers uit

Dat project lijkt al geruime tijd te zijn uitgebracht, maar is er 25 april een 1.0 release geweest.

[Reactie gewijzigd door gertvdijk op 22 juli 2024 22:55]

[init6]

Voor veel media betekent 1.0 dat er dan pas iets uitgebracht is. Verder mooi product wat ze bij transloadit gebouwd hebben.

[CH4OS]

Een 1.0 release wordt door ontwikkelaars dan ook gezien als de eerste stable release. Dus dat betekend inderdaad ook de eerste officiële release.

[init6]

Niet geheel correct, het ligt aan de versioning die je aanhangt. Voer je semver in dan klopt je redenering. Ik heb echter versies van meerdere tools gedraaid die jaren onder de 0. zaten en als stable gemarkeerd waren.

[CH4OS]

Ik denk dat dat eerder een uitzondering op de regel is.

[bozotheclown]

Volgens hun website ondersteunen ze ook Safari op de Mac en iOS. Dit stukje vind ik niet heel erg nieuwswaardig persoonlijk maar de feiten, als je dan toch bezig bent ff compleet weergeven zou een aardig idee zijn.

[Orion64]

Handig als je in een gebied met een dun datalijntje wil rommelen met je data.

[kuurtjes]

Het belangrijke hier is dat de Tus protocol gebruikt wordt en dit de eerste integreerbare browser lib is die er op gebaseerd is.

De technologische "nieuwswaardigheid" staat gelijk aan WireGuard als je het mij vraagt. Het is een zeer interessant protocol.

[El_Frigo]

Als het gaat om ....

Other than that, picking files directly from your Instagram and Dropbox — without first passing through your mobile phone — can save a lot of bandwidth and battery life (uploads with Uppy and Companion happen server-to-server).

...
Klinkt het mij ook als een webbrowser based FXP protocol bovenop FTP. Dat werd/wordt ook gebruikt als server2server protocol juist om de bandbreedte van de "client"/"middle-man" niet leidend te laten zijn.

Dus ergens is het principe niet zo vernieuwend, maar wel voor de implementatie binnen een web-browser?

[kevinvz]

Het concept van Uppy’s Companion is inderdaad helemaal te vergelijken met FXP. Het werkt dan wel met HTTP, en oAuth (dus super voor een web omgeving), maar uiteindelijk geeft de client de opdracht, en servers onderling doen de data overdracht, net als bij FXP. Op die manier blijft je mobieltje buiten schot als je een filmpje van 4GB uit de Dropbox wil uploaden. Let the cloud figure it out : )

Tus daarentegen voorziet alleen in de hervatbaarheid van file uploads. Dus als dat 4GB filmpje toch op je mobieljte staat, en je loopt na 3.99GB uploaden even naar de kelder om een zak chips te pakken en je verbinding valt weg, blijft Tus gewoon proberen en verstuurt de laatste 10MB zodra de verbinding terug is, zodat je niet helemaal opnieuw hoeft te beginnen : )

[timmera99]

"Momenteel ondersteunt Uppy Chrome, Edge, Firefox, Opera, Safari en Internet Explorer".

Is dit niet een beetje voorbarig, niets te vinden nog bij Chrome en Firefox.

[mschol]

het betreft een door een webdeveloper te gebruiken/implementeren applicatie, geen download manager in een browser

[MrMonkE]

Ik ga alvast wat opensourcebestanden zoeken om te uploaden.