Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Nieuws » Pro » Development » Standaarden » Nieuwe javascript-functies maken lokale file-access mogelijk

Nieuwe javascript-functies maken lokale file-access mogelijk

Door Dimitri Reijerman, donderdag 26 november 2009 18:20, views: 25.221

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.

Volgende 23:31 Tweakers.net uitgeroepen tot Website van het Jaar 2009
Vorige 17:20 LG komt in 2010 uit met PK-plasmaserie
Advertentie

Gerelateerde content

Gerelateerde jobs

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 104 reacties zichtbaar1040 Off-topic / Irrelevant: 104 reacties zichtbaar104+1 On-topic: 74 reacties zichtbaar74+2 Informatief: 6 reacties zichtbaar6+3 Spotlight: 0 reacties zichtbaar0
«  1  2  3  »

Door Gammro, donderdag 26 november 2009 18:23

Score: 1
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...

Door dragontje124, donderdag 26 november 2009 18:27

Score: 1
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 donderdag 26 november 2009 18:31]

Door ktf, donderdag 26 november 2009 18:50

Score: 1
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

Door Little Penguin, donderdag 26 november 2009 18:52

Score: 1
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)...

Door Andr01d, donderdag 26 november 2009 19:27

Score: 0
Bij Gmail kan dat.. of werkt dat niet met JS?

Door cyf3r, donderdag 26 november 2009 19:32

Score: 1
Een deel JS maar die praat met een flash applicatie.

Door CptChaos, donderdag 26 november 2009 22:33

Score: 0
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. ;)

Door Cloud, donderdag 26 november 2009 23:48

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

Door PegOpDeWeg, vrijdag 27 november 2009 11:28

Score: 0
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.

Door cdwave, vrijdag 27 november 2009 08:36

Score: 1
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.

Door CRXDelSol, vrijdag 27 november 2009 11:39

Score: 0
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.

Door SuperDre, donderdag 26 november 2009 21:25

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

Door OddesE, donderdag 26 november 2009 23:57

Score: 1
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.

Door poepkop, vrijdag 27 november 2009 01:12

Score: 1
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 :*)

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

Door DexterDee, vrijdag 27 november 2009 05:25

Score: 2
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 ;)

Door Emunator, donderdag 26 november 2009 23:54

Score: 0
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 ?

Door DiLDoG, vrijdag 27 november 2009 01:11

Score: 1
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.

Door negerzoen, donderdag 26 november 2009 18:33

Score: 2
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 negerzoen op donderdag 26 november 2009 18:34]

Door Little Penguin, donderdag 26 november 2009 19:13

Score: 1
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...

Door poepkop, vrijdag 27 november 2009 01:17

Score: 1
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 vrijdag 27 november 2009 01:18]

Door cdwave, vrijdag 27 november 2009 08:40

Score: 0
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.

Door TheNox, vrijdag 27 november 2009 13:21

Score: 0
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!

Door Little Penguin, donderdag 26 november 2009 18:38

Score: 1
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.

Door jbtbnl, donderdag 26 november 2009 19:08

Score: 1
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

Door MagicPatrick, donderdag 26 november 2009 20:23

Score: 1
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...

Door veldmuis, donderdag 26 november 2009 18:39

Score: 1
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. :)

Door jj71, donderdag 26 november 2009 19:46

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

Door g4wx3, donderdag 26 november 2009 22:34

Score: 1
JAVASCRIPT


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

[Reactie gewijzigd door g4wx3 op donderdag 26 november 2009 22:35]

Door driekske, donderdag 26 november 2009 23:18

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

Door Morellow, donderdag 26 november 2009 23:36

Score: 1
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.

Door Radhe, vrijdag 27 november 2009 10:17

Score: 0
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.

Door wildhagen, donderdag 26 november 2009 18:24

Score: 1
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...

Door Soultaker, donderdag 26 november 2009 18:34

Score: 2
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 donderdag 26 november 2009 18:36]

Door ZpAz, donderdag 26 november 2009 18:35

Score: 1
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.

Door hackerhater, vrijdag 27 november 2009 11:21

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

Door bzerk, donderdag 26 november 2009 18:36

Score: 0
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

Door dragontje124, donderdag 26 november 2009 18:39

Score: 1
zo gaat dat dus niet werken en dat begrijp jij ook wel :P

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)

Door br men, donderdag 26 november 2009 19:41

Score: 1
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.

Door pat42, donderdag 26 november 2009 20:13

Score: 1
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).

Door Jorbes, donderdag 26 november 2009 21:28

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

Door JanDM, donderdag 26 november 2009 21:52

Score: 1
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 ;)

Door Kazu, donderdag 26 november 2009 21:53

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

Door dragontje124, donderdag 26 november 2009 23:35

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

Door --Andre--, vrijdag 27 november 2009 08:57

Score: 1
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

Door hackerhater, vrijdag 27 november 2009 11:23

Score: 0
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

Door Little Penguin, donderdag 26 november 2009 18:46

Score: 2
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.

Door SirBlade, donderdag 26 november 2009 21:03

Score: 1
"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.

Door Little Penguin, donderdag 26 november 2009 21:48

Score: 1
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...

Door Wim-Bart, donderdag 26 november 2009 23:12

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

Door dragontje124, donderdag 26 november 2009 23:54

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

Door mieJas, vrijdag 27 november 2009 09:30

Score: 1
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?

Door R4gnax, vrijdag 27 november 2009 09:47

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

Door mschol, donderdag 26 november 2009 18:26

Score: 1
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

Door stifmeizter, donderdag 26 november 2009 18:39

Score: 1
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!

Door SPee, donderdag 26 november 2009 18:40

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

Door JanDM, donderdag 26 november 2009 18:48

Score: 1
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 JanDM op donderdag 26 november 2009 18:49]

Door Ventieldopje, donderdag 26 november 2009 19:09

Score: 1
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 :P

Door JanDM, donderdag 26 november 2009 19:14

Score: 1
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).

Door Little Penguin, donderdag 26 november 2009 19:21

Score: 1
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...

Door Ventieldopje, donderdag 26 november 2009 23:48

Score: 1
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 :)

Door Little Penguin, donderdag 26 november 2009 18:50

Score: 1
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.

Door Ventieldopje, donderdag 26 november 2009 19:10

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

Door Maximmm, donderdag 26 november 2009 18:33

Score: 1
daar dacht ik ook als eerst aan, goed aan functionaliteit, slecht in security oogpunt

Door fridgeman, donderdag 26 november 2009 18:34

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

Door Little Penguin, donderdag 26 november 2009 18:50

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

Door eborn, donderdag 26 november 2009 21:06

Score: 1
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.

Door RobertMe, donderdag 26 november 2009 18:35

Score: 1
Deze API bestaat toch al langer volgensmij? Opera gebruikt hem bv. al voor Opera Unite en het nieuwe widget systeem heeft ook al ondersteuning voor de File I/O API.

Door ApexAlpha, donderdag 26 november 2009 18:36

Score: 1
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 donderdag 26 november 2009 18:41]

Door JanDM, donderdag 26 november 2009 18:45

Score: 1
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 JanDM op donderdag 26 november 2009 18:50]

Door Little Penguin, donderdag 26 november 2009 18:56

Score: 1
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...

Door Psychnosiz, donderdag 26 november 2009 22:25

Score: 0
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.

Door Little Penguin, donderdag 26 november 2009 22:57

Score: 1
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...

Door RM-rf, donderdag 26 november 2009 18:48

Score: 1
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

Door Little Penguin, donderdag 26 november 2009 19:00

Score: 1
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.

Door onok, donderdag 26 november 2009 18:50

Score: 1
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?

Door JanDM, donderdag 26 november 2009 18:57

Score: 1
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 JanDM op donderdag 26 november 2009 19:04]

Door Little Penguin, donderdag 26 november 2009 19:06

Score: 1
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)

Door Daeron, donderdag 26 november 2009 19:03

Score: 1
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.

Door JanDM, donderdag 26 november 2009 19:06

Score: 1
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.

Door Little Penguin, donderdag 26 november 2009 19:10

Score: 1
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...
«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 23:31 Tweakers.net uitgeroepen tot Website van het Jaar 2009
Vorige 17:20 LG komt in 2010 uit met PK-plasmaserie
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011