Nieuwe javascript-functies maken lokale file-access mogelijk

Het W3C heeft een draft gepubliceerd die javascript-ontwikkelaars de mogelijkheid moet geven om beperkte toegang te verkrijgen tot files op het lokale bestandssysteem. Hier moeten vooral webapplicaties van profiteren.

De nieuwe draft over de File-api, opgesteld door de bij Mozilla werkzame Arun Ranganathan, is door het W3C voorgedragen in de hoop dat de nieuwe functies uitgroeien tot een nieuwe open standaard. De functies zijn al deels in de laatste nightly builds van Firefox verwerkt.

De api introduceert onder andere het nieuwe commando FileReader, waarmee bestanden op het lokale bestandssysteem uitgelezen kunnen worden. Met FileReader kunnen zowel binaire als ascii-bestanden benaderd worden en zijn er diverse event handlers beschikbaar. Deze handlers kunnen onder andere aangeven of het inladen van een bestand al dan niet is geslaagd. Met de javascript-commando's moet het voor webapplicaties mogelijk worden om op clientniveau - de webbrowser van de eindgebruiker - operaties op lokale bestanden uit te voeren. Hierdoor is er minder dataverkeer met de server nodig en kunnen webapps soepeler draaien.

Om te voorkomen dat willekeurige bestanden benaderd worden met de File-api, kunnen alleen files gemanipuleerd worden die door de gebruiker expliciet met het file-input-element zijn geselecteerd, veelal via een webformulier. Scripts kunnen de bestandsnaam of -namen uitlezen via het dom en deze vervolgens via het FileReader-commando benaderen.

Reacties (104)

[Verwijderd]

Ik schrik een beetje van het gebrek aan kennis bij veel, met name toch technisch aangelegde mensen mag je aannemen in de comments die ik hier lees.

Deze zelfde techniek zit al een tijdje in elke browser waar flashplayer 10 op geinstalleerd is, en dat zijn er nogal wat.

FlashPlayer 10 doet exact hetzelfde met de filereference class. Zodra een gebruiker een bestand kiest (en dat kan dus niet met een script die dat veld voor jou invult, nu niet, nooit niet) dan geeft de gebruiker expliciet met eigen ogen op een bestand op zijn systeem de rechten aan de browser om dat bestand te mogen lezen. Niet meer niet minder.

Met name voor RIA's is dit enorm handig en daar zijn legio toepassingen voor te bedenken waar dit goed voor te gebruiken is. Bijvoorbeeld een plaatje uploaden, maar die moet eerst nog even gecropped en resized worden. De gebruiker kan dan gewoon dat plaatje van 3 mb van z'n digitale camera selecteren en zonder tussenkomst van een server kan dat plaatje gebruikt worden in de browser om te bewerken, te resizen en dan pas het eind resultaat naar de server te sturen. Scheelt tijd, bandbreedte en vergroot het gebruikers gemak.

Ik zie het probleem niet, want het bestaat allang en is niet zomaar (of beter gezegd, niet) te misbruiken.

[wildhagen]

Lijkt me een gigantisch veiligheidsrisico.

Fijn dat de gebruiker het kan aangeven, maar ik denk niet dat de gemiddelde (niet-tweaker) gebruiker weet of een file of niet vertrouwd is om op deze manier beschikbaar te stellen, en gewoon maar op 'OK' (oid) klikt, als het hem gevraagd word.

Om het over eventuele bugs in deze API maar niet te hebben, waardoor men misschien toch zonder toestemming allerlei files kan benaderen...

[Little Penguin]

Lijkt me een gigantisch veiligheidsrisico

Volgens mij moet de gebruiker wel eerst één of meerdere bestanden selecten en daarna kan de JavaScript code hier iets mee gaan doen - maar dan alleen uitlezen. Ik zie niet in wat het extra veiligheidsrisico hier is.

Zeker als je bedenkt dat het voor een site nu ook al mogelijk is om de gebruiker lokaal bestanden te laten kiezen, alleen moet deze dan eerst geupload worden naar de server. Zodra het bestand geupload is, dan kan er nu pas wat mee gedaan worden.

Wat is het verschil tussen deze API en een form-upload voor de gebruiker? Volgens mij heeft de gemiddelde gebruiker niet door of een bestand lokaal verwerkt wordt door JavaScript of eerst geupload wordt. Als men met de nieuwe API rucksichloos bestanden gaat selecteren, dan zou men dat met de bestaande mogelijkheden ook al gaan doen.

Om het over eventuele bugs in deze API maar niet te hebben, waardoor men misschien toch zonder toestemming allerlei files kan benaderen...

Het probleem van bugs, dat hebben we nu ook al. Op dat punt is er dus weinig verschil, behalve dan dat deze bestanden lokaal verwerkt kunnen worden...

Wat is het extra risico van deze API t.o.v. de MS-ActiveX API van MSIE? Via ActiveX kun je een compleet systeem overnemen en als daar een lek in zit heb je zo een virus te pakken (de meeste zijn er inmiddels wel uit, maar MSIE6 op Win98 was anders zo lek als een mandje). Als er al lekken in deze API/implementatie zitten, dan heeft men alleen nog maar toegang tot de lokale bestanden, dat is erg vervelend en mogelijk zelfs een groot privacy-gevaar, maar minder erg als een lek in ActiveX.

[SirBlade]

"Select your outlook pst-file to check for errors online"
<gebruiker selecteer pst file>
<computer druk bezig>
<computer stuur contacts naar spammer>
"No errors found"

Ok, het kon voorheen ook, maar dan moest je eerst een 500MB pst file uploaden, de contacts op de pc van de gebruiker verwerken is een stuk sneller.

[Little Penguin]

Alleen weet de gebruiker niet waar dit bestand opgeslagen is, volgens mij is het zelfs knap lastig om in een standaard configuratie van MS-Windows bij de MSOutlook pst-file te komen (ook bij Mozilla Thunderbird's bestanden kom je niet zomaar).

Naar mijn idee ben je spijkers op laag water aan het zoeken.

Op het moment dat men e-mail adressen wil hebben kan men veel gemakkelijker een Trojan oid laten installeren door een beperkte groep gebruikers - aangezien de meesten via CC ipv BCC allerlei onzin-mails versturen hoef je, in verhouding, maar een paar computers leeg te hengelen om aan voldoende adressen te komen...

[Wim-Bart]

Helemaal niet lastig om te vinden, je geeft gewoon %appdata%\Microsoft\Outlook\%username%.pst mee als argument en het werkt :-)

[dragontje124]

je kan dus geen argumenten meegeven, das nou juist het mooie: de gebruiker moet alles zelf doen , wat nu dus eigenlijk ook al kan.

[mieJas]

Wat als je HTML-pagina een "verborgen" textbox heeft en er voor het gemak "C:\Users\" in staat. Je kan toch niet controleren uit welk veld die JS z'n effectieve pad haalt?

[R4gnax]

Het moet persé een file input box zijn (niet een gewone textbox) en file input boxes zijn niet voor te configureren met een waarde.

[Soultaker]

Ik denk dat het meevalt, omdat het alleen gaat om het benaderen van bestanden die al in een file form input box geselecteerd zijn. Je kunt nu al vanuit JavaScript een formulier submitten en dan wordt dat bestand naar de server gestuurd, wat net zo goed een veiligheidsrisico is.

Het enige verschil is dat je er met de nieuwe functionaliteit ook client-side bij kunt, waardoor het dus niet nodig is om het bestand eerst naar de server te sturen en dan weer terug naar de client.

Om het over eventuele bugs in deze API maar niet te hebben, waardoor men misschien toch zonder toestemming allerlei files kan benaderen...

Dat geldt natuurlijk net zo goed voor file input boxes. Die werden ook niet altijd zinnig geïmplementeerd (in sommige gevallen kun je vanuit JavaScript het pad aanpassen bijvoorbeeld), maar inmiddels is men zich van die risico's bewust. Deze toevoeging maakt dan weinig verschil.

Ik kan me voorstellen dat je (vanuit beveiligingsoogpunt) het benaderen van lokale bestanden helemaal zou wil voorkomen, maar dan moet je zowel die FileReader als de de file input boxes uitzetten. Met één van de twee schiet je weinig op.

[Reactie gewijzigd door Soultaker op 24 juli 2024 08:59]

[ZpAz]

Je begrijpt het conept volgens mij niet helemaal.

Momenteel is het enkel mogelijk om een file up te loaden door een html formulier. (Als in, een gebruiker kiest het bestand wat hij wil uploaden.)

Nu kan je ipv enkel het formulier uploaden, het betreffende bestand als met JS uitlezen. Voor de gebruiker veranderd er dus niets. Elk bestand wat ze anders zouden uploaden kan dus nu eerst met JS uitgelezen worden.

Wat wel erg fijn is, het is namelijk een beetje onnozel om eerst een compleet bestand up te moeten loaden alvorens je bijvoorbeeld de extensie kan controleren.

[hackerhater]

Niet alleen extensie, maar mime-type en bestandsgrootte controleren is ook wel fijn
Al blijft server-side controle nog altijd nodig

[bzerk]

joho, dit is een hele coole website!!!
Klik op OK om toegang te krijgen

(hele kleine lettertjes):
o ja, je zet hiermee ook c:\winnt\system.dat open

[dragontje124]

zo gaat dat dus niet werken en dat begrijp jij ook wel

het gaat gewoon hetzelfde werken als nu,dmv een HTML formulier alleen hoef je nu niet het hele bestand up te loaden om het bijvoorbeeld door de gebruiker zelf te laten bewerken (Google Docs enzo)

[acemoo]

Dus je maakt een veldje <input name='hax' type="file" /> + een scriptje<script> name.value = 'c:\winnt\system.dat'</script>

En dit zet je in het zelfde formulier als wat bzerk zei, en ze hebben toegang.

Ok dit zal waarschijnlijk niet zo makkelijk werken en wel redelijk beschermd worden, maar ik ben bang dat er toch een fout zal komen in browser X waardoor het toch een golf van malware zal veroorzaken.

[pat42]

De values van file upload forms zijn niet met JavaScript in te stellen, dat kan simpelweg niet. Nu niet, en in de toekomst ook niet (tenminste, als browsermakers een beetje nadenken, maar dit is té obvious om te vergeten).

[--Andre--]

Was dit niet te omzeilen? Ik herinner me een scriptje waarbij je een tekst moest overtypen. De actie typen werdt gezien als user input. Het script nam alleen bepaalde tekens over. Hierdoor ontstond een filename, die vervolgens kon worden geüpload

[hackerhater]

was dat geen bug?
Als het goed is is het onmogelijk om het pad in de file-upload boxes aan te passen vanuit een script
Juist om zoiets te voorkomen

[Verwijderd]

Dus als je je eigen browser maakt zou het wel moeten kunnen?

[user109731]

Dus als je je eigen browser maakt zou het wel moeten kunnen?

Zeker. Of met een patch voor Firefox of Chrome. Je kunt eenvoudig een browser maken die heel je harde schijf upload naar een website. Probleem is dat niemand zo'n browser wil gebruiken

[Kazu]

Ja, alleen staat daar weer tegenover dat die browser dan algemeen geaccepteerd en gebruikt zou moeten worden.

[dragontje124]

als je nu een eigen browser maakt kan je daar ook zo veel lekken in maken als je zelf wil.

[Gammro]

Gaat dat niet ervoor zorgen dat er een boel Java based virussen komen die worden geactiveerd als je ook maar de pagina opkomt?
Ik mag hopen dat hiervoor een beveiliging is ingebouwd...

[Verwijderd]

Of de beveiliging werkt hangt af van de implementatie. W3C geeft alleen een draft waarin de specificaties staan. Javascript engines hebben dus hun eigen implementatie en het is maar afwachten of nergens gaten in zitten.

Ik vraag me af of je dit moet willen. Caching is de taak van de browser en webserver, en cookies ondersteunen sessies al. Waar ik vooral bang voor ben is dat je straks, net als met lokale applicaties, afhankelijk bent van je lokale opslag. Het mooie van webapplicaties is juist dat je overal bij je gegevens kunt en niet afhankelijk bent van een harde schijf.

Aan de andere kant zit er wel wat in om bestanden van de harde schijf te kunnen openen, bewerken en op te slaan. Een online tekstverwerker (bijv Google Docs) kan dan zonder een bestand te downloaden je documenten doorzoeken en opslaan. Maargoed, dat gaat natuurlijk een keer fout.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 08:59]

[Little Penguin]

Waar ik vooral bang voor ben is dat je straks, net als met lokale applicaties, afhankelijk bent van je lokale opslag. Het mooie van webapplicaties is juist dat je overal bij je gegevens kunt en niet afhankelijk bent van een harde schijf.

Dat is ook gelijk het nadeel, op het moment dat MSN/Hotmail of Google Documents offline is kun je niet bij je e-mail of je documenten.

Verder is deze API nog niet bedoeld voor het opslaan van bestanden, je kunt er vooralsnog alleen mee lezen...

[poepkop]

Verder is deze API nog niet bedoeld voor het opslaan van bestanden, je kunt er vooralsnog alleen mee lezen...
Eigenlijk @ negerzoen: En waarom zou een webapplicatie dat niet mogen en een .exe wel? Uiteindelijk is de ontwikkelaar van de browser er verantwoordelijk voor om toestemming te vragen aan de gebruiker of een validatie toe te paseen, net als bij SSL certificaten. Zodat jij net als bij een .exe akkoord moet gaan met de voorwaarden en bewust iets toegang geeft tot je systeem?

[Reactie gewijzigd door poepkop op 24 juli 2024 08:59]

[cdwave]

En waarom zou een webapplicatie dat niet mogen en een .exe wel?

Omdat een webapplicatie niet op jouw PC draait maar op de webserver, en een .exe wel op jouw PC draait en niet op de server. Bijvoorbeeld.

[Verwijderd]

Een webapplicatie draait niet per definitie op de PC of de Server, dat hangt af van de taal waarin het geschreven is. Javascript wordt aan de kant van de gebruiker, op zijn pc, uitgevoerd/geinterpreteerd. (Clientside)

Dus ik zie ook niet in waarom een .exe wel toegang heeft tot locale bestanden een clientside taal zoals bv javascript niet.

Qua beveiliging kun je wel zeggen dat er een risico zit als een (toevallig geladen) webapp toegang kan hebben tot al je bestanden. Maar daar is genoeg op te bedenken, en die browser-devs zijn ook niet achterlijk.

Ik kan deze file api in iedergeval erg goed gebruiken. Nu upload ik een bestand als ik via "magic numbers" wil weten wat voor soort bestand het is. Straks kan ik dit aan de kant van de gebruiker doen, scheeld erg veel bandbreedte.

Het heeft dus echt praktische voordelen!

[dragontje124]

lees:
"Om te voorkomen dat willekeurige bestanden benaderd worden met de File-api, kunnen alleen files gemanipuleerd worden die door de gebruiker expliciet met het file-input-element zijn geselecteerd, veelal via een webformulier. Scripts kunnen de bestandsnaam of -namen uitlezen via de dom en deze vervolgens via het FileReader-commando benaderen."

oftwel: eigenlijk hetzelfde als: bestandje selecteren->uploaden->uitlezen alleen dan client side alleen sneller, want er is geen tijd nodig om het bestand te uploaden
btw: java is iets anders dan javascript

[Reactie gewijzigd door dragontje124 op 24 juli 2024 08:59]

[SuperDre]

Klopt dat ze dat zeggen dat veelal via een webformulier.. maaruh, dat is dan natuurlijk ook wel te simuleren....

[OddesE]

Nee, want je kan de waarde van een file input niet zetten vanuit javascript, alleen uitlezen. Dit is nu al zo, anders zou je al een lek hebben.

Ik vind dat ze dit wel goed bedacht hebben. Mooi spul, nu nog wachten totdat IE het ook ondersteunt.

[poepkop]

nu nog wachten totdat IE het ook ondersteunt.
Kan je lang wachten... Maar waarom zou je wachten, als je het nu, al met de nightly builds kan hebben

Dit is ideaal voor een webdeveloper, geen java-meuk. Het biedt hele mooie functies, lees: http://dev.w3.org/2006/webapi/FileAPI/#filereader-interface

[DexterDee]

Kan je lang wachten... Maar waarom zou je wachten, als je het nu, al met de nightly builds kan hebben

Misschien omdat je die website niet voor jezelf maar voor de rest van de wereld maakt

[ktf]

Het zou mooi zijn als het dan eindelijk ook eens mogelijk wordt meerdere bestanden uit 1 map in 1x te selecteren. Als je nu een rits fotos wil uploaden duurt dat een eeuwigheid om alles te selecteren, als je dat met formulier-upload doet tenminste

[Little Penguin]

Het zou mooi zijn als het dan eindelijk ook eens mogelijk wordt meerdere bestanden uit 1 map in 1x te selecteren.

Binnen HTML5 wordt er al gewerkt aan een optie om meerdere bestanden te kunnen selecteren voor de File Upload.

Deze specificatie gaat echter vooral over de toegang van JavaScript tot door de gebruiker gekozen bestand(en)...

[cdwave]

Een van de stokoude HTML specs stond multiple files al toe, maar zowel servers als browsers maakten er een potje van en toen is de feature een stille dood gestorven.

Aangezien dit een nuttige functie zou zijn waar veel eindgebruikers al jaren op wachten, zal dit wel nooit in de standaard komen.

[xoniq]

Ik hoop wel dat het terug komt.
Zou wel gewoon ontzettend handig zijn.
Hoef je ook geen vage omweg te doen met Flash e/of JAVA.

[Andr01d]

Bij Gmail kan dat.. of werkt dat niet met JS?

[Verwijderd]

Een deel JS maar die praat met een flash applicatie.

[CH4OS]

GMail kan niet met JS in je bestanden kijken, zoals te lezen is, zul je het bestand moeten selecteren via een file-input-element op de webpagina <input type="file" name="foobar" /> voor de kenners.

Als je bedoeld dat GMail ziet wat voor bijlagen je hebt, dat komt omdat de files server side staan, niet lokaal.

[Cloud]

Nee wat hij bedoelt is dat je bij GMail meerdere files in één keer kunt attachen.

[Zer0]

Gmail maakt oa. gebruik van Gears http://en.wikipedia.org/wiki/Gears_(software)

[PegOpDeWeg]

Multiple file upload (shift+click of ctrl+click selecties) kan al heel lang met java applets of sinds een paar jaar met Adobe flash. De server site heeft niets anders dan een simpel upload script nodig in php/asp/.net etc.

[Emunator]

Scripts kunnen de bestandsnaam of -namen uitlezen via de dom en deze vervolgens via het FileReader-commando benaderen.

Dit gaat mij al te ver, wat als mijn bestand "Ik mag het koningshuis niet.doc" heet ?

[DiLDoG]

Uhm je moet dat bestand nog steeds zelf selecteren (met die mooie browse knop ernaast) dus ik zie niet helemaal waarom je wel eerst dat bestand zou selecteren om hem vervolgens níet up te loaden omdat t zo geheim is.

[Little Penguin]

Het gaat hierbij niet om Java, maar om JavaScript/DOM. Verder is het zo dat je zelf nog een bestand moet selecteren of juist op een bepaalde gebied moet laten vallen voor dat het bestand voor de site beschikbaar is.

Qua beveiliging is deze hetzelfde als de rest van de JavaScript/forms afhandeling.

Zonder een actie van de gebruiker gebeurt er niets. Uit de specificaties kan ik verder geen functionaliteit opmaken die aangeeft dat er bestanden geschreven kunnen worden, dat is gelijk de beveiliging tegen "virussen" - waar jij dus zo bang voor bent.

[jbtbnl]

Ter verduidelijking: met "DOM" geeft Little Penguin niet de mentale staat van de poster Gammro aan; hij of zij refereert naar het Document Object Model.
http://en.wikipedia.org/wiki/Document_Object_Model

[Verwijderd]

Nog meer verduidelijking (van http://en.wikipedia.org/wiki/JavaScript):

JavaScript was originally developed by Brendan Eich of Netscape under the name Mocha, which was later renamed to LiveScript, and finally to JavaScript.
The change of name from LiveScript to JavaScript roughly coincided with Netscape adding support for Java technology in its Netscape Navigator web browser. JavaScript was first introduced and deployed in the Netscape browser version 2.0B3 in December 1995.
The naming has caused confusion, giving the impression that the language is a spin-off of Java, and it has been characterized by many as a marketing ploy by Netscape to give JavaScript the cachet of what was then the hot new web-programming language.

Dus eigenlijk is de verwarring aan Netscape te wijten...

[g4wx3]

JAVASCRIPT


BTW, Jscript/vbscript van microsoft kan het al een tijdje, via activeX ...

[Reactie gewijzigd door g4wx3 op 24 juli 2024 08:59]

[driekske]

en javascript kan het ook al een tijdje, via java... duh.

[Verwijderd]

ActiveX moet je eerst weer activeren via het balkje wat je toegeschoven krijgt (top, onder je adresbalk).

Bij deze nieuwe functies kan je dus selecteren of je dit wilt en niet eerst andere handelingen doen voordat je het daadwerkelijk kan uitvoeren..
Deze nieuwe functies in javascript zijn dus gebruiksvriendelijker dan ActiveX.

Zowiezo vind ik ActiveX niks, maar dat is mijn mening maar.

[veldmuis]

Ze doen wel hun best het te voorkomen, maar de kans dat daar weer een lek in gevonden wordt lijkt me wel aanwezig.

BTW: Java is geen javascript, verre van zelfs.

[jj71]

Nee, want JavaScript is geen Java. Dit heeft helemaal niets met Java te maken.

[Radhe]

Grappig dat er nog altijd mensen zijn die de fout maken Java met JavaScript te vergelijken. In syntax hebben ze wat van elkaar weg, maar deep-down zijn het echt twee gescheiden werelden.

[Verwijderd]

Ohnee, moet dit nou, geef web applicaties alsjeblieft niet nog een manier om lokaal dingen op te slaan. We hebben al:

1) Cookies
2) Flash persistent local object
3) IE/VBScript lokale opslag

Alle drie worden al gebruikt om gebruikers te volgen, en het is al onoverzichtelijk genoeg hoe je nou precies je "cookies" weggooit zodat je alle zooi kwijt bent. Voor een leek is het al onmogelijk.

[dragontje124]

wie heeft het hier over opslaan?
Het gaat om lezen.
de gebruiker (en ook alleen de gebruiker) kan een bestand selecteren dat ie wil laten lezen. Dit kan dus client-side gelezen worden ipv dat het eerst geupload moet worden (het kan dus inderdaad nu ook al maar dan moet alles geupload worden dmv een html formuliertje)

[mschol]

het klinkt aardig maar ik vind het een veel te gevaarlijke functie..
je moet bestanden opgeven die bewerkt mogen worden... daar kan ook makkelijk misbruik van gemaakt worden denk ik

[SPee]

Inderdaad. Is een vooringevulde tag al niet mogelijk?
Of voorinvullen/-selecteren via javascript?

[Ventieldopje]

Niet bij het <input type="file" /> element, daarbij kun je bij de meeste browsers geen vooraf ingestelde waarde meegeven met 'value'.

Maar nou zat ik ff rond te snuffelen en ik kwam een script tegen dat een bestand opent met javascript op je schijf (nog met de auto methode) en vervolgens een request maakt naar de server om te uploaden, tada komt geen input veld aan te pas

http://www.captain.at/ajax-file-upload.php .. ik kan het fout hebben maar ehh, lijkt me toch een serieus probleem te vormen en nog cross-platform ook

[Little Penguin]

http://www.captain.at/ajax-file-upload.php .. ik kan het fout hebben maar ehh, lijkt me toch een serieus probleem te vormen en nog cross-platform ook

Het mag dan wel cross-platform zijn, het werkt alleen op Mozilla-based browsers en dus niet op MSIE, Opera, Chrome of Safari.

Verder moet je hiervoor nog wel een setting aanpassen (about:config), dat zie ik een normale gebruiker niet direct doen en is het ook nog eens zo dat je dan een flink veiligheidslek genereerd.

Niet direct een optie voor een normale website/web-applicatie...

[Ventieldopje]

In dit voorbeeld maken ze ook gebruik van de oude manier van toegang tot bestanden krijgen en daar doel ik ook niet zo zeer op, wat ik bedoel is dat je met de nieuwe functie die ze dus introduceren in het nieuwe draft dat je dus simpel een bestand kan openen met javascript en die kan uploaden met een AJAX request, ik heb daar namelijk nog nooit confirmatie dialogen voor gezien

[user109731]

Daarvoor moet je expliciet een hidden setting in Firefox aanzetten. Vervolgens moet je de website nog toestemming geven. No way dat een website automatisch bestanden kan uploaden (zonder plugins zoals ActiveX in IE).

[user109731]

Het is in principe gewoon een uitbreiding op de file upload control. Het is al jaren mogelijk om bestanden te uploaden, het enige dat nu veranderd is dat diezelfde data nu naar een script gestuurd wordt.

Dus nee, voorinvullen via Javascript is niet mogelijk; anders zou iedere malafide website nu al bestanden kunnen uploaden

[Reactie gewijzigd door user109731 op 24 juli 2024 08:59]

[Little Penguin]

Voor zover ik de bestaande API doorgelezen heb, is het alleen mogelijk om bestanden te lezen en is het niet mogelijk om bestanden te bewerken of weg te schrijven...

Pas als er ook geschreven kan worden ontstaat er een significant risico dat verkeerde bestanden bewerkt gaan worden. Misschien dat een latere API dit mogelijk maakt, maar deze in elk geval nog niet.

[Ventieldopje]

Lezen vind ik al erg genoeg, schrijven zullen ze ook niet snel doen omdat dat opvalt en lezen valt vaak niet op

[stifmeizter]

Aangezien bestanden lokaal gemanipuleerd kunnen worden lijkt me dit geen beveiligingsrisico. Aangezien in de webapplicatie expliciet aangegeven kan worden om wat voor bestand het moet gaan is dit natuurlijk vrij goed afgebakend.

Geweldige toevoeging voor het uploaden van grotere bestanden, aangezien deze lokaal dan opgesplitst kunnen zonder een gebruiker daarmee hoeven lastig te vallen!

[ApexAlpha]

Chrome OS gebaseerd op webapps komt uit en W3C steunt het meteen door deze java script code / functie te ontwikkelen. Google sponsort W3C, niet?

Gewoon mijn eerste gedachte

Verder lijkt het mij wel een security risk als sommige sites dit vragen, als dit door middel van een pop-up gebruikt drukt sowieso iedere vista gebruiker instinctief op 'ja'

[Reactie gewijzigd door ApexAlpha op 24 juli 2024 08:59]

[Little Penguin]

Chrome OS gebaseerd op webapps komt uit en W3C steunt het meteen door deze java script code / functie te ontwikkelen. Google sponsort W3C, niet?

Deze specificatie is iets wat men niet direct nodig heeft voor ChromeOS, volgens mij is het zelfs zo dat jij in ChromeOS helemaal geen enkel bestand offline hebt staan.

Verder is deze specificatie gemaakt door een Mozilla-medewerker, dit heeft dus niets met Google of ChromeOS te maken.

Verder lijkt het mij wel een security risk als sommige sites dit vragen, als dit door middel van een pop-up gebruikt drukt sowieso iedere vista gebruiker instinctief op 'ja'

Je moet eerst een bestand selecteren, als je direct op 'Ja' of 'OK' klikt is er geen bestand geselecteerd -> geen bestan in JavaScript aanwezig.

offtopic:
Jouw opmerking geeft gelijk de zwakte van UAC. Als je de software zo opzet dat je als normale gebruiker werkt en een wachtwoord nodig hebt voor ingrijpende dingen zou zo'n instintc niet ontstaan...

[Verwijderd]

volgens mij is het zelfs zo dat jij in ChromeOS helemaal geen enkel bestand offline hebt staan.
En je cache dan?
lol

Dan moet je al een serieuze verbinding hebben om vlot te werken.

[Little Penguin]

Wat ik bedoel, dat is dat de gebruiker zelf lokaal niets op kan slaan. Dat de Google Chrome browser dingen lokaal opslaat/cached dat is logisch...

Maar deze File API is om lokaal bestanden te benaderen, maar als je geen bestanden hebt om t benaderen...

[user109731]

Chrome OS gebaseerd op webapps komt uit en W3C steunt het meteen door deze java script code / functie te ontwikkelen. Google sponsort W3C, niet?

Nee, deze standaard is voorgesteld door Mozilla (de laatste nightly builds van Firefox ondersteunen het al). Ieder bedrijf kan zoiets voorstellen. Natuurlijk kan Google dit ook goed gebruiken voor Chrome (OS), maar zij zitten hier dus niet achter

Verder lijkt het mij wel een security risk als sommige sites dit vragen, als dit door middel van een pop-up gebruikt drukt sowieso iedere vista gebruiker instinctief op 'ja'

Het werkt zoals een file-upload dialog. De gebruiker moet dus bewust het bestand selecteren.

[Reactie gewijzigd door user109731 op 24 juli 2024 08:59]

[onok]

Op zich kon dit allemaal al, maar niet met javascript. Voorheen had je hier bijvoorbeeld flash voor nodig. Het maakt het allemaal net wat makkelijker voor zowel de ontwikkelaar als de eindgebruiker. Ik hoop dat er ook een file-input komt waarmee je meerdere bestanden tegelijk kunt selecteren. Dit moet tot nu toe ook helaas met flash. Weet iemand hier iets meer van?

[user109731]

Ik hoop dat er ook een file-input komt waarmee je meerdere bestanden tegelijk kunt selecteren. Dit moet tot nu toe ook helaas met flash. Weet iemand hier iets meer van?

Ja, goed nieuws: HTML5 ondersteunt het uploaden van meerdere files (multiple="true"). Webkit (Chrome en Safari) en de beta van Firefox 3.6 ondersteunen dit al. Zie hier voor meer informatie.

[Reactie gewijzigd door user109731 op 24 juli 2024 08:59]

[Little Penguin]

Ik hoop dat er ook een file-input komt waarmee je meerdere bestanden tegelijk kunt selecteren.

De mogelijkheid om in één selectieveld meerdere bestanden te kunnen selecteren en uploaden is onderdeel van HTML5.

Zie ook: http://www.whatwg.org/spe...k/#the-multiple-attribute
(N.B. omvangrijke pagina, laden/renderen kan even duren)

[Remcoder]

Dit gaat geheid problemen opleveren.

Neem het volgende scenario:

Gebruiker bezoekt website met deze javascript functie, javascript vraagt gebruiker om zijn SAM bestand te uploaden. Website heeft dan ip en SAM bestand, dit valt uit te lezen waarna de wachtwoorden en gebruikers voor dat systeem bekend zijn.

Progje maakt verbinding met pc en identificeert zich als gebruiker, kan spyware/virus installeren en klaar, weer een pc voor aan het botnet toe te voegen.

Nee, laat dit er maar uit.

[user109731]

Gebruiker bezoekt website met deze javascript functie, javascript vraagt gebruiker om zijn SAM bestand te uploaden. Website heeft dan ip en SAM bestand, dit valt uit te lezen waarna de wachtwoorden en gebruikers voor dat systeem bekend zijn.

Sorry, maar dit kan al jaren met een normale file upload dialog? Het enige verschil is dat je nu client-side met Javascript het bestand kunt inzien, maar uploaden kan al jaren.

[Little Penguin]

Gebruiker bezoekt website met deze javascript functie, javascript vraagt gebruiker om zijn SAM bestand te uploaden. Website heeft dan ip en SAM bestand, dit valt uit te lezen waarna de wachtwoorden en gebruikers voor dat systeem bekend zijn.

Progje maakt verbinding met pc en identificeert zich als gebruiker, kan spyware/virus installeren en klaar, weer een pc voor aan het botnet toe te voegen.

Deze optie is nu ook al aanwezig, ook nu kun je al bestanden uploaden via het input-type "file" van de HTML-forms.

Als men dit soort zaken zou willen doen, dan kan men dit nu ook al doen. Voor zover ik weet is dat echter niet het geval, de virussen hebben tot op heden van andere lekken gebruik gemaakt om een computer over te nemen.

Als het SAM-bestand ongecodeerde wachtwoorden (of slecht gecodeerde ww) bevat, dan is dat een ontwerpfout van het OS. Een goed OS (en eigenlijk ieder goed programma) zal nooit een ongecodeerd wachtwoord opslaan. Men zal altijd hashen in combinatie met en salt...

Verder zijn er weinig systemen die direct aan het internet hangen, bij de meeste zit er een router tussen die dit soort pogingen snel neutraliseert...

[Verwijderd]

Yahoo! heeft zoiets al geimplementeerd bij hun Mail service m.b.t. de bijlages.

[Little Penguin]

Maakt dat echter geen gebruik van Flash om dit te bereiken? Deze API wordt namelijk nog niet door productie-browsers ondersteund...

[eborn]

De voorgestelde API voor de browsers is inderdaad vergelijkbaar in wat Flash momenteel al toestaan: bestanden die geselecteerd worden via een File->Open popup zijn vanuit Flash (deels) te benaderen.

[RM-rf]

HTML5 zelf kent al de database interface welke voor web-applicaties veel machtiger is en nuttiger
http://dev.w3.org/html5/webdatabase/

wat dat betreft hoop ik niet dat deze functionaliteit al te makkelijk misbruikt wordt door ontwikkelaars voor iterne data, maar voor bv het door de gebruiker laten wegschrijven van gegenereerde documenten kan het natuurlijk wel handig zijn

[Little Penguin]

HTML5 zelf kent al de database interface welke voor web-applicaties veel machtiger is en nuttiger

Op het moment dat je echter iets met een lokaal bestand wil doen, dan zul je toch een manier moeten hebben om dit bestand in de JavaScript omgeving te krijgen. Dat kan dan dus met deze File-API.

Echt belangrijke data kun je beter in een dedicated database (Oracle RDBMS, Firebird SQL, Postgres, MySQL et al) opslaan via de web-applicatie.

wat dat betreft hoop ik niet dat deze functionaliteit al te makkelijk misbruikt wordt door ontwikkelaars voor iterne data,

Ook nu al kan men via Flash redelijk veel informatie opslaan en in de DB API is gespecificeerd dat de browsers een quotum per site 'moeten' implementeren.