Semantic of NPN_GetURL. Local files. History

Benjamin Smedberg benjamin at smedbergs.us
Fri Feb 24 08:24:20 PST 2012


On 2/23/2012 4:35 PM, John Yani wrote:
> Hi.
> I am writing a plugin which intercepts data of a mime type, processes
> it, generates an HTML result, and redirects the browser to this newly
> created html file on the local drive.
Do you mean that it redirects the browser to something like 
file:///c:/temp/somefile.html?

If so, I think there are some serious security issues with your setup: 
somefile.html would then have access to anything in the temp directory 
(or wherever you are storing the files.

OTOH, if you are dynamically generating the content using NPN_NewStream, 
then it will have the correct security context, but it will still have 
the navigation/history issue you describe below.

>
> I have two points, concerning implementation/semantic of NPN_GetURL (
> https://developer.mozilla.org/en/NPN_GetURL ).
>
> The first point concerns security issues
>
> Some browser implementations, namely WebKit and Mozilla forbids
> opening local files ("file://") when the plug-in is on a remote
> (http://) page  ( https://bugzilla.mozilla.org/show_bug.cgi?id=332572
> ) .
> As long as the plugin can open sockets and read local files directly
> and have the same rights as a browser, I don't see any reason to
> forbid opening local files with NPN_GetURL.
I suspect that this is defense in depth. Plugin codepaths are often 
written with the assumption that URL loads are network loads, and don't 
consider the security implications of loading file: URIs. OTOH, if 
you're using native filesystem calls then considering the security 
implications seems obvious.
> As you know NPN_GetURL supports target option. If it is "_self" url
> will be opened in current page. The problem is that a page page with
> plugin is saved to history. So when I click back when I'm on html
> result page, the content is redirected to the plugin which generates
> an html result and redirects me there. Endless loop.
> What I propose is to add a new target option "_self_no_history". Its
> semantics would be the same as "_self", but the current page would be
> deleted from history before redirect. So when I click back, I'll be on
> the page before
I don't think that this is necessary or desirable in your case, and 
would probably be pretty complicated to implement. However, assuming you 
can generate the content you want in string form, I think that the only 
thing necessary is to replace the contents of the current page using 
document.write using NPRuntime scripting. I have tested that this works 
at least in gecko even for fullpage plugins.

--BDS



More information about the plugin-futures mailing list