Note also that the HTTP server solution requires you to ship a binary (the server) with your files, therefore sacrificing platform independence and requiring the user to run an untrusted binary, all just to show some HTML files.
Jonathan Zuckerman <j.zucker...@gmail.com> schrieb am So., 9. Apr. 2017, 14:23: > The solution most developers use is to run a simple web server that hosts > static content, it's a much simpler solution than the API you propose and > requires no changes to the spec. It doesn't address the CD-ROM use case, > though.. > On Sun, Apr 9, 2017 at 06:11 Melvin Carvalho <melvincarva...@gmail.com> > wrote: > > > On 9 April 2017 at 11:51, David Kendal <m...@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 > > > > > > > > >
