Forse non a tutti i web surfer è noto il termine hotlinking, conosciuto anche come deep linking o inline linking. In parole povere è la pratica, ormai largamente diffusa, di inserire un contenuto (immagini soprattutto) sul proprio sito/blog facendo riferimento al file hostato su un dato server, ovvero linkando in modo diretto il file in questione e consumando così la banda del server ospitante il file.

Tale "tecnica", se vogliamo chiamarla così, diventa dannosa quando vi è un grande afflusso di accessi a quel file o alla pagina in cui viene visualizzato tale file.
In genere l'hotlinking avviene per pigrizia o per una mentalità di condivisione globalizzata; fatto sta che taluni si vedono succhiare la banda e magari non ne capiscono il motivo. Una soluzione sarebbe prendere il contenuto voluto e riupparlo su un altro server, a seconda della tipologia del file (image hosting, file hosting ecc.) . Certo, anche nei miei post sarà capitata un'immagine hotlinkata sebbene generalmente cerchi sempre di uppare i miei contenuti su Imageshack (immagini) o direttamente su Wordpress.

Ma volendo, è possibile bloccare gli hotlinker. Tuttavia devo precisare che per riuscire in questo intento è necessario l'utilizzo di un server Apache (per esempio chi crea un sito su Altervista è già a posto).

Procedendo, dovete editare (o creare talore non fosse presente) il file .htaccess presente nella root del vostro sito aggiungendo queste righe:

RewriteEngine On
RewriteCond %{HTTP_REFERER} !^http://(www\.)?vostrosito\.com/ [NC]
RewriteCond %{HTTP_REFERER} !^$
RewriteRule \.(jpe?g|gif|bmp|png)$ images/stophotlink.jpg [L]

Ora non vi resta che sostituire a vostrosito\.com l'indirizzo del vostro spazio web e a images/stophotlink.jpg l'indirizzo dell'immagine che apparirà al posto dell'immagine che ha subito l'hotlinking.
Se pensate di poter far danni modificando il file fatene una copia di backup.

Operando in questo modo l'immagine hotlinkata non verrà più visualizzata sul sito che ne fa uso.

Alla prossima
Some references to: Giovy.it

Note: You will need some knowledge of Apache's rewriting engine to implement, including an .htaccess file with RewriteEngine On.

Redirect root requests (excludes internal pages) to an iPhone page

RewriteCond  %{HTTP_USER_AGENT} ^.+iPhone
RewriteCond  %{REQUEST_FILENAME} !.*iphone.html
RewriteRule  ^$ /iphone.html [L,R=301]

Redirect all requests (includes internal pages) to an iPhone page

RewriteCond  %{HTTP_USER_AGENT} ^.+iPhone
RewriteCond  %{REQUEST_FILENAME} !.*iphone.html
RewriteRule  ^.*$ /iphone.html [L,R=301]

Redirect all requests from a directory to an iPhone page

RewriteCond  %{HTTP_USER_AGENT} ^.+iPhone
RewriteCond  %{REQUEST_FILENAME} !.*iphone.html
RewriteRule  ^/directory/?(.+)?$ /iphone.html [L,R=301]

Redirect all requests to a corresponding file in an iPhone directory

RewriteCond  %{HTTP_USER_AGENT} ^.+iPhone
RewriteCond  %{REQUEST_FILENAME} !.*iphone
RewriteRule  ^(.*)$ /iphone/$1 [L,R=301]

Instead of using id's in the URL we are going to use the page title. We will not include the id of the object in the URL because if we had to do that, this wouldn't make it easier to navigate through since you have to know both the id and title of the object. In this post we will take a look at how we can use a game title instead a game id in our URL. The visitors of the site can easily guess the title of the game and just type it in!

Then end result will look something like this:

http://www.dosspot.com/games/sam-and-max-hit-the-road/

Looks nice? It looks a lot better than the current URL:

http://www.dosspot.com/details.php?gameid=1

So, here is what we need: A PHP function which takes a string and turn it into friendly chars we can use in our URL, a new column in our database table and finally some new lines in our .htaccess file.

OK, so what do we do with our PHP function? We keep it simple and effective. Anything not matching a char between a-z and A-Z or a number, 0-9, will be removed from the title. Every space we find we replace with a -.

Example: Command and Conquer: Tiberan Dawn will do. This title would be suitable as a URL. We use our function and it will look like this: command-and-conquer-tiberan-dawn. Simple, nice and really cool!

The implementation of this is not that hard. We extract and remove all bad chars in the title. It's very straightforward. Five lines of code:

function createPermaLink($string)
{
$string = preg_replace("/(:|;|-|\"|\/|\(|\)|\')/", "", strtolower($string));
$string = preg_replace("/(\s)/", "-", strtolower($string));
return $string;
}

We will use this function everytime we want to link to a game page. We will send the game title as the argument into the createPermaLink function and it will return a clean and URL friendly string back to us.

Next up we go to the MySQL database table we want to match our perma link with. We add a new coloumn named perma as a varchar length 100. We take the game title and use our newly created createPermaLink function and copy the text and paste it into the new database column. So, the database table might look like this:

ID Title                                                      Perma
1    Sam and Max Hit the Road             sam-and-max-hit-the-road

Now we are able to do a SQL statement and try to select the row with a Perma value matching the incoming perma value from the URL. To be able to send a perma via the URL we need to add lines to our .htaccess file. Again, very easy:

RewriteRule ^([a-z0-9\-]+)/$ /game.php?perma=$1 [L]

Here I have a rule saying: Anything that matches a-z chars or 0-9 integers or a - is valid and it's redirected to my game.php page with a querystring attached named perma with a value. The value in our case will be the game title transformed by our createPermaLink function.

So in our game.php file we simple write a SQL statement to fetch the corrent row with our Database class:

$perma = mysql_real_escape_string($_GET['perma']);
$result = $db->fetchQuery("SELECT * FROM games WHERE perma = '$perma'");

Pretty simple huh? The first line is just making sure that no hackers can break into our database and after that we use the $db object which is an instant of our Database class and we call our fetchQuery method to retrieve the row we want.

Three different areas we need to modify but only with very little code we are able to add the page title in the URL quite simple. The URL's is a lot nicer and SEO loves it!

# Customizable error response.  Three styles:
# 1. Plain Text - the (") marks it as text, it does not get output
#ErrorDocument 500 "The server made a boo boo.
# 2. Local Redirects - e.g. To redirect to local URL /missing.html
#ErrorDocument 404 /missing.html
#ErrorDocument 404 /cgi-bin/missing_handler.pl
# 3. External Redirects (All env. variables don't go to the redirected location)
#ErrorDocument 402 http://some.other_server.com/subscription_info.html

# Mosaic/X 2.1+ browsers can uncompress information on the fly
AddEncoding x-compress Z
AddEncoding x-gzip gz tgz

#Content negotiation directives
#AddLanguage fr .fr
# Just list the languages in decreasing order of preference.
LanguagePriority en fr it

######################################################################
# If the web server's AllowOverride allows INDEXES to be overridden  #
######################################################################
# DirectoryIndex, ExpiresActive, ExpiresByType, ExpiresDefault
# ImapBase, ImapDefault, ImapMenu
# FancyIndexing, IndexOptions, IndexOrderDefault, IndexIgnore, HeaderName, ReadmeName
# AddDescription, AddAlt, AddAltByEncoding, AddAltByType
# AddIcon, AddIconByEncoding, AddIconByType, DefaultIcon

# Default file to send to the client if none specified.  
# Separate multiple entries with spaces.
# If none of these files exists in a directory, a directory listing may
# be returned depending on Options Indexes setting.
DirectoryIndex index.html index.htm index.shtml index.php index.php3 index.pl index.cgi /cgi-bin/index.cgi

# Must enable expirations to use other expire directives
#ExpiresActive on
# 'M' means that the file's last modification time should be used as the base time
# 'A' means the client's access time should be used as base time
#ExpiresDefault M604800
# Expire GIF images after a month in the client's cache
#ExpiresByType image/gif A2592000  
# HTML documents are good for a week from the time they were changed, period     
#ExpiresByType text/html M604800  
#ExpiresByType text/html "access plus 1 month 15 days 2 hours" 
#ExpiresDefault "modification plus 5 hours 3 minutes" 
#ExpiresByType text/html "now plus 1 month 15 days 2 hours"

# ImapMenu can be none, formatted, semiformatted, unformatted
ImapMenu semiformatted
# ImapDefault can be error, nocontent, map, referer, or some useful URL.
#  The .map file overrides this.
ImapDefault map
# ImapBase can be map, referer, URL.  The .map file overrides this.
ImapBase referer

############## THIS HERE IS NOT TOO IMPORTANT! ###################
# Apache version dependent.  If Options indexes is allowed, Server will behave as follows:
#IndexOptions FancyIndexing FoldersFirst NameWidth=* DescriptionWidth=*
#IndexOptions FancyIndexing NameWidth=*
#IndexOptions +IconHeight=20 +IconWidth=20 +IconsAreLinks
#IndexOptions +ScanHTMLTitles
#IndexOptions +SuppressColumnSorting 
#IndexOptions +SuppressDescription 
#IndexOptions +SuppressLastModified 
#IndexOptions +SuppressSize 
#IndexOptions SuppressHTMLPreamble
# Sort by Name, Date, Size, or Description? Default is name.
#IndexOrderDefault Ascending Name
# Don't list these files
#IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

# Server .conf should already have set these up.  You should only set
# the missing ones in .htaccess files (if you ever find out)
#AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
#AddIconByType (TXT,/icons/text.gif) text/*
#AddIconByType (IMG,/icons/image2.gif) image/*
#AddIcon /icons/binary.gif .bin .exe
#AddIcon /icons/text.gif .txt
#AddIcon /icons/uuencoded.gif .uu
#AddIcon /icons/hand.right.gif README
#AddIcon /icons/folder.gif ^^DIRECTORY^^
#AddIcon /icons/blank.gif ^^BLANKICON^^
# If no file type matches..
#DefaultIcon /icons/unknown.gif
#AddDescription "GZIP compressed document" .gz
AddDescription "Java class file" .class
AddDescription "Java source file" .java
AddDescription "Java Server Pages source file" .jsp
# Server writes the contents of HeaderName file before the directory listing by adding .html or .txt to the specified name.
# Server writes the contents of ReadmeName after the directory listing.
# The server looks for the-specified-name.html, then the-specified-name.txt
ReadmeName README
HeaderName HEADER
############## END OF NOT-TOO-IMPORTANT ###################

######################################################################
# If the web server's AllowOverride allows LIMIT to be overridden    #
######################################################################
# order, allow from, deny from, allow from env, deny from env

# Controls which domain name or computer host client can get stuff from this server.  
# No space between allow and deny in order (just comma).  allow from all is default
#order allow,deny
#deny from all
#deny from www.yahoo.com
#allow from www.yahoo.com
# The allow from env directive controls access to a directory by the existence
# (or non-existence) of an environment variable. Example: 
# BrowserMatch ^KnockKnock/2.0 let_me_in
# 
#     order deny,allow
#     deny from all
#     allow from env=let_me_in
# 

######################################################################
# If the web server's AllowOverride allows OPTIONS to be overridden  #
######################################################################
# Options, XBitHack, CheckSpelling, Example - in order of importance

# Options:
# ExecCGI - Execution of CGI scripts is permitted
# FollowSymLinks - Server will follow symbolic links in this directory
# SymLinksIfOwnerMatch - Server follows sym links if target file/dir owned by the same user id as the link
# Includes - Server-side includes are permitted
# IncludesNOEXEC - Server-side includes permitted, #exec and #include of CGI scripts are disabled
# Indexes - Lists directory if no index file is found
# MultiViews - Content negotiated MultiViews are allowed. 
# Note that "MultiViews" must be named *explicitly* --- "Options All" doesn't give it to you.
# This here resets any previous settings
# Options IncludesNOEXEC MultiViews
Options Includes MultiViews
# Or, add/subtract from prior options
#Options +Indexes -Includes
# To disable execution of SSI and CGI in this directory
#Options -Includes -IncludesNOEXEC -ExecCGI

# Checks "user" execute permission on file.  If yes, executes it as SSI.
# Then, no need for special file extension .shtml
XBitHack on

# Matches document(s) if maximum one spelling mistake
# CheckSpelling  on

#Example directive is Apache API related for Apache programmers

######################################################################
# The following do not depend on AllowOverride setting at all        #
# These are either always available or need a loaded module          #
######################################################################
# Generally available:
# Satisfy, ServerSignature, LimitRequestBody
#  ... ,  ... 
#  ... ,  ... 
#  ... ,  ... 
# ForceType, SetHandler, RemoveHandler, AddDefaultCharset
# Optionally installed modules:
# CookieName, Header

# Satisfy any is used to password restrict an area, but to let clients from particular
# addresses as defined in 'allow from' to get in without prompting for a password. Default is "all"
#Satisfy any

# Access control by file name in a directory where .htaccess file is placed:
# The following lines prevent .htaccess files from being viewed by
# Web clients.  Since .htaccess files often contain authorization
# information, access is disallowed for security reasons.  Comment
# these lines out if you want Web visitors to see the contents of
# .htaccess files.  If you change the AccessFileName directive above,
# be sure to make the corresponding changes here.

    order allow,deny
    deny from all

# Can use reg exp  instead of line below.
#
#       order allow,deny
#       allow from all
#

# Optionally add a line containing the server version and virtual host
# name to server-generated pages (error documents, FTP directory listings,
# mod_status and mod_info output etc., but not CGI generated documents).
# Set to "EMail" to also include a mailto: link to the ServerAdmin.
#ServerSignature On
#ServerSignature EMail

# Specify cookie name to be used if CookieTracking is set to on.  Needs mod_usertrack installed.
# I specify this up in FileInfo overriding
# CookieName "woiqatty"

# To control denial-of-service attacks
LimitRequestBody 3000000

# For documents served through this directory, modify headers as follows:
# Can also be set, add.  Mod_header not generally available.
#Header append Author "V. Singla"   
#Header unset Author

################# For Apache Windows version only ######################

# use this to specify whether Apache should search windows registry
# or the #! line of the called script itself for interpreter name and location.
#ScriptInterpreterSource script
# Tries to match the called file's extension in registry (e.g. search registry for .pl or .cgi)
#ScriptInterpreterSource registry

############ END OF .htaccess FILE #############



.htaccess examples

Digest authentication is described in RFC 2617.

Directives

# AuthDBGroupFile

# AuthDBUserFile

# AuthDBAuthoritative

# AuthDBMGroupFile

# AuthDBMUserFile

# AuthDBMAuthoritative

# AuthDigestFile

# AuthDigestGroupFile

# AuthDigestQop

# AuthDigestNonceLifetime

# AuthDigestNonceFormat

# AuthDigestNcCheck

# AuthDigestAlgorithm

# AuthDigestDomain

# Using Digest Authentication

Using Digest Authentication

Using MD5 Digest authentication is very simple. Simply set up authentication normally, using "AuthType Digest" and "AuthDigestFile" instead of the normal "AuthType Basic" and "AuthUserFile"; also, replace any "AuthGroupFile" with "AuthDigestGroupFile". Then add a "AuthDigestDomain" directive containing at least the root URI(s) for this protection space. Example:

AuthType Digest

AuthName "private area"

AuthDigestDomain /private/ http://mirror.my.dom/private2/

AuthDigestFile /web/auth/.digest_pw
Require valid-user

Note: Digest authentication is more secure than Basic authentication, but only works with supporting browsers. As of September 2004, major browsers that support digest authentication include Amaya, Konqueror, MS Internet Explorer for Mac OS X and Windows (although the Windows version fails when used with a query string -- see "Working with MS Internet Explorer" below for a workaround), Mozilla, Netscape 7, Opera, and Safari. lynx does not support digest authentication. Since digest authentication is not as widely implemented as basic authentication, you should use it only in environments where all users will have supporting browsers.

Apache module mod_auth_digest

1. edit /etc/apache2/httpd.conf
2. Add RewriteEngine On
3. Add RewriteLogLevel 2
4. Add RewriteLog /var/log/apache2/rewrite.log
5. Add ServerSignature Off
   The ServerSignature directive allows the configuration of a trailing footer line under server-generated documents
6. Add ServerTokens Prod
   This directive controls whether Server response header field which is sent back to clients includes a description of the generic OS-type of the server as well as information about compiled-in modules
7. Add ErrorDocument 500 “Internal server error” to return a generic error message when http 500 error occurs
8. Add ErrorDocument 404 “An unknown error occurred, please try again later”  (http 404 = not found)
9. Add ErrorDocument 403 “An unknown error occurred, please try again later”    (http 403 = forbidden)
10. Save – exit httpd.conf
11. touch /var/log/apache2/rewrite.log to create the rewrite.log file
12. touch /srv/www/htdocs/.htaccess to create the .htaccess file
13. Edit the /srv/www/htdocs/.htaccess file
14. Add Options +FollowSymLinks –MultiViews
    Note: FollowSymLinks must be set to + for rewrite to work!
15. Add rewrite rules appropriate for your environment.  I'm using some rules that can be found in the Pauldotcom Security Weekly episode #94 show notes, which were based on a post by nullbyte.
16. Save – exit .htaccess
17. YaST – Network Services – HTTP Server
18. Server Modules tab – rewrite – toggle status to enabled - finish
19. From a terminal run: SuSEconfig
20. From a terminal run: /etc/init.d/apache2 restart
21. With a web browser, try to access a page on the server that does not exist, ie  http://server/nothere.html
22. View the  /var/log/apache2/rewrite.log 
    You should see the attempt logged

Realidade

Ter o apache instalado no ubuntu por meio de apt-get ou aptitude, ter um arquivo htaccess dentro do diretório público e o mesmo não estar sendo lido.

Saída

Como sempre, lá vai a coisa "mastigadinha":

1 - Acesse o diretório das configurações do apache referente aos virtual hosts, ou seja -> /etc/apache2/sites-available/

2 - Assim que chegar lá, acesse o arquivo referente ao seu site, no caso do meu foi o amigo Default, ele tinha um conteúdo semelhante a:

NameVirtualHost *
<VirtualHost *>
ServerAdmin webmaster@localhost

DocumentRoot /var/www/
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>

ErrorLog /var/log/apache2/error.log

# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn

CustomLog /var/log/apache2/access.log combined
ServerSignature On

Alias /doc/ "/usr/share/doc/"
<Directory "/usr/share/doc/">
Options Indexes MultiViews FollowSymLinks
AllowOverride None
Order deny,allow
Deny from all
Allow from 127.0.0.0/255.0.0.0 ::1/128
</Directory>

</VirtualHost>

############################

Para corrigir a coisa altere somente os trechos como abaixo:

NameVirtualHost *
<VirtualHost *>
ServerAdmin webmaster@localhost

DocumentRoot /var/www/
<Directory />
Options FollowSymLinks Indexes
AllowOverride AuthConfig
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride AuthConfig
Order allow,deny
allow from all
</Directory>

####################################################

Pronto, feito isto a coisa vai funcionar Beleza!

Acesse -> http://www.tinews.info e fique extremamente informado na área de TI.

Voici la manoeuvre à effectuer :

- Créez un fichier htaccess (nommez un fichier texte htaccess puis vous le renommerez .htaccess lorsque vous enregistrez).

- Créez une page html quelqconque. (Ici, nous l'appelerons 404.html).

- Vous pouvez mettre ce que vous voulez dans la page 404.html

- Voici ce qu'il y a à écrire maintenant dans le fichier htaccess :

 # ErrorDocument

ErrorDocument 404 404.html

Lorsque que l'utilisateur effectuera une erreur 404, il sera redirigé sur la page 404.html

A la place de 404, vous pouvez mettre d'autres nombres. Voici la liste des erreurs les plus répandues :

Erreur 400 : La syntaxe de la requête est erronée.

Erreur 401 : Accès à la ressource refusé.

Erreur 403 : Refus de traîtement de la requête.

Erreur 404 : Document non trouvé.

Erreur 500 : Erreur interne du serveur

... or like this with mod_rewrite disabled
http://telephotos.co.uk/index.php?object=photo&action=latest

Note that they both go to the same page. What is happening is the Orqi Loader is receiving the object and action parameters and then using them to look for a controller. First it will look in your nominated "_classes/_app" folder, then it will look in your nominated "_orqi/_app" folder for a default controller. If it can't find one then an error is returned to the screen of the ilk "Error: Class PhotoController not found."

The object parameter is the name of the controller and action is the name of the function in the controller. In the example above, this means Orqi will be looking to execute a function called "Latest" in a class called "PhotoController" which is in a file called "PhotoController.php".

Enable mod_rewrite

If you look in the config.php file you will notice a line like this ...

[sourcecode language='php']$this->app['mod_rewrite'] = true;[/sourcecode]

Set it to true to enable the nicer URL writing. Orqi will also produce nice URLs in functions like Controller::MakeLink()

NB: You MUST have the mod_rewrite module loaded on your webserver

.htaccess

Here is like the most basic .htaccess file you can get away with. It's here where the urls are redirected from "/niceurl/mycommand.html" to "/index.php?object=aargh&action=horridurl".

[sourcecode language='cpp']
RewriteEngine on
RewriteRule ^pages/(.*).html$ index.php?object=page&action=view&id=$1&%{QUERY_STRING} [L]
RewriteRule ^(.*)/(.*).html$ index.php?object=$1&action=$2&%{QUERY_STRING} [L]
[/sourcecode]

The File Extensions

If you want to change the url extensions in your urls just look for the following line in your config.php. The file extension in your config file must agree with the file extensions in your .htaccess file.

(My advice is leave it as html. I was using .orqi for a while before I realised it was an SEO suicide move)

[sourcecode language='php']$this->app['extension'] = 'html';[/sourcecode]

The auth cookie, on the other hand, is delivered only for the admin area and can be used to make changes to the blog.  If you login via https, your auth cookie will be delivered only for SSL sessions.  If you login over https and later visit your admin via regular http, you will have to log in again to get a non-SSL auth cookie. By default, you have the option of visiting your admin either via http or https.  If you want to force all admin sessions to be over https, add the following to your wp-config.php:

define(’FORCE_SSL_ADMIN’, true);

This will prevent non-SSL logins to your blog. This means you will never have an auth cookie delivered in the clear.  If you want to force logins to be over SSL to prevent usernames and passwords from being sent in the clear while letting your users have the choice of using http or https when visiting the admin, add this to your wp-config.php:

define(’FORCE_SSL_LOGIN’, true);

This does not force all cookies to be delivered over SSL.  The user has a choice between the greater security of an https session and the greater speed of an http session.  If you want to remove this choice and force secure https sessions, FORCE_SSL_ADMIN is for you.

With these new cookies comes new secret keys for signing them.  Recall that WordPress 2.5 introduced SECRET_KEY as a means of adding a little extra security to cookie signing.  If you intend to use the SSL support in 2.6, you will probably want to define the secret key for the secure cookie.  If you don’t intend to use SSL, you can stick with your existing SECRET_KEY.  Here’s an example of what the new secret key definitions look like:

define(’AUTH_KEY’, ‘put your unique phrase here’);
define(’SECURE_AUTH_KEY’, ‘put your unique phrase here’);
define(’LOGGED_IN_KEY’, ‘put your unique phrase here’);

You should change those sample phrases to unique, preferably random phrases.  Each key should have a different phrase.  Visit http://api.wordpress.org/secret-key/1.1/ to get a set of random keys that you can cut-and-paste into your wp-config.php.  Once again, if you don’t intend to use SSL, you can stick with the SECRET_KEY you already have.

This should be mostly transparent to plugins and themes. I say mostly because there are some themes that send POST and AJAX requests to files within the themes directory.  The auth cookies are delivered only to the wp-admin and wp-content/plugins directories, so files directly loaded from wp-content/themes will not see the cookies.  Themes should send their POST and AJAX re