Dirty and Quickie deep linking prevention

George Notaras gnot at g-loaded.eu
Sat Sep 26 02:05:36 EEST 2009


rouvas at di.uoa.gr wrote:

>>> Ginetai kai me to mod_rewrite tou Apache, kapos etsi:
>>>
>>> <IfModule mod_rewrite.c>
>>>   RewriteEngine On
>>>
>>>   RewriteCond %{HTTP_REFERER} .*myspace.*
>>>   RewriteRule  .*                 /dont-link-to-me  [G]
>>>
>>>   RewriteCond %{HTTP_REFERER} .*hi5.*
>>>   RewriteRule  .*                 /dont-link-to-me  [G]
>>>
>>>   RewriteCond %{HTTP_REFERER} .*youtube.*
>>>   RewriteRule  .*                 /dont-link-to-me  [G]
>>> </IfModule>
>>>
>>> sto .htaccess tou directory.
>>>
>> Με αυτό όμως πιάνεις όλα τα links από τα παραπάνω sites...
> 
> Αυτός δεν ήταν ο στόχος;

Από ό,τι κατάλαβα, ο Ρικούδης δεν ήθελε από τρίτα site να κάνουν
απευθείας linking σε κάποια φωτογραφία, ώστε να μην του τρώνε το
bandwidth, ενώ η φωτό θα φαινόταν σαν να είναι hosted στο τρίτο site.


>> Το παρακάτω είναι νομίζω καλύτερο και επιστρέφει και πιο χρήσιμο error
>> code:
>>
>> <IfModule mod_rewrite.c>
>>   RewriteCond %{HTTP_REFERER} !^http\:\/\/DOMAIN\.TLD\/
>>   RewriteRule \.(jpg|jpeg|png|gif)$ http://DOMAIN.TLD/stopleeching.html
>> [R=302,L]
>> </IfModule>
>>
>> Δεν είμαι σίγουρος ότι χρειάζεται escaping o referrer.
> 
> Μου φαίνεται ότι το [G] γυρνάει 410 που σημαίνει "Gone", ενώ το 302
> σημαίνει "Found". Θεωρητικώς, αν το "βρει" (το .jpg) (302) δεν έχει λόγο
> να σταματήσει να το "ζητάει" οπότε θα συνεχίσουν να έρχονται αιτήσεις προς
> το resource σου στον server *σου* που θα πρέπει να αναλώσει πόρους να τις
> εξυπηρετήσει.
> 
> Αντίθετα, εάν η απάντηση είναι αρνητική ως προς την ύπαρξή του (410=Gone),
> θεωρητικώς πάλι, οφείλει να μην σε ξαναενοχλήσει. Οπότε τη γλυτώνει ο
> server σου.
> 
> Πρακτικώς τώρα, καθώς μου έτυχε να δέχομαι χιλιάδες hits την ώρα προς
> συγκεκριμένες εικόνες, δε νομίζω ότι λαμβάνει κανείς(=λογισμικό) υπόψη του
> ότι και να του γυρίσεις. Η κατάσταση διορθώθηκε όταν άλλαξε URL στις εν
> λόγω εικόνες.
> 

Βάζω το 302 με το εξής σκεπτικό:

Αν η φωτο (ή οποιοδήποτε αρχείο) είναι κάτι αξιόλογο, λογικό είναι να
μην θέλουμε να εμποδίσουμε τα indexing bots από το να το βρουν και να το
κάνουν index.

Αν στο παραπάνω rewrite rule χρησιμοποιήσουμε το 410 error code, τότε το
bot, όταν φτάνει στο αρχείο μέσω των δικών μας links, θα παίρνει
response 200 (ΟΚ), ενώ, όταν φτάνει μέσω links τρίτων ή απευθείας (χωρίς
referer), για το ίδιο location θα παίρνει το fatal response 410 (GONE).

Σ' αυτή την περίπτωση θεωρώ το 302 (temporary redirection) καλύτερη
λύση, καθώς είναι σαν να λέει στο bot: "το αρχείο βρέθηκε, αλλά
προσωρινά βρίσκεται σε άλλο location".

Αντίθετα, αν η φωτο ή το οποιοδήποτε αρχείο δεν είναι αξιόλογο ή απλά
δεν μας ενδιαφέρει αν θα μπερδέψει τα indexing bots ή όχι, αλλά από την
άλλη βάζουμε ως πρώτη προτεραιότητα να μην μας καταναλώνουν οι άλλοι το
bandwidth άσκοπα, τότε το 410 μου φαίνεται λογική λύση (χωρίς να είμαι
ειδικός για να κρίνω).

Οπότε καταλήγω στο συμπέρασμα ότι το response code θα πρέπει να μπαίνει
κατά περίπτωση, ανάλογα με το τι επιδιώκει κανείς. Εγώ είχα στο μυαλό
μου μια εντελώς διαφορετική περίπτωση από αυτή που ανέφερες παραπάνω.


Παρακάτω για πληροφοριακούς λόγους παραθέτω την επεξήγηση των codes 410
& 302 (από http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html):

410 Gone
--------
The requested resource is no longer available at the server and no
forwarding address is known. This condition is expected to be considered
permanent. Clients with link editing capabilities SHOULD delete
references to the Request-URI after user approval. If the server does
not know, or has no facility to determine, whether or not the condition
is permanent, the status code 404 (Not Found) SHOULD be used instead.
This response is cacheable unless indicated otherwise.

The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that remote
links to that resource be removed. Such an event is common for
limited-time, promotional services and for resources belonging to
individuals no longer working at the server's site. It is not necessary
to mark all permanently unavailable resources as "gone" or to keep the
mark for any length of time -- that is left to the discretion of the
server owner.


302 Found
---------
The requested resource resides temporarily under a different URI. Since
the redirection might be altered on occasion, the client SHOULD continue
to use the Request-URI for future requests. This response is only
cacheable if indicated by a Cache-Control or Expires header field.

The temporary URI SHOULD be given by the Location field in the response.
Unless the request method was HEAD, the entity of the response SHOULD
contain a short hypertext note with a hyperlink to the new URI(s).

If the 302 status code is received in response to a request other than
GET or HEAD, the user agent MUST NOT automatically redirect the request
unless it can be confirmed by the user, since this might change the
conditions under which the request was issued.

      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
      to change the method on the redirected request.  However, most
      existing user agent implementations treat 302 as if it were a 303
      response, performing a GET on the Location field-value regardless
      of the original request method. The status codes 303 and 307 have
      been added for servers that wish to make unambiguously clear which
      kind of reaction is expected of the client.



More information about the Linux-greek-users mailing list