restriction to directly accessing any file by typing in the address bar

See
http://www.wazzup.co.nz/tutorials/protect_pdf/index.php
http://www.experts-exchange.com/Web_Development/Web_Languages-Standards/PHP/PHP_Databases/Q_21004573.html

Create a directory which noone will know about, and disable file listing for that directory:
http://www.javascriptkit.com/howto/htaccess11.shtml
Make sure directory name can not be guessed either, make it something like /pdfs5464243589/

Then make a PHP script which will download files based on file name, file name will be passed to the PHP script via $_GET vars, e.g.:
pdfdlscript.php?myfile=myfile.pdf

Then "pdfdlscript.php" will take a file from your directory and pass it to user to view/doanload. Directory name "/pdfs5464243589/" can be placed within the PHP code, and this PHP code will grab the file based on $_GET[myfile] variable. This PHP file will also take care of user authentication (e.g. via user session). So it will not give file download if someone types
http://www.domain.com/pdfdlscript.php?myfile=myfile.pdf
in the browser directly, but will allow it if user is logged in.

You need to create a newcustom http handler for the files and serve them from a server page

check for a referer. deny all users that do not have a referer, deny users from refering urls that you do not aprove of.

I'm sorry but I can't go for the referer solution or the complex directory name solution. The referer solution is bad for many reasons (briefly touched upon above), but mostly because the client fills in the referer link. You can never trust the client. One must always view the client as a brilliant and diabolical opponent who would be smart enough to forge a referer link.

As for the random directory name. I think that solution works but should someone somehow get that directory name, then all security is gone. This is essentially proposing "security by obscurity", a weak solution, at best.

paradoxengine's second solution seems along the right track. A "secure" random token stored in the server should be pretty tight. Adding a timeout on the token will make it even tighter. That way you can reduce user's from accessing the links page, visiting other pages, and then entering one of these extra-secure URLs directly as the random token will have timed out. A timeout on the order of a few minutes might be reasonable.

Another variant is to store data in hidden fields on the links page and have clicking the link actually submit a form. I think the data you need in the hidden fields is the sessionID, a timeout time, the page or pages they have access to, and a signature that signs all of the hidden fields along with a random number that is only stored in the user's session on the server  (the random number ensures that the user cannot spoof the signature).

There probably are other ways to do this, but one thing I'm wondering is why do you wish to do this? It seems so un-web-like.

- Neil

> .. like to restrict access to a certain directory on my webserver if users directly access any file by typing in the address bar.

I guess you're just talking about the files in the directory, not the directory itself, not to be access by direct URL. Otherwhise the only solution is: don't publish ;-)

Said this, I'd do it as follows:
1. create your directory in the web server containing the pdf files, this directory must not be accessable through URL (either outside DocumentRoot, or access restrictions)
2. write a .php script doing your authentication and accepting a parameter for the final file to be retrived
3. the .php  described in 2. delivers requested files only if the user credentials match, then files are fetched from 1. and send to client