[file plugin] Accessing physical device paths

[Anthony Rumsey <ar...@adobe.com>]

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

Re: [file plugin] Accessing physical device paths

[Anthony Rumsey <ar...@adobe.com>]

Hi Ian,

Thanks for the reply.  I'm glad to hear that it looks like all my concerns
are already being addressed.  I'll look into the latest file and zip
plugins to see if they do indeed solve my issues.

Anthony

>
>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 <ar...@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
>
>

Re: [file plugin] Accessing physical device paths

[Andrew Grieve <ag...@chromium.org>]

Thanks for the feedback! I believe Ian's come to the same conclusion (that
we should be exposing this functionality), and is working on exposing it.


On Fri, Feb 28, 2014 at 11:22 AM, Anthony Rumsey <ar...@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
>
>

Re: [file plugin] Accessing physical device paths

[Michal Mocny <mm...@chromium.org>]

Note to anyone reading this guide in the future: I think it is still not
advisable to store or consume the result of "entry.toNativeURL()" in a way
that your app depends on being stable.  You should store the original path
passed to getFile() etc only, and resolve toNativeURL() only at the time of
use with each run of the application.

Right?


On Fri, Feb 28, 2014 at 1:01 PM, Ian Clelland <ic...@chromium.org>wrote:

> 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 <ar...@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
> >
> >
>

Re: [file plugin] Accessing physical device paths

[Ian Clelland <ic...@chromium.org>]

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 <ar...@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
>
>