I'm putting together a portfolio website which includes a number of images, some of which I don't want to be viewable by the general public. I imagine that I'll email someone a user name and password, with which they can "log-in" to view my work.
I've seen various solutions to the "hide-an-image" problem on line including the following, which uses php's readfile. I've also seen another that uses .htaccess.
Use php's readfile() or redirect to display a image file?
I'm not crazy about the readfile solution, as it seems slow to load the images, and I'd like to be able to use Cabel Sasser's FancyZoom, which needs unfettered access to the image, (his library wants a link to the full sized image), so that rules out .htaccess.
To recap what I'm trying to do:
1) Provide a site where I give users the ability to authenticate themselves as someone I'd like looking at my images.
2) Restrict random web users from being able see those images.
3) Use FancyZoom to blow up thumbnails.
I don't care what technology this ends up using -- Javascript, PHP, etc. -- whatever's cleanest and easiest.
By the way, I'm a Java Developer, not a web developer, so I'm probably not thinking about the problem correctly.
Instead of providing a link to an image. Provide a link to a cgi script which will automatically provide the proper header and content of the image.
For example:
image.php?sample.jpg
You can then make sure they are already authenticated (e.g. pass a session id) as part of the link.
This would be part of the header, and then your image data can follow.
header('Content-Type: image/jpeg');
Edit: If it has to be fast, you can write this in C/C++ instead of php.
Using .htaccess should be the safest/simplest method, as it's built in functionality of the webserver itself.
I do not know if it fits your needs, but I solved a similar poblem(giving pictures to a restricted group of people) by using TinyWebGallery, which is a small gallery application without database.
You can allow access to different directories via password and you can upload pictures directly into the filesystem, as TinyWebGallery will check for new dirs/pics on the fly. It will generate thumbnails and gives users possibility to rate / comment pictures (You can disable this).
This is not the smallest tool, however I thik it is far easier to setup than using apache directives and it looks better as naked images.
If you're using Nginx, you could use the Secure Link module.
Related
In Imgur, you can input an image URL and a few seconds later, there's a thumbnail of the image. Or in Bing Search, you can (or used to) be able to view a thumbnail of the website in the search results before visiting it.
I would love to implement something similar for my website, but I can't wrap my head around on how it is done. Moreover, are there not security concerns? I'd imagine the servers have to at least download the website, render it and take a screenshot. What if it's a malicious website, and you download something malicious on your server?
A headless Web browser engine like PhantomJS can be used for this. See example on their wiki. Yes, it would be prudent to run this in some sort of a sandbox, feeding a queue of URLs into it, then taking the generated thumbnails from the file system.
While I don't know the internal workings of any of the aforementioned services, I'd guess that they download/create a local copy of the images and generate a thumbnail from that.
Imgur, as an image hosting service, definitely needs a copy of the image prior to being able to generate thumbnails or anything else from it. The image may be stored locally or just in memory, but either way, it must be downloaded.
The search engines displaying screenshots of the sites likely have services that periodically take a screenshot of the viewable area when the content is getting indexed, and then serve those screenshots (or derivatives) along with the search results. Taking a screenshot really isn't dangerous, so there's nothing to worry about there, and whatever tools are used to load/parse/index the websites will obviously be written with security considerations in mind.
Of course, there are security concerns about the data you're downloading, too; the images can easily contain executable code (such as PHP) in their EXIF data, so you need to be careful about what you do with the images and how.
Currently working on an offshoot of the idea more adequately addressed here.
Creating a Secure File Hosting Server for PDFs
I'm developing a secure PDF hosting website where certain users can download certain PDF's that I have stored outside of the webroot to prevent people from accessing documents they shouldn't access.
I've got the download working using the first solution, but I want to implement a 'view/preview' feature too. I still don't get content headers as well as I should but I believe what is causing the bulk of my issues is I can't put a 'src' attribute on the embed/object/iframe/whatever. And that's kind of the point of the system.
My question is, is there any way to feed a file (as opposed to a url) to an embed/object? I would like to keep my current system and I'm going for simplicity at the moment so the easier the better.
I saw Recommended way to embed PDF in HTML? and will probably check out pdf.js if I'm trying something that isn't doable.
I have not yet had the chance to play with pdf.js, but it either that or a flash player of some sort.
Or you rely on the browser to display it has a webpage and you can iframe it, but that's so lame... it would work only for a fraction of you users.
PDF2SWF - convert PDF to SWF ( 1 page = 1 SWF).
Use other SWF (reader) to load SWF pages via XML or something else.
Use $_SESSION to store ID of PDF document which should be served through e.g. /preview (same link for previewing all documents)
Don't serve original PDF, put a watermark, or make them low-res.
Otherwise, your PDF will never be "secure".
http://www.swftools.org/
I am developing a website with php that is about uploading and selling/buying pdf documents. Of course, I need to program it in a way that makes it impossible (or at least very hard) to copy the purchased documents.
Do you know of any mechanism to do this? Is it a programming issue or rather a pdf issue? Also, are there maybe other file types that you recommend that are better for this purpose than pdf? Maybe there should be another solution than downloading the pdf files but rather only viewing them in a browser?
Thank you!
Charles
EDIT
Maybe some more information is needed: The users on the website will upload the pdfs themselves, so there is no way to create the pdfs only when they are downloaded, as they are purely user generated input.
I believe password/certificate protected pdfs are an option, though iirc they require certificate verification (so Adobe Acrobat loads a certificate and verifies it against your server on each viewing). This can require a lot of faffing by the purchaser, and may put some people off the service.
I'd just generate the pdfs at purchase-time and embed the purchasers details (address, email, etc) visibly inside the pdf (don't do it just secretly as it would probably violate privacy laws in some countries, though you should embed a private 'transaction id'), and in it's metadata. This way it provides both a disincentive to sharing (in that either their details will be shared with others, or that they will have to take the effort to remove them (which is difficult for the average user if you place edit-locks in the file)).
It also potentially allows you to identify and block the user from additional purchases if you do find a shared document online.
As per question edit... It's possible to make automated edits to pdf documents through the use of Ghostscript. (may need integration with something like IMagick or other software depending on the type of edits you wish to apply)
I would embed them in my web-page. When the user downloads the document you loose control over it. (unless you implement some fancy DRM solution)
Simple way to go would be to use something like Flex Paper or other online viewers.
Create a page that verifies if a user is logged in for example and has the rights to download the PDF.
Try something like this when serving the file to the user, if you are using PHP for example:
header("Content-Type: application/force-download");
header("Content-Disposition: attachment; filename=\"file.pdf\");
I'm building a web app where users can build custom web pages that pull content from other web pages. I know of a few options for doing this, and I'm not sure which is best, and if there are better solutions out there. Right now, I could:
Use iframes, which will (sort of) accomplish what I want, but will force the client to download and render all the web content, which seems slow. I've heard a lot of people say iframes are passe and should not be used, etc.
Use a library like wkhtmltopdf, which will render the html on the server side and generate a pdf image of it. This would work nicely, but the result is just an image, so text won't be selectable, links won't be clickable, etc. Also, I've heard that you can get in legal trouble for hosting other people's web content on your site without permission.
Use something like phpquery to literally scrape content off of other sites. This option could have the same legal issues as the above option.
Has anyone done anything like this, or does anyone have any thoughts?
The cleanest solution would be send off a http request server side, then render the html into your page as you require, this will also require changing all the urls of content and links to be absolute
eg:
<img src="\images\banner.png">
will work on the remote server, but once inside your page, the image will not exist. The most workable solution would be limit the functionality to images and links, then do a find / replace with regex to match relative urls and add the source address to it.
You will however run into legal issues if you are resending other peoples content from your server, even just html.
Using an iframe would be the quick dirty solution and probably have the least legal ramifications, as the browser sends a normal request to the site for the content.
I'd recommend DocRaptor for generating PDF files from HTML. It works in a similar fashion as wkhtmltopdf, but produces fully functional PDF files.
Here's a link to its homepage:
http://docraptor.com/
And a link to its API documentation:
http://docraptor.com/documentation
Is there anyway to hide .swf path showing up from webpage?
you can use a php script something like getswf.php?name=flash.swf in your flash tags. Then create getswf.php script to respond with output of flash.swf file, and keep flash.swf file in a directory outside of public directory.
There may be ways to make it difficult to view. However, nothing you do can stop an intelligent adversary from using a tool like Fiddler to monitor web traffic and undo all your obfuscation.
I think this is a fairly pointless exercise. Any resource that gets sent to a browser, be it an image, sound, flash movie, even flv files loaded by the YouTube player, can all be saved to disk fairly easily.
As Justin mentions, Fiddler can achieve this easily.
As others answered it there are ways to do it using your script. If you are looking for a paid option check this out Media Vault.
Hiding the URL to the swf file might be quite a challenge but there are other things you can do if you're wanting to more closely protect the video/data being displayed by the swf.
I'll run through a couple of ideas in the order I think them most obfuscated with the least first. Bare in mind that most of these techniques merely make it harder to get to the information/video rather than making it impossible to obtain.
The main idea most sites tend to follow is that of having the swf as a player and the content in another file somewhere else, usually an flv or mp4 etc.
Add flv location through Javascript
This technique is as basic as it sounds. You have your swf player on the page and pass a new variable too it (such as 'file') with the location to the flv file using Javascript. If you're already loading your content with some kind of JS flash module then all the easier to begin implimenting.
Obfuscating flv location through XML
Another techniqe I've seen used quite recently is that of having an XML document as a paremeter to the swf player and then the flash player itself resolves the URL of the flv from a node in the XML. It's easy to get to the flv URL if you want to but it does make it that little bit harder.
Token access
This technique can be used in conjunction with any of the above two. You basically ensure that your flv files can only be accessed with the use of a special token otherwise the page returns a HTTP error. The token would be understood by the flash player and the server and upon the player making a request for the flv, a token must be included (usuallu the token itself is obfuscated in some way that it cannot be easily mimmicked through a simple GET request).
Domain access
Very similar to the above however in this case, the flv file will only be loaded when the requesting URL is a specific site. All other requests will be denied (such as directly hitting the flv location in your browser.
As stated above, none of these methods make it impossible to get hold of your flash material. If it's on the web (or any network for that matter), it's possibly a target. You'll usually find for most things that making it harder to obtain will deter a lot of those who would otherwise have been privy to downloading your content.
Completely hiding the URL to the swf
If your only criteria is to hide the URL then hiding it behind a URL rewrite is the best option I can think of.
Your swf might be at /location/flash/player.swf?file=summer.flv and then you could do a URL rewrite to something like /vacations/summer2011/.
This way the URL to the swf is completely hidden away and this should satisfy your desire to hide the swf path.
The answer is NO.
You may not want to believe it. but it is a fact. you can do all you like to obfuscate it. but the browser needs to find it. if the browser can find it so can anyone else.
A server side script that acts as a loader will hide the real path to the file, but to what purpose. the end result is the file is still available.
If you want a simple answer, so simple people can't find it then the people here have given you some suggestions. obfuscation is the best you can hope to achieve.
Alternately only allow approved users access to the file. that way they need to log in to get access to it. but if you want it available publicly then its well, public!
DC