The only way I know to take the contents of a local file and push those bytes to a server is to set up a form post with an <input> of appropriate type to prompt the user to select a file.
I would like to do the same thing only pushing the data through XMLHttpRequest (no cross-scripting tricks).
Currently, we do this with an iframe to get the post behavior.
My sense is the iframe is the only solution, but I post here in case I've missed something.
You could use the JavaScript File API (available in Firefox 3.6 or later and latest versions of Chrome and Safari). Basically, you can add an event listener to the <input> tag that will fire when a user selects a file. Then, you can upload it using an XMLHttpRequest. Also, the File API can allow you to do other fancy stuff, such as drag-and-drop uploads, getting information about a file before it is sent to the server, and providing a progress bar as a file is uploading.More info: https://developer.mozilla.org/en/using_files_from_web_applications
This is not a good cross-browser solution because it doesn't have good support in all the popular browsers (Internet Explorer), but you could use feature detection in JavaScript to detect if the File API is available and revert back to your iframe method if it is not.
Related
MDN docs state:
To enable a web page to contain an <img> element whose src attribute points to this image,
you could specify "web_accessible_resources" like this:
"web_accessible_resources": ["images/my-image.png"]
The file will then be available using a URL like:
moz-extension://<extension-UUID>/images/my-image.png"
<extension-UUID> is not your extension's ID.
It is randomly generated for every browser instance.
This prevents websites from fingerprinting a browser by examining
the extensions it has installed.
So, I would think that these resources cannot be read by any web page outside the extension, since they would need to know the random UUID.
However, the same MDN docs also state:
Note that if you make a page web-accessible, then any website may then link or redirect
to that page. The page should then treat any input (POST data, for examples)
as if it came from an untrusted source, just as a normal web page should.
I don't understand how "any website may then link or redirect to that page". Wouldn't it need to know the random UUID? How else could a webpage access this resource?
The point of Web Accessible Resources is to be able to include them in a web context.
While you can communicate the random UUID to the webpage so that it can use the file, it doesn't have to be included by the website code itself. Here's a hypothetical scenario:
You're writing an extension that adds a button to evil.com site's UI. That button is supposed to have an image on it.
You bundle the image with your extension, but to add it as src or CSS property to the webpage you need to be able to reference it from a web context.
So, you make it web-accessible, and then inject your UI element with a content script.
Perfectly plausible scenario.
Note that a random third-party site villains-united.com can't just scrape the URL to know if your extension is installed, since the URL is per-browser unique. This is the intent behind WebExtensions's UUID over Chrome's extension-id model.
However, let's continue our hypothetical scenario, from a security perspective.
The operators of evil.com are unhappy with your extra UI. They add a script to their code that looks for added buttons.
That script can see the DOM properties of the button, including the address of the image. Now evil.com's code can see your UUID.
Being the good guy, your extension's source code is available somewhere, including the page that launches nuclear missiles if called (why you would have that and why it would be web-accessible is another matter, perhaps to provide the functionality to good-guys-last-resort.org).
evil.com's script now can reconstruct the URL of this trigger page and XHR it, plunging the planet into nuclear apocalypse. Oops. You probably should've checked the origin of that request.
Basically, if a web-accessible resource is used in a page, the UUID likely leaks to that page's context via DOM. That may not be a page you control.
I have a Web Extension that occasionally deals in files -- usually by sending off a URL to the file to a remote server or by downloading the file at the user's request and shipping off the bytes to the same server.
This works fine for most use-cases, but sometimes you'll come across a site that automatically triggers a download of a file and pops open the file-open dialog for the user to handle. I wasn't able to find any documentation or filed bugs to this effect, but is there a way to register an extension to appear as a handler in that dialog?
Its currently not possible to add an icon to the file chooser dialog with WebExtensions. Feel free to open a feature request here: http://bugzilla.mozilla.org/
If you want to handle an action whenever a download occurs, you can use
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/downloads/onCreated
I have a webbrowser control in my application that is used to display pdf files that have been created in iTextSharp and are stored locally on the hard drive.
I would like to be able to navigate the file (next, previous, first, last, toc) from my application rather than using the inbuilt nav of the reader in the browser.
I have seen that you can navigate to specific pages by using
Browser.Navigate("filename.pdf#page=?);
This works the first time but when trying to navigate to a different page, it makes the browser disappear completely with no errors. However, I can reload the file without problem if I don't have the #page=? suffix on the file url though. Any ideas on this?
Alternatively, is there anyway in iTextSharp of adding something to the file to allow for it to be navigated from an external command?
All the official parameters that can be used to navigate through a PDF using parameters in the query string after the ? character are listed in a document published by Adobe: Parameters for Opening PDF Files
You already mentioned the page parameter. Another option could be using named destinations: nameddest=destination. In this case, you need to add the anchor with name destination to the file using iTextSharp.
Note that not all viewers implement these parameters. Adobe supports them in Adobe Reader and in the Adobe Reader plug-in, but there is no guarantee that they will work in pdf.js (Firefox), Pdfium (Google Chrome),... If your browser disappears when using an open parameter, you may have hit a bug in the browser or the viewer plug-in that causes the browser to crash. iTextSharp nor iText can crash a browser ;-)
There are no other ways you can navigate a PDF from an external application. The only thing you can do, is to add JavaScript to the PDF so that it always opens at the same page. This is done using an open action. I don't think this solves your problem as it would mean that you have to change the PDF file every time you want it to open at a different page.
I'm trying to send a PDF file from a WCF to silverlight client. PDF is generated by DevExpress XtraReports (in method XtraReport CreateReport(string reportTypeName, RootGenericReportParameterContainer reportInformation)).
Acually PDF is saved somewhere on clients computer after choosing save path in file save dialog - DevExpress takes care of everything - but I don't have a clue how to open the PDF in new tab in browser.
And here is another problem. Silverlight 4 has no access to local file system right? So information about local PDF location is useless. Maybe it would be better to save the PDF in WCF and send a link to it to the client - but how?
I would first question why you need to send the file to the Silverlight client. Get rid of that requirement and the solution becomes much simpler. Silverlight can provide a link that opens a new browser tab. That link would be handled by the web domain, processing it as an HttpHandler, generating the PDF file for the browser. Your PDF url doesn't have to reference a physical file, you can still generate it on request, handle querystring values, etc... Lots of different ways to do this.
Seems that the question isn't really about DevExpress or Silverlight - you're just looking to open a [document of some kind] in a new tab. Each browser natively handles things differently, and users can change tab handling to whatever they want. And (as you mentioned) once the user has downloaded the file, you no longer control it.
Your best bet (and the way I do it) is probably to have a link pointing to a handler/file using "target='_blank' " in the anchor tag on the webpage. From the server side, you would want to set the "Content-Disposition" header to "Inline" to indicate to the browser that the document should be displayed in place instead of downloaded ("Attachment").
I'm developing a Windows Application in C sharp.using a Web Browser control to Login to the Https Site and Download the List of files. I'm able to login in to the Site and I'm able to Navigate to the Page where files are listed to be downloaded. When I try Downloading the file using the file URL and trying to Navigate using Web Browser Control a Pop - Up appears asking whether to Open or Save or cancel. How to handle this Pop up and I'm stuck here.
Any Answers are appreciated.
Thanks,
Vinay.
If all you are trying to do is download a file, you might be better off using webRequest.Create("Url") instead of the WebBrowser control. There are ways of handling authentication depending on the method the website uses.
It's best not to use the WebBrowser to download files (unless initiated by the user, who can click the save button). Instead, you can use a WebRequest to download the files from your application.
Since you said you have to log in to the website, I'm going to assume that it uses the popular method of using cookies (as opposed to HTTP Basic Auth). To get the cookies from the WebBrowser, you can use the Cookie property of the WebBrowser's Document property.