I am using SWT Browser to display html pages. These HTML pages are stored in a folder. By this anybody can copy the data easily, which I want to protect. For this I have encrypted the HTML pages.
How to decrypt these HTML pages during Backward and Forward activity ? Also while displaying them in the browser by using setUrl("url") method -
htmlBrowser.setUrl(url String);
Related
So I'm trying to download pdf files from an ancient internal web system. I put in a request and based on my request parameters, it generates a new pdf and shows it in a new window. Since the pdfs are generated dynamically, there is no real url I could download.
I'm trying to figure out how I would download the file after it has generated and opened up in the new window.
The pertinent part of the page's source seems to be this:
<body onload="document.FormForDownload.submit();">
<form name="FormForDownload" method="get" action="./download.pdf" target="iframePDF">
<iframe name="iframePDF"></iframe>
</form>
</body>
I'm open to using the requests library or urllib or anything people suggest. ANy ideas? Working in python btw.
If I suppress chrome's own PDF viewer to get it to automatically download the pdf, I get a page that looks like this:
Clicking the open button will give me this page:
This is because the url generated is one time use only, to generate the url again, I have to request the pdf again.
I am using nodejs server to serve static files. When the pdf file is served, the browser displays the title as URL of the pdf path.
127.0.0.1:8080/docs/sample
How can I set this to a custom title say "Sample"
I have tried following things but no luck :
res.setHeader('Content-Disposition', 'inline;filename="sample.pdf"');
Setting meta tag of pdf file as "sample"
Any help will be much appreciated.
If you're using a static file server, then yes you are serving it as a download. Modern browsers often contain a built-in PDF viewing plugin, so instead of asking the user where to save the file, the browser will instead just display the PDF right in a browser tab. It still downloaded it, it just saved it to some temporary cache on your machine in that case.
What I'm getting at is that you cannot control the browser title in that case because it's just the browser trying to be nice and make things convenient for the user. The PDF file itself would have no idea if it was being displayed in the browser's built-in viewer or in Adobe Reader on the desktop. There are no HTTP headers you could send down to set the title either because browsers expect page titles to be set from HTML or JavaScript running on an actual web page.
Now, if you were to embed the PDF file in an HTML page with some kind of PDF viewer then you could control the page title with a simple <title>some title</title> tag or calling document.title = 'some title'; from JavaScript. That works because the browser is rendering an actual web page that you control, and that page just happens to have an embedded PDF viewer on it.
Here's an example of an embeddable PDF viewer. http://pdfobject.com/
//hack alert
You could trick the browser by setting the last fragment of the url to whatever you like . i.e. change sample in your example to the desired title.
(tested in chrome 58.0.3029.110)
HTH
I have a fundamental question and I am searching for that for a long but I still don't know the exact response for that.
I am working with browsers and web applications. I am wondering how and based on what a web browser decide to send a particular request to the web server.
For example when you enter http://www.google.com inside the address bar of your web browser. the Browser will send a bunch of request to the web server for rendering the web page properly.
Now, my question is that how the web browser decide which request it needs to send to the web server.
does it related to some tags like 'link' or 'script' inside the body of the responses.
does the browser parse the javascript functions to see if it should send a request based on those functions?
Lets take an example to explain this one.
Consider you want to search for something and you hit http://www.google.com on your browser. These are the events that unfold to fetch you the page that will let you type in your query.
First, the networking stack on your machine will try to figure out which actual internet address matches www.google.com. This is called a DNS lookup. Once it receives a response for this lookup in form of an IP address, it can make a connection to the actual server that is serving google.com.
The machine makes a socket connection and uses the HTTP protocol to communicate with the server. It queries for the resource at / (which is the root) of the address you are trying to reach. This is called a GET request. The request is normally described like so: GET /
Google will respond with an HTML page. normally "index.html", which gets downloaded by the browser.
Once the HTML is downloaded, all linked resources, such as images to render the HTML as well as javascript referenced by the HTML page gets downloaded.
The downloaded HTML page is parsed and an in-memory tree is created called the "DOM Tree". This tree contains the elements of the HTML page in a hierarchy. Once the DOM is created, you can see the page being rendered on the browser.
During this parsing, the browser discovers more resources to be downloaded, such as images, stylesheets, javascript files. The HTML page references these resources via different tags such as <img> for images, <script> for javascript.
All detected resources are downloaded. Browsers download many of these resources in parallel, but apply them (javascript and stylesheets) sequentially in the order they where found on the page.
Stylesheets are parsed, and the styles are applied to the DOM of the HTML page. Sometimes, if stylesheets take longer to download, you can see the "raw" HTML page being rendered before the styles are applied. This happens sometimes over a slow connection.
Once the HTML page and related javascript files have been downloaded, the browser calls the "onload" callback function of javascript. Most Javascript heavy applications are started at this time.
Once onload is called, Javascript takes over and can attach handlers for different elements on the web page. Once the handlers have all been installed, interacting with the webpage could call one or more javascript functions that are listening for these events.
Javascript can also manipulate the DOM (the elements on the page), which results in UI updates (what the user sees) and therefore can be used to build a complete app on a single page.
Here is some more reading on the process: http://friendlybit.com/css/rendering-a-web-page-step-by-step/
The best way to examine this interaction is to use Developer tools on Chrome/FireFox or IE and view the network activity when you visit a web page.
I would like to modify my extension's popup dynamically (at run-time). And want to specify a custom popup HTML file that's loaded from my server.
In Firefox, I can easily accomplish this with XUL overlays which I can specify at run-time.
And document.loadOverlay() does allow me to specify a 'remote' URL for the overlay.
Is the same possible in Chrome?
I've been playing with chrome.browserAction.setPopup( details ) API, but it seems that the details.popup param must specify a local file, and not a remote URL.
I have answered this exact same question on the Chromium-Extensions mailinglist.
There is no API to load external popups but you can do that with plain JavaScript. What you could do (I have done that in the past):
Use an iframe + extension messaging within the popup. The iframe
points to some external url not hosted in the extension.
Use templates (jQuery templates example), load those template files to
your background page, and just use them to construct your popup.
Download the html contents using XHR and load them within the popup
by constructing the DOM.
I usually use the template approach, but I use the popup iframe approach when I want to manage the entire popup in the server side so I don't have to push updates to the extension gallery. I am not a fan of downloading the HTML contents, templating seems safer.
Hope this helped!
I'm creating an image gallery site that you have to log in to access. The site will use sessions to keep track of usernames and passwords. Logged in users will be able to search for images and see results. Presumably, this means I'll be putting images in a web directory. How do I keep non-logged in people from being able to browse directly to an image in this directory?
This is PHP-based, with MySQL.
Check for a referrer header, and require it to be from your site.
You can also check that cookies get sent to you (that they're logged in).
Your best bet is then having PHP fetch the images from a location outside of your web dir.
Also, check out the comment string: using mod_rewrite can do all this directly from apache.
Put the images in a folder that isn't accessible through a direct Url, and have the program serve the image directly
Don't put the images in a browsable directory. Better yet, store them outside of your webroot. Put some sort of custom handler in place that will load the requested image and send it back to the user, after the user has been validated and verified. This will also prevent hot-linking of your images.
Put the images in a folder outside the web site, and use a proxy page to send the image to the browser. Make a page that you use as url in your img tag, something like:
getimage.php?id=8783475
In the page you check that the user is logged in, and determine from the parameters what image to send. Set the content type of the page to the type that matches the image, for example "image/jpeg", read the image file and send directly to the response stream.
If your images are not too large, there is a very smart way of protecting them from unauthorized access.
You can you base64 econding, the same as Outlook Express attachment encoding, and put the code inside an ASP page which uses the SESSION object. SEE TUTORIALS ON ASP FOR MORE ON THIS SUBJECT.
When a user accesses the page, the asp code checks if the user is autheticated. If he isn't the script interrupts the page code, not visualizing the image.
If the user is authenticated the scripts loads the entire page and the base64 is reconstructed into a visible image.
The trick here is that you don't have a directory with plain images in it, but the image is encoded in the page html, so it is reconstructed on the fly by the script.
Since you don't have images in the directory, nobody can attempt to point the browser directly to them, since thay simply do not exist.
You can use this site to encode the images:
http://www.motobit.com/util/base64-decoder-encoder.asp
Then you have to "call" the image in the html code using this tag:
img src="data:image/gif;base64, ..............................................(here you place the code obtained from the site above)...............
You're done! Your images are not accessible if the user is not logged in.
Do not let people access your image directories directly.
Let your image gallery software forward the image to the user. Check the needed credentials.