password protect all web pages?

[garyed]

I'm not sure if this is a php or Apache question but here goes anyways. 

I have my Apache web server set up so I can access it from anywhere which obviously means anyone else can access it too. I have my index page which is basically a menu for the site password protected with a simple php script. 

The problem is the index.php password page can be bypassed by just typing the name or path of any of the pages on the site. I don't want to have to password protect or enter a session variable onto every page.

Is there a practical way to make it where no page can be accessed without being routed from the index.php page ?   

[requinix]

If all you want is a password prompt then you can do that with .htaccess and a password list. Apache handles it all for you. The login prompt is a bit basic 😎 but if you don't care about that then it's very easy to use.

Otherwise what you're looking at having to create is a standard login system using a session. Each page verifies the session data is correct (like by require()ing an appropriate file and calling some function inside it, so you don't have to copy/paste the same verification code everywhere) and redirects to the index page if it isn't.

[garyed]

Thanks,

If I understand you right, it could either be done through the .htaccess file or else I would have to edit every page to look for the correct session variable that is passed from index.php when the correct password is entered.

Assuming that is correct then .htaccess would be a better idea assuming it is reasonably secure. I don't do much other than surfing the web & doing my site on my server but I still don't like the idea of it being insecure.   

[JacobSeated]

In my experience, .htaccess (HTTP based authentication) is actually pretty bad, because the htaccess syntax is so exotic that even experienced developers sometimes struggle to figure it out. But, I often use it on client test-sites to easily prevent access and indexing in search engines.

For my personal projects, I do much prefer to just redirect all requests to PHP, even for files that exist. This is because I just find it much easier to do what I need from PHP. 

In a purely PHP based app, you could configure your VHOST like this:
 

RewriteEngine on
RewriteRule ^.*$ index.php [L,QSA]

That should basically rewrite all requests to your PHP application. The down-side is that you need to manually handle caching headers, for static files, as well as the range header (range requests) if you want to properly support streaming of video files. I am working on a file handler for this: https://github.com/beamtic/Doorkeeper/tree/master/lib/file_handler

The good thing about redirecting everything is that it is much easier to secure your application since it only has a single point of entry. This is nice when using form-based authentications with cookies. 

Alternatively, if you still want to support some public static files, and have them delivered by your web server, you can use the following configuration:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^.*$ / [QSA]

This would still allow you to keep some private static files outside of your web-root, and then have a file handler script serve them to the user after the user has authenticated.

The configuration should also work from .htaccess, but I recommend just throwing it in your VHOST config. It should also be more efficient, although that's probably insignificant in must cases.

[garyed]

By doing the RewriteRule would that mean if I have any file in the root directory let's say called jimbo.php & someone typed in  http://myipaddress/jimbo.php it would redirect them to index.php? 

[requinix]

It wouldn't redirect the user. Normal RewriteRules make their changes internally - the user wouldn't know it happened. Only when you try to redirect someone to a complete URL somewhere else on the internet (ie, "https://whatever/path") or you use the [R] flag will the user('s browser) be told to do something else.