Custom file system for accessing web applications

Question

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

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

But how can I explain this to him? He points me to the dialogs “save as” or “upload a file” and says that other applications can do this. I do not know how to explain to him that this is just interaction with the browser.

I tried to use Google for links to evidence, but I can not find something quickly.

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

Answer 1

Finally, I compiled some quotes, and it is done ..

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

scripts are executed in a sandbox in which they can only perform Web-related activities, and not general-purpose tasks, such as 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 sites more interactive. The JavaScript standard has specifications that restrict certain functions, 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, the web application cannot access other application 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.

Answer 2

Mozilla File System API Limitations

Because the file system is sandboxed, the web application cannot access other application files. You also cannot read or write files arbitrarily (for example, "My Pictures" and "My Documents") on the user's hard drive.

Answer 3

Maybe this document has slipped?

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

Section 4.1

An application may request temporary or permanent storage space. Temporary storage may be easier to obtain at the discretion of UA [quota restriction restrictions available without user request], but the data stored there may be deleted at the convenience of UA, for example. to solve the problem of low disk space.

Conversely, after maintaining persistent storage, the data stored in the application should not be deleted by the UA without user intervention. An application may, of course, delete it at its discretion. The UA must require permission from the user before providing a permanent place to store the application.

This API defines standard source isolation in the context of the file system, as well as persistence of data through calls. Applications are more likely to use temporary storage for caching, and if it is still around the previous session, it is often useful. Persistent data, on the other hand, is useless if you cannot access it again on the next call. However, even persistent data can be deleted manually by the user [via UA or through direct file system operations].

Answer 4

How to argue with the Client-Server model? You send a request to the server (request for a website, file or something else) and the web server can respond. There is no direct access to the file system on the server (between the web server), and the client can choose what it sends to the server (file selection dialog in the browser).