Web application access user's file system

问题:

I am creating a web application for my client. The application will be installed on a dedicated server within corporate network. He wants to see the list of his local files (from his local PC) on the web page. He means that any visitor can see the list of his local files from some folder.

I know that the web application cannot have access to visitor's file system. Browser limits this by design. Of course, there might be some browser extensions and applets and flash apps or even hacks.. But this is not that case.

But how can I explain this to him? He points me to the 'save as' or 'load file' dialogs and say that other applications can do this. I don't know how to explain him that this is just a browser's interaction.

I tried to google for some links to proofs, but cannot find something quickly.

Can you guys give me some links to the documents describing inability to access user's folder from web application?

回答1:

Finally I did a compilation of some quotations and it is done..

https://en.wikipedia.org/wiki/JavaScript#Security

scripts run in a sandbox in which they can only perform Web-related actions, not general-purpose programming tasks like creating files

https://www.us-cert.gov/publications/securing-your-web-browser

JavaScript, also known as ECMAScript, is a scripting language that is used to make websites more interactive. There are specifications in the JavaScript standard that restrict certain features such as accessing local files.

https://developer.mozilla.org/en-US/docs/Web/API/File_System_API/Introduction#restrictions

Because the file system is sandboxed, a web app cannot access another app's files. You also cannot read or write files to an arbitrary folder (for example, My Pictures and My Documents) on the user's hard drive.

回答2:

Mozilla. File System API Restrictions

Because the file system is sandboxed, a web app cannot access another app's files. You also cannot read or write files to an arbitrary folder (for example, My Pictures and My Documents) on the user's hard drive.

回答3:

Maybe this document rocks?

http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#security-considerations

Section 4.1

An application can request temporary or persistent storage space. Temporary storage may be easier to get, at the UA's discretion [looser quota restrictions, available without prompting the user], but the data stored there may be deleted at the UA's convenience, e.g. to deal with a shortage of disk space.

Conversely, once persistent storage has been granted, data stored there by the application should not be deleted by the UA without user intervention. The application may of course delete it at will. The UA should require permission from the user before granting persistent storage space to the application.

This API specifies the standard origin isolation in a filesystem context, along with persistence of data across invocations. Applications will likely use temporary storage for caching, and if it's still around from a previous session, it is often useful. Persistent data, on the other hand, is useless if you can't access it again the next time you're invoked. However, even persistent data may be deleted manually by the user [either through the UA or via direct filesystem operations].

回答4:

What about arguing with the Client-Server model? You send a request to the server (website request, file or whatever) and the webserver can respond. There's no direct file system access on the server (webserver in between) and the client can choose what he sends to the server (file picker dialogue in browser).