W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2017

Re: [whatwg] Accessing local files with JavaScript portably and securely

From: duanyao <duanyao@ustc.edu>
Date: Tue, 18 Apr 2017 18:17:28 +0800
To: Roger Hågensen <rh_whatwg@skuldwyrm.no>, whatwg@lists.whatwg.org
Message-ID: <983dffc7-3d18-ecc7-a2e4-67d0c730876e@ustc.edu>
在 2017年04月18日 16:09, Roger Hågensen 写道:
> On 2017-04-17 15:22, duanyao wrote:
>>> This can handle multipage fine as well.
>>> Anything in the folder test.html_files is considered sandboxed under
>>> test.html
>> The problem is, what if users open `test_files\page2.html`or
>> `test_files\page3.html`directly? Can they access 
>> `test_files\config.json`?
>> This is to be solve by the "muli-page application" convention. By the
>> way, the name of the directory is usually `foo_files`, not
>> `foo.html_files`.
>
> Good point. But why would a user do that when the entry point is the 
> test.html?
The user may bookmark it and access it later on; the tab maybe restored 
from a previous browser session;
the user may open it from the histroy list, and so on.

>
> In this case the browser could just fallback to default behavior for 
> local html files.
Agree.
>
> Alternatively the browser could have some logic that knows that this 
> is a page under the test folder which is the sandbox for test.html
>
> Also your example of "test_files\page3.html" and 
> "test_files\config.json" ofcourse page3.html could access it, just 
> like it could access config.js if not for CORS on XHR and local files.
Maybe no. "files" is a generic word, so if you make every "xxx_files/" 
folders magical, it's quite possible that there are folders happen to 
ends with "_files" but are not intented to be local web apps. If you 
require a `xxx.html` to make "xxx_files/" magical, it is a little 
awkward and confusing for muli-page app.

This is why I propose a new (and unlikely already used) pattern 
`xxx_webrun/` for more powerful muli-page app, and limit `xxx_files/` to 
single page app.

In single page app case, it would be more common that `test.html` gets 
`test_files\page{2|3}.html` via XHR and renders the latter in place, 
instead of navigating to it.
So the latter don't need to access `test_files\config.json` themselves.

>
> Actually a lot of the issue here is XHR (and fetch) not being possible 
> for local web pages.
>
> The only reason I suggested using the same naming convention for the 
> sandbox folder is that (at least on Windows) Explorer deletes both the 
> html and folder something users are familiar with. Though I'm sure 
> Microsoft could add support for the same to another folder naming 
> convention, I can't see that being backported to Windows 8.1/8/7.
`xxx_webrun/` convention doesn't need OSes' support, just browsers'; and 
you just delete that folder to delete the app completely.

>
>>> I just checked what naming Chrome does and it uses the page title. I
>>> can't recall what the other browsers do. And adds _files to it.
>> Chrome can be configured to ask for location when saving a page, then
>> you can name it as you will.
>> The "xxx_files" convention was introduced by IE or Netscape long ago,
>> and other browsers just follow it.
>> ...
>>> I have not tested how editing/adding to this folder affect things,
>>> deleting the html file also deletes the folder (at least on Windows
>>> 10, and I seem to recall on Windows 7 as well).
>> There is no magic link between `foo.html` and `foo_files/`, this is just
>> a trick of Windows Explorer. You can change things by hand in that
>> directory as you will.
>
> I just confirmed that. just creating a empty .html file and a same 
> named folder with _Files at the end does "link" them in Explorer.
> Is this unique to Windows or does other platforms do the 
> same/something similar?
>
Probably just Windows Explorer. At least Nautilus file manager on linux 
doesn't do the trick.
Received on Tuesday, 18 April 2017 10:18:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 18 April 2017 10:18:19 UTC