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

On 9 April 2017 at 11:51, David Kendal <me@dpk.io> wrote:

> Moin,
>
> Over the last few years there has been a gradual downgrading of support
> in browsers for running pages from the file: protocol. Most browsers now
> have restrictions on the ability of JavaScript in such pages to access
> other files.
>
> Both Firefox and Chrome seem to have removed this support from XHR, and
> there appears to be no support at all for Fetching local files from
> other local files. This is an understandable security restriction, but
> there is no viable replacement at present.
>
> This is a shame because there are many possible uses for local static
> files accessing other local static files: the one I have in mind is
> shipping static files on CD-ROM or USB stick, but there is also the more
> obvious (and probably more common) use of local files by developers
> prototyping their apps before deploying them live to an HTTP server.
>
> This is an inconvenience to many web developers, and I'm far from the
> only one to complain about it. For instance, this from a very prolific
> reporter of Chrome bugs:
>
> > I've filed hundreds of Chrome bugs and I would rather would see this
> > fixed than any of them
>
> in <https://bugs.chromium.org/p/chromium/issues/detail?id=47416>. That
> bug was the number two most starred Blink bug in 2016.
>

Thanks for the pointer, I just starred this too.  I am currently hitting a
wall with this issue as well.

I have looked for a way to override this, but cannot find something.  As a
consequence, I have switched to electron, which seems to have this feature.


>
> I'd like to see APIs that solve this problem securely, in a way that's
> portable across all browsers. I know this isn't trendy or sexy but
> 'single-page apps' are still in vogue (I think?) and it would be
> useful/cool to be able to run them locally, even only for development
> purposes.
>
>
> A proposed solution, though far from the only one possible:
>
> There should be a new API something like this:
>
> window.requestFilesystemPermission(requestedOrigin);
>
> which does something like
>
> - If permission was already granted for the specified requestedOrigin or
>   some parent directory of it, return true.
>
> - If the current page origin is not a URL on the file: protocol, raise a
>   permissions error.
>
> - If requestedOrigin does not share a root path with the current page
>   origin, raise a permissions error. That is, a file with the name
>   file:///mnt/html/index.html can request access to file:///mnt or to
>   file:///mnt/html, but *not* to file:///etc, where it could read the
>   local password file.
>
> - The browser displays an alert to the page user showing the name and
>   path to the directory which has requested this permission. The user
>   can then choose to allow or deny access.
>
> - If the user chose not to allow access to the files, false is returned
>   or some other error is raised.
>
> - If they chose to allow access, return true.
>
> - For the remainder of the session (user agent specific), all files
>   in the requestedOrigin directory, including the current page, have
>   total read access (with Fetch, XHR, etc.) to all other files in
>   the directory.
>
> requestedOrigin is allowed to be an absolute or relative URI.
>
> Some useful Fetch semantics for file: URLs should also be defined.
>
> I like this solution because it maintains portability of scripts between
> HTTP(S) and local files without too much extra programming work: if
> scripts only request relative URLs, they can both (a) detect that
> they're running locally from file: URLs, and request permission if so
> and (b) detect that they're running on HTTP, and make exactly the same
> API calls as they would on the local system.
>
> This is also a beneficial property for those using file:// URLs for
> development purposes.
>
> Of course, this is just one solution that's possible. I would welcome
> feedback on this proposal and any progress towards any solution to this
> very common problem.
>

+1 looks like a good solution.  Another way would be to set a flag in the
options.


>
>
> Thanks,
>
> --
> dpk (David P. Kendal) · Nassauische Str. 36, 10717 DE · http://dpk.io/
>    <+grr> for security reasons I've switched to files:// urls instead
>
>

Received on Sunday, 9 April 2017 10:12:12 UTC