locked
Seeking WebView (8.1) clarification: can JS coming from local storage use ScriptNotify?

    Question

  • Hello all,

    My use case is quite simple: download zipped HTML5 templates from CMS, cache to local storage, feed them content and allow them to drive interaction by calling into native C# via window.external.notify. But, the notify event never fires.

    I did some searching and came upon this forum response, which says that this is not going to work and references this doc. I quote from the doc:

    Note that, for security reasons, you cannot navigate to HTML you have downloaded to this location and you cannot run any executable or potentially executable code, such as script or CSS. It is intended for media such as images or videos and the like.
    However, this doc applies to HTML apps, not C# ones. The equivalent C# doc does not have a similar passage. Does this restriction indeed apply to C# apps as well as HTML ones? I can indeed navigate to HTML I've downloaded to local storage and run scripts there, only window.external.notify seems disabled, which leads me to suspect the applicability of this document. Furthermore, this windows team blog post seems to contradict the aforementioned doc.

    Sometimes you might want to create and/or store content locally, but then also load the content into WebView. For example, if you have an HTML game with downloadable levels, you can store the levels in the local state directories so they are available offline.

    WebView can now load content from the local and temporary app state folders. These are the same folders that are discoverable using the LocalFolder and TemporaryFolder APIs, and can be used for storing app content. The app can create directories and files under these folders, and then navigate to them using the ms-appdata protocol.

    To enable an app to have multiple islands of content that are isolated from each other, you are required to create a sub directory under the local or temporary folder’s and store the content within that directory. The Uri scheme is: ms-appdata:///local/TopLevelDirectory/file for files from the local state ms-appdata:///temp/TopLevelDirectory/file for files from the app’s temporary state folder

    This blog post seems to imply that this local-storage facility is now very much intended to be navigable and generally to be used for heavy lifting.

    So, my questions: has there been some change of policy since the aforementioned blog post and should we now avoid loading content from local storage, or is there some way to enable JS->C# communication for downloaded content? If there is, where is it documented? If there is no way to facilitate such communication, does that mean that HTML/C# hybrid apps are no longer permitted/frowned-upon in the Windows Store?

    Many thanks,

    Mike

    Tuesday, July 22, 2014 12:52 PM

Answers

  • The guidance is: don't do that.  The documentation is clear on the requirements, and you're not meeting them. 


    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Wednesday, July 23, 2014 2:19 PM
    Moderator
  • The point here is that arbitrary code downloaded from who-knows-where can't be assumed to be safe. It can be run sandboxed from the app, but letting it control the app is a potential security issue.

    If your scenario demands it, you can validate the HTML and load it via NavigateToString. That meets requirement #3 and will be able to call back to the app, but make sure you treat this as untrusted input and give it careful scrutiny.

    --Rob

    Wednesday, July 23, 2014 3:35 PM
    Owner

All replies

  • I am not aware of any changes.  However, note these things specifically:

    The manifest requirement does not apply to content that

    1) Originates from the app package,

    2) Uses an ms-local-stream:// URI

    3) Is loaded using NavigateToString.

    Which of these requirements are you meeting? 


    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Tuesday, July 22, 2014 7:40 PM
    Moderator
  • Hi,

    I'm not meeting any of these requirements. I'm using a "ms-appdata:///local/" URI which can't be added to the manifest because it fails validation.

    So, if it can't be added to the manifest, and does not fall into the list you provided, then scriptnotify will not work, is that right? If so, what is the guidance for downloading content and then establishing bidirection JS<->C# communication with scripts within that content?

    Thanks,

    Mike

    Tuesday, July 22, 2014 9:05 PM
  • The guidance is: don't do that.  The documentation is clear on the requirements, and you're not meeting them. 


    Matt Small - Microsoft Escalation Engineer - Forum Moderator
    If my reply answers your question, please mark this post as answered.

    NOTE: If I ask for code, please provide something that I can drop directly into a project and run (including XAML), or an actual application project. I'm trying to help a lot of people, so I don't have time to figure out weird snippets with undefined objects and unknown namespaces.

    Wednesday, July 23, 2014 2:19 PM
    Moderator
  • The point here is that arbitrary code downloaded from who-knows-where can't be assumed to be safe. It can be run sandboxed from the app, but letting it control the app is a potential security issue.

    If your scenario demands it, you can validate the HTML and load it via NavigateToString. That meets requirement #3 and will be able to call back to the app, but make sure you treat this as untrusted input and give it careful scrutiny.

    --Rob

    Wednesday, July 23, 2014 3:35 PM
    Owner
  • We're not downloading the code from who-knows-where, but rather from a trusted and secured CMS that we control. It's basically the same idea as whitelisting selected URLs in the manifest, except we're adding the additional step of downloading the code for later offline use, I don't see anything particularly risky about this scheme - and there should be some provision for supporting it. Anyway, it's easy enough to accomplish the same exact thing with NavigateToLocalStreamUri, so I guess the prohibition isn't that strong :)

    Mike

    Thursday, July 24, 2014 4:18 PM