Community @ The Turning Gate

Support community for TTG plugins and products.

NOTICE

The Turning Gate's Community has moved to a new home, at https://discourse.theturninggate.net.

This forum is now closed, and exists here as a read-only archive.

  • New user registrations are disabled.
  • Users cannot create new topics.
  • Users cannot reply to existing topics.

You are not logged in.

#1 2017-11-12 06:12:45

JimR
Member
Registered: 2012-11-30
Posts: 348
Website

Hotlink prevention

I get sites that are linking to my images, and I'd like to block this. Usually there's a cPanel to add hotlink protection. This simply writes a few rules into the htaccess file.

I was reading this article.  https://perishablepress.com/creating-th … -strategy/

I want to understand what potential conflicts with Backlight I could be creating by using hotlink protection.

I also created a 403 error page, and would like anyone hotlinking to get that permission error. Or I could create a custom image to replace targeted image (e.g. "no hotlinking allowed)

What's the best strategy, and the htaccess rules, for this?

Last edited by JimR (2017-11-12 06:19:27)


--Jim

Offline

#2 2017-11-12 11:07:37

Matthew
Administrator
From: San Francisco, CA
Registered: 2012-09-24
Posts: 5,795
Website

Re: Hotlink prevention

That's an impressively comprehensive article! I skimmed it, but will have to go back later to give it a thorough read.

I'm not sure the rules to use, but the nice about .htaccess is that you can try rules, and if they cause problems, just remove them. You won't do permanent damage.

Look for anything to block cross-origin or cross-domain access to your images. Backlight and your images and your Wordpress site all live on the same domain, so blocking cross-domain access, in theory, should not impact them.

Ben might be able to give some advice about how to go about it without conflicting with what the publisher needs to do, but it might not even be an issue.


Matt

The Turning Gate, http://theturninggate.net

Offline

#3 2017-11-12 20:11:21

Ben
Moderator
From: Melbourne, Australia
Registered: 2012-09-29
Posts: 4,399

Re: Hotlink prevention

I've read through the article.  The code in the initial 'Conclusion' section should not affect Backlight (after changing 'domain' to your own domain).

However, the effect of the code for image protection won't necessarily be what you're looking for.  One one hand, it's fairly heavy-handed, so may block some referrers that you'd rather allow, such as results from search engines.  To improve on that, see the extra HTTP_REFERER entries mentioned further in the article.
On the other hand, the article was written in 2012.  With the Internet being a moving target, the recommended code may not be as bulletproof as it once was.

Offline

#4 2017-11-13 14:55:53

JimR
Member
Registered: 2012-11-30
Posts: 348
Website

Re: Hotlink prevention

Ben wrote:

One one hand, it's fairly heavy-handed, so may block some referrers that you'd rather allow, such as results from search engines.  To improve on that, see the extra HTTP_REFERER entries mentioned further in the article.

Yup - I caught that too. I don't mind a search engine showing my photos. I actually enjoy that. They'll serve up their own copies. I just didn't want people hotlinking.

Ben wrote:

On the other hand, the article was written in 2012.  With the Internet being a moving target, the recommended code may not be as bulletproof as it once was.

Yup - I caught that too, which is what prompted my question.

To add even more to the mix, I've setup CloudFlare as my caching service. It's great. I also notice it's causing some funny interactions with htaccess. I had written hotlinking protection into htaccess and it was being ignored. I then found out CloudFlare has its own hotlink protection.

I'll dig some more and update this thread.


--Jim

Offline

#5 2017-11-13 19:16:40

Ben
Moderator
From: Melbourne, Australia
Registered: 2012-09-29
Posts: 4,399

Re: Hotlink prevention

Hi Jim, have you been using CloudFlare during the time your site was acting strangely and 'corrupting' the db?  That service has been known to interfere with Backlight.

Offline

#6 2017-11-14 08:47:11

JimR
Member
Registered: 2012-11-30
Posts: 348
Website

Re: Hotlink prevention

Ben wrote:

have you been using CloudFlare during the time your site was acting strangely and 'corrupting' the db?  That service has been known to interfere with Backlight.

The corruption idea was just an idea. Turns out nothing was actually corrupted. I was just getting the strangest things happening, but that was just once and I can't reproduce what ever problem that was.

I've used CloudFlare for many years. It's fantastic, and makes the site much faster. While editing files you have to enable the Developer mode, which turns on caching new/edited files. There's lots of other things to know. I haven't had any problems, once it's all setup.

I have a support ticket into CloudFlare, asking how hotlinking protection is being interfered within htaccess. Once I learn more about that, I can share what I've found. Other than this, I haven't seen any problems. The general issue is just that it's a cache, and while developing the site you have to constantly be concerned if your edits are taking effect or if you're still reading from the (unchanged) cache. I have this same problem with my hosting service's caching, and even my browser's cache.

What problems with CloudFlare do you know about?


--Jim

Offline

#7 2017-11-14 11:19:17

Ben
Moderator
From: Melbourne, Australia
Registered: 2012-09-29
Posts: 4,399

Re: Hotlink prevention

That's why I put 'corrupted' in quotes.
The main problem customers have had with CloudFlare has been that Backlight logins haven't worked.  I have not looked into Cloudflare myself and have only ever advised to disable the service.  It sounds like developer mode may solve that problem.  I'll try to find time to have a play with CloudFlare.

Backlight has a further level of caching to also think about smile

That would be great if you could continue to share your insights on CloudFlare.

Offline

#8 2017-11-14 17:37:15

JimR
Member
Registered: 2012-11-30
Posts: 348
Website

Re: Hotlink prevention

Ben wrote:

Backlight has a further level of caching to also think about

Oh? I didn't know about this. Probably the biggest source of false problems for me has been due to caching. I'll be making changes, and then not finding the change. Eventually it dawns on me I'm looking at the previously cached data.

What are the details about how Backlight caches? Is there a way to temporarily disable it for development?

Ben wrote:

That would be great if you could continue to share your insights on CloudFlare.

I've used it for many years. It's also my DNS service, because they can do a better job with caching that way. Plus, they have good security to prevent DoS attacks, etc. They also provide a SSL cert, so I have https to my site.

The service has grown a great deal since I first signed up with them. Many hosting services have agreements with them to provide free caching. This is typically a cpanel add on.

I went the extra step of using them as my DNS. Still, it's a free service and has tremendously boosted my site's performance.

I would read through their docs https://support.cloudflare.com

Maybe start a new thread on CloudFlare. I'll join and answer any questions that show up.


--Jim

Offline

#9 2017-11-14 18:15:26

Ben
Moderator
From: Melbourne, Australia
Registered: 2012-09-29
Posts: 4,399

Re: Hotlink prevention

JimR wrote:

What are the details about how Backlight caches? Is there a way to temporarily disable it for development?

The way Backlight works is that it operates on two levels of PHP.  When elements of a page have changed, a whole bunch of PHP is run, to generate a cached file, saved under backlight/data/designer/cache.  Those templates include unprocessed PHP that is executed upon page load, for dynamic elements such as adding photos into a template.  The first process is much heavier than the latter, so by using the cached files, performance is greatly increased (which in itself isn't quite true, since we designed it that way, so it was never slowed down by a lack of cache).
The same process is used for the dynamic CSS and JS files. 

Backlight does a pretty good job at removing files from the cache when various settings change, such as through Designer or changing the menu structure.  There are some edge cases though, such as those related to embedded albums.  Our advice is to visit Designer > Templates > Clear Template Cache if something gets stuck.

This caching can be bypassed entirely by copying the file backlight/env.php.skel to backlight/env.php and uncommenting the SKIP_CACHE line so that it looks like:

define('SKIP_CACHE', true);

Other options can be found be appending the ?help parameter to a URL, e.g. http://yoursite.com/galleries/album/?help  They include the skipCache and reCache parameters.  Note that they only affect the cache for the page you're visiting and not the caching of the dynamically-generated linked JS and CSS files.  Note also that some of the other special parameters can have odd effects, such as adding debug entries into the generated cached file..

JimR wrote:

Maybe start a new thread on CloudFlare. I'll join and answer any questions that show up.

That would be great.

Offline

Board footer

Powered by FluxBB