I had given up on protecting online images since even disabling the easiest ways to get at images still left people the option to use Inspect, then Sources, and poke around in the folders until they found the right file, hey, presto.
The only real way to get around that was to break the image up into tons of fragments so you're just depending on people not being able to code and getting bored with the idea of putting the image back together.
This site, however, has a public domain image that has somehow truly blocked the Inspect hack: The image appears within Inspect (d7... folder, 3rd image) but any attempt to open or download that image just produces useless "download" files instead of the actual image. How'd they pull that off? and why isn't it more common? How expensive/time consuming would it be to implement for online image databases?
The image appears within Inspect (d7... folder, 3rd image) but any attempt to open or download that image just produces useless "download" files instead of the actual image.
I managed to download it (using qutebrowser) by opening in new tab. The filename was qwe_download.
When i opened the image in my file manager (Thunar), it showed as WebP image.
I used feh (image viewer) and it was exactly the image.
Maybe use WebP compatible image viewer to open the file.
Related
I have minimal knowledge of coding but I just spent the past 6 hours trying to resolve this issue.
Go here to see the image I am trying to have load.
If I am suppose to chance the SRC lines, how and where do I do that?
The HTML image loads perfectly from my computer.
Like what #mlegg said, I get the same error when trying to go to your link. It looks like that is no longer a valid URL or there is some form of security on it so it's only accessible from your computer (since you said it works from your computer?).
It could also be getting pulled from your browser cache if it was a good URL at one time. Try doing a Shift + Refresh of the page or purposely clear your cache.
If you have the image locally you could try uploading to a different web based repository and src it from there.
Just to cover all bases, I trust you know how to put an image on a web page using the img tag:
<img src="http://lorempixel.com/400/200/">
You might also want to try a different image that you know is available and accessible. You can use the URL above for lorempixel.com or you can scrounge up a different image from a Google Images search.
I have a really simple piece of CSS which is applying a background image to <li> elements
.icon-facebook { background: url("./images/icon_facebook.png") no-repeat; }
This works fine when I view it locally, without a web server, i.e. by double-clicking the .html file.
But as soon as I serve the same page via Apache - whether on localhost or a production server - the background images disappear.
Other background images on the page work fine - and all have identical (relative) paths.
Specifying an absolute path to the background-images does not work either.
Renaming the files did not work.
The images can be displayed just fine if navigated to directly in the browser.
Monitoring Apache's access log, the browser doesn't even attempt to request the images (!), even if an absolute URL is supplied in the CSS.
When I inspect the <li> Firebug says "could not load the given URL" but when I copy and paste the background-image URL straight from the CSS in Firebug into a new tab - guess what? It works.
I have a <div> on the same page with a different background image from the same folder which works just fine. When I replace its filename with one of my "problem" files I notice it isn't displayed any more.
The images in question are 20x20px PNGs (but I tried JPGs too).
All other browsers work fine.
This is truly driving me crazy.
Unbelievable. Truly unbelievable.
The culprit was Adblock Plus, which I had installed on Firefox but not any other browser. It was interpreting the names and/or class names of the background images as being either advertisements or social media annoyances, and therefore silently blocking them.
I had previously added my production domain to its white list, but when it changed I forgot to update it.
That explains why some image filenames worked (e.g. icon_f.png whereas others - icon_fb.png or icon_facebook.png - did not).
Let this be a lesson - do not run any kind of addons on your development browser.
I was ready to cry... and think I will now. Cry for my stupidity.
Thank you to all for your input.
Specifically, the culprit is Fanboy's Social Blocking List, which is one of the filter subscriptions included in Adblock Plus. It has already caused me a lot of distress in the past.
To disable it, click on the Adblock Plus toolbar button and choose Open filter preferences. You'll then find the list of subscriptions and you can simply unsubscribe to that one.
It's better than disabling Adblock Plus completely so you can continue using it for what it was originally intended: blocking ads.
Is there a way to disable a user from downloading a file from a URL?
For example I have a link:
wow.mywebsitedomain.com/templates/filename.svg
I want to disable the user from downloading the filename.svg
These svg files are not just an image, they are editable designs that I have spent countless hours on each. No, I do not care if someone does a screenprint or gets a png etc, as those are not scalable, editable, vector files.
When the user clicks on a png thumbnail my actual link opens my online design editor to allow the user to customize these files, then save to my server, then purchase printed media, and they are not allowed to download any files.
I tried putting the actual files into a password protected folder on my server, but they do not open properly, and I do not want the user to have password access to this folder.
Essentially I need the link to be accessible, just not show the actual link for someone to copy and open/save/download etc.
Hopefully there is a simple solution for a non-programmer with basic html skills?
Thanks
Your can do things like "disabling right-click" and stuff - it may prevent some users from downloading your file, BUT basically you cannot prevent a file which is downloaded and interpreted by the browser from being downloaded to a user's hard drive.
This is not only true for SVGs, but also for music, videos, etc.
Instead, you can convert your SVG file to a PNG on server-side, and show only the PNG to the user. Note that you have the possibility to create PNGs of different sizes on the fly - dependent on the request, user's screen resolution, etc. You can also implement caching of the generated PNGs if needed.
On how to create a PNG from SVG in PHP read here:
Convert SVG image to PNG with PHP
You can choose other raster image format, of course.
If they can view it, they can download it. End of story. If you only want them to see a PNG, make a PNG from it and put that up
My understanding is; if you can see it, you can download it,
I have a web application, where i am storing all the images in a folder which is totally outside WEB-INF folder or webroot folder. When the jsp to display the image is called, before displaying it, i am moving the concerned image files to WEB-INF/images folder and then setting the path in the html IMG tag. My question is
Is this good design?
Also even though the image is moved to WEB-INF/images folder, the page does not display the image always, it displays sometimes and sometimes it doesnt. I dont know how to debug this problem.
I am using springs and spring security.
This is not a very good design. In many cases, server will cache web application data so if the image was not there it will never find out that it appeared in place. That's, probably, causing the inconsistency that you observe as there may be other factors affecting caching.
The right choice would be to provide a servlet that serves your image data upon request from the file.
I have a basic webpage that references four image files using the following code:
<img src="/images/SanFran.jpg" name="urbanForm" alt="urbanFormA" width="150" height="100"/>
(I change SanFran.jpg, to London.jpg, NewYork.jpg and Barcelona.jpg - just replacing the filename)
However, although the 4 jpegs are very similar (200 x 150 pixels) and made using a similar technique (cropping an image in Picassa), only one of the files will load (London.jpg). The other three give me a broken link message. I have checked that I am do not have misspellings numerous times, and cannot find the problem.
Is there anything that I have not considered?
(I'm using Aptana Studio on OSX and viewing it using Safari as a previewer; the same problem exists if I look at it using Firefox or Chrome)
Are all the images in the same directory?
Make all the file names lowercase, so you know that isn't the issue.
double check extensions, "jpg or jpeg or JPG or JPEG"
take it back to basics <img src="images/filename.jpg" />
Try naming one of the others
SanFran.jpg. See what happens.
Might give you a clue.
Open them all in windows explorer,
confirm the images themselves load
normally and aren't corrupt.
Check all are in /images/
right click on the broken link and
choose view image or copy image
location. See if where it's trying
to access is definitely the right
place.
Do the same with the working one.
Compare and see if any differences.
change everything to lowercase, just
in case (excuse pun)
hit ctrl+shift+reload a few times,
and F5 a few times.
clear cache manually if you know how
or have the tools.
Copy it to a different loacation and
try loading them there. Ideally a
different computer.
Upload it somewhere and see if it
works in your browser when online
Hopefully one of those may help...
If you know the files are there, make sure the case of the filename matches (s is different than S on Linux), and then make sure .jpg is the proper extension and not .jpeg.
It could be because your Jpegs are saved as CMYK as oppose to RGB. See this link for more detail. However this would only affect some browsers
http://www.plaveb.com/blog/cmyk-images-not-displayed-in-internet-explorer
Open the images in Photoshop and resave in RGB color format (just incase it's CMYK). Known issue in some legacy browsers, not sure when or if it went away.