cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Clelland <iclell...@chromium.org>
Subject Re: [file plugin] Accessing physical device paths
Date Fri, 28 Feb 2014 18:01:50 GMT
Hi Anthony,

I'm glad to hear your feedback on this. I've been the principal dev behind
this refactoring, and I suppose I've been responsible for a lot of these
sorts of decisions (although not entirely; the mailing list is littered
with long long threads about File and associated plugins)

The original reason for hiding this was to try to enforce the idea that
HTML filesystems are supposed to be sandboxed. In Chrome, for instance,
there is no way for a web site or app, even with filesystem permissions, to
get the actual on-disk location of any of your files, even given a
FileEntry object for them. It's simply none of the app's business where the
files actually live.

>From a security perspective, I had always believed that it is better not to
expose those kinds of details to JavaScript code. Partly because the app
shouldn't care, and partly because it opens up possibilities for apps to
read and write to locations that they really shouldn't have access to.

This abstraction also gives us the flexibility to introduce new types of
filesystems, where the resources may not even be files in the traditional
sense. Having them all under the "cdvfile" URL scheme means a single code
path can can be the entry point into the file plugin, and there's (ideally)
only one place to deal with these URLs.

Having said all that, I can appreciate your position here. The abstraction
isn't perfect, and there are places where, when dealing with the iOS or
Android webviews, it falls apart.

The very earliest dev releases of the refactored File plugin didn't even
have _getLocalFileSystemPath -- I didn't add that until I had actually
pushed it to git and started to use it with other plugins, like
FileTransfer. At that point, it was clear that some at least that plugin
would need a way to get an actual file path, given a cdvfile URL. So that
method was added, and marked as just for the use of FileTransfer.

Since releasing 1.0.0, we have had a lot more feedback about how other
plugins interact with File, and how people are using filesystem URLs in
their apps, and what's not working like it used to. I've made some biggish
changes to the plugin to address this feedback; hopefully it addresses your
issues as well.

The first big change since 1.0.0 was released was to make an explicit
interface for native code to convert between cdvfile URLs and absolute
device filesystem paths. This was CB-6057, and there is a document now that
plugin authors can use for guidance on working with the new URLs. This was
done still with the intention that, while native code might need to work
with filesystem paths, we should still keep those methods away from the
JavaScript code in the app.

(Incidentally, the first customer of this API was the zip plugin itself --
v2.0.0 at https://github.com/MobileChromeApps/zip uses this, and works well
with File 1.0.1.)

The second change was spurred by CB-6079, and implemented as CB-6106. It
turns out, as you've noticed, that there are some places in the webview
which simply cannot use URLs with schemes other than file:// and http[s].
The <audio> and <video> tags, specifically, just cannot be made to work
with cdvfile:// URLs, and I suspect that there are other cases as well.
(Even <img> tags, before Android 4.0.0, have troubles with these URLs.)

To address that, there is a new method on FileEntry objects,
FileEntry.toNativeURL(), which provides a URL which *can* be used for
these, and which I suspect can be used in your case as well, rather than
calling the exec bridge.

As soon as the new version is released, you should be able to replace any
instances of your exec() call with "entry.toNativeURL()", and get back a
URL which you can use.

I think it's unfortunate that we have to expose device-path locations in
this way; it's an information leak at the very least, and it means that we
need to be extra careful that paths which should be unavailable to the app
actually *are* off-limits, but it appears to be a necessity.

Hopefully these changes address your concerns -- I certainly want the new
version of File to be at least as useful as the previous version. If you
think that more still needs to be done, please email me (or the list); I'd
love to talk about your use cases.

Regards,
Ian



On Fri, Feb 28, 2014 at 11:22 AM, Anthony Rumsey <arumsey@adobe.com> wrote:

> Hi there Cordova devs!
>
> The release of version 1.0 of the file plugin obviously changed the
> behaviour of a majority of its API in order to be better aligned with the
> W3C file spec.  As an app developer at Adobe and user of this plugin the
> abstraction of device paths to filesystem URLs is great in order to get
> consistent behaviour across devices.  On the other hand there are cases
> when a lament the loss of having access to actual device paths.  Is it not
> possible to to have the best opt both worlds and allow the file plugin to
> convert file entry URLs to local paths when desired?
>
> Wait a second! There is an internal method already that provides
> thisÅ "_getLocalFilesystemPath"!!
>
> I know there has been lengthy discussion on this topic in the past but
> what was the final reason for hiding this functionality?
>
> Now for some context on my use case.
>
> In the process of upgrading an app I'm working on to use file-plugin 1.0 I
> ran across 2 cases where I needed an actual local filesystem path.  First,
> the app downloads ZIP files from a server and then unzips them on the
> device to persistent storage. The zip plugin in this case expects local
> file system paths as its source and destination.  Maybe the solution to
> this usage would be for the zip plugin to support filesystem URLs.  Fair
> enough but that isn't the case today.  Second, once the zip content is
> stored I then want to redirect my web view to that location.  With the
> testing I did there didn't seem to be a way to redirect to a filesystem
> URL using 'window.location.href'.
>
> In both cases, since '_getLocalFilesystemPath' exists, I have resorted to
> calling 'window.cordova.exec(success, fail, "File",
> "_getLocalFilesystemPath", [url]);' in order to get the desired path.
>
> Thanks,
> Anthony
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message