I recently came across this app (I know there are many others like it too)
Thought I’d give it a try with one of my galleries. The first was password protected and the app did not sucessfully download anything.
Next I tried a non protected gallery, the results, my whole site was downloaded. Fortunatley for any gallery that was password protected the app was only able to grab 1 gallery thumbnail but for non protected sites evrything was grabbed (in full resolution plus all the admin files)
I guess my main point if this post is to warn fellow users of Backlight about these apps, epsecially for those generating revenue and to password protect their property.
The other… is there any way of stopping these apps in backlight settings?
Just to note I am still on BL3, so this might have been addressed in subsequent versions.
One other quick question. When I set a password for galleries, rarely does it retain the password.
Say for example if I revisit the gallery a few days later the password is @incorrect@ and I have to reset it in publisher settings.
Can you create a non-sensitive album that exhibits this problem and share it and the password to that @Ben and @Matthew will have something to look at.
Hi @kim_uk1, Backlight doesn’t have a mechanism for blocking scrapers. The current design makes it difficult to do so, as asset requests are handled directly by the web server and do not pass through Backlight code. At best some Backlight mechanism could try to stop users visiting too many galleries in quick succession. Third-party products exist to intercept automated traffic like this. Can you see if there are any firewall rules or plugins on your host that can be enabled?
What do you mean by ‘all the admin files’?
In my experience, browsers do a poor job of handling password retention on Backlight. I’ve found that they see different password fields and try to link them to the same account, with stored access codes clobbering the stored login details for my Backlight admin. My personal solution is to instruct the browser to never remember passwords for my site, then use a combination of easy-to-type passwords and 2FA. It’s not ideal.
Thanks for the link to your gallery (I’m now wishing I was on a skiing trip!).
I see that the Access Code fields have autocomplete="off" and that there’s no option to change that in Backlight. @Matthew, do you remember if there was a reason for this?
I vaguely recall there was a reason for it, but I do not remember the specifics. Maybe something to do with not wanting to auto-fill passwords, for example, if someone else is using your computer.
Anyway, I would never make autocomplete a user-configurable option.
Thanks for the reply, the detail you provide is very much appreciated. Regarding ‘Admin Files’ after closer inspection, the app hasn’t managed to grab any sensitive information like passwords.
Publishing on the web means making the content publically available. Trying to fight this isn’t going to work. Thus, site scrapers are not going away.
Content protection means copyrights. Watermarks are good to help the viewer realize the source of the content. You can also put your copyright mark into the watermark. Another thing, do not publish hi-resolution images usable for printing. Making smaller images is also good for a speedy website.
Web servers can detect suspicious behavior such as a site scraper downloading multiple images in rapid sequence. That could trigger “rate limiting” to stop the scraping operation. Most web servers have this ability. If your hosting service provides this is something to consider when choosing your provider. You can then run into false positives, which annoy your visitors. To avoid completely shutting them out, you could use a CAPTCHA (still annoying real visitors). No matter what you’ll never win this battle. They simply schedule to scrap a few pages over time and still get everything.
Attempting to prevent this activity isn’t something to look for in Backlight. It’s not serving the images to the scraper. If Backlight were to try to do something, it would likely best be done as “content obfuscation.” But this has drawbacks that can complicate the site, and possibly impact SEO. You have to work out a scheme at the web server.
I watermark all my images for sale with a cross hatch grid. I also don’t upload anything in hi resolution, at least not high enough to print anything bigger than 5x7.
Web servers can detect suspicious behavior such as a site scraper downloading multiple images in rapid sequence. That could trigger “rate limiting” to stop the scraping operation.
Interesting read. I think the best advise is the one to not upload high resolution photos. I’ve been having problems lately updating Backlight pages. When I do frequent page reloads to check formatting changes the site eventually crashes and times out for several minutes. Until recently this never happened. My hosting company says it’s because I’m on an old server (which I’m going to upgrade soon) but I wonder if it’s the above mentioned ‘rate limiting.’ Has anyone else run into this problem lately?
The problem here is that high-resolution displays – Apple’s “Retina” displays, and similar high-density displays which are now the norm for many brands – demand higher resolution images. Providing 1x size images to these displays results in soft, zoomed-in images.
For example, displaying a 1000px image on a 2x display at the perceived size of 1000px (that you would expect), you are actually scaling that image to 200%. That makes it soft. To get sharp images on a 2x display, then you need to use 2x images; for your 1000px image to be displayed crisp at a perceived size of 1000px on screen, the image itself should be 2000px. Which is lousy for anyone relying on low-resolutions for security purposes.
