Apache notes

the Apache web-server Project

Apache started with code from the National Center for Supercomputing Applications (NCSA), located at the University of Illinois at Urbana-Champaign, Illinois.  Apache stands for “A patchy” server - not the native-American Indian tribe, despite the (confusing) feather logo.

Apache is "set it and forget it" software in that, once it is set up and running, it usually stays running i.e. as long as the server is 'up'. The trick lies in setting up Apache in the first place ... ;-)

Apache can only run one MPM (Multi-Processing Module) at a time.

Installation(s)

Windows – XAMPP Apache installation (from ApacheFriends.org)

The fastest, easiest way to install Apache on Windows is via the ApacheFriends.org XAMPP distribution, which includes mySQL and PHP.

1. Unzip to the root directory (e.g. in Windows … C:\xampp … for typing brevity)
2. Run setup_xampp.bat.
3. Start/stop xampp programs via the xampp-control.exe (e.g. via a desktop shortcut).

If Apache won't start ...

If you see the following error: " Only one usage of each socket address (protocol/network address/port) is normally permitted. : make_sock: could not bind to address 0.0.0.0:443 no listening sockets available, shutting down"
... Apache is experiencing a port conflict.  If you’re running SkyPE, the port conflict is because SkyPE options -> Connection -> "Use port 80 and 443 as alternatives for incoming connections" is checked.

Linux Debian/Ubuntu Apache installation

On Ubuntu/Debian Linux using the Synaptics Package Manager installs the latest apache 'metapackage' version e.g. the apache2 'metapackage', which installs the faster, high-volume-server, multi-threaded apache2-mpm-worker MPM (Multi-Processing Module) Apache2, rather than the non-threaded, Apache 1.3 apache2-mpm-prefork MPM version.

I experienced faulty Package installations, particularly with PHP, using Synaptics Package Manager while Apache was running. I experienced dialog boxes, trying to 'open' PHP files, including attempts to open some .PHTML file. a2enmod php5 complained that "Module php5 does not exist". Synaptic Package Manager libapache2-mod-php5 un-install/re-install yielded no joy. Ultimately, I needed to purge and re-install libapache2-mod-php5 and other Packages, as follows.

    sudo /etc/init.d/apache2 stop
    sudo apt-get remove --purge apache2 php5
    sudo apt-get remove --purge libapache2-mod-php5
    sudo apt-get install php5 apache2 libapache2-mod-php5
    sudo /etc/init.d/apache2 start

The Debian/Ubuntu text doc is located at:

    /usr/share/doc/apache2/README.Debian.gz

Default Debian/Ubuntu configuration files are located at /etc/apache2 . Ubuntu/Debian Linux runs Apache under the www-data service User (not an application User).

Apache logs

The Apache logs can provide additional insight to the visibility provided by PHP xdebug. The default Debian/Ubuntu Apache log files are specified in /etc/apache2/apache2.conf to be in:

    ErrorLog /var/log/apache2/error.log

Due to frequent reference, it is worth bookmarking this file path. For development visibility, consider setting LogLevel debug in /etc/apache2/conf.d/VirtualHosts.conf.

Apache PHP

Installing either the PHP 'metapackage' or libapache2-mod-php5 , separately, removes the apache2-mpm-worker MPM and substitutes the non-threaded, Apache apache2-mpm-prefork MPM ... presumably to accomodate non-threaded PHP. Note: this does not mean using Apache 1.3; the pre-fork MPM is still Apache 2. The PHP 'metapackage' also installs the php5-common package.

To get the Apache PHP interpreter ( x-httpd-php ) to process within various file types, add the following line to the server's .httpd.conf file (or /etc/apache2/apache2.conf in the case of Debian/Ubuntu), rather than in any directory .htaccess file - to minimize Apache overhead, searching directories for .htaccess files (per "Apache Cookbook" p. 223).

    AddHandler application/x-httpd-php .php

Note: NO version number like x-httpd-php5 ... or you'll experience dialog boxes, trying to open a .PHTML file. See "AddHandler vs. AddType", below.

Apache Configuration

Prior to Apache2 configuration was done via /etc/apache2/http.conf. Debian Apache is configured via /etc/apache2/apache2.conf. http.conf exists on Debian only for compatibility with other software that expects to find http.conf. apache2.conf includes httpd.conf though it is, now, left blank. /etc/apache2/http.conf or /etc/apache2/apache2.conf consists of comments and Directives with values, some of which can be nested.  Most options can be left as is. A pound sign ("#" - not double forward slashes) designates a comment.

For each VirtualHost site, place a configuration file in /etc/apache2/sites-available . Enable VirtualHost files with a2ensite siteFile ; disable VirtualHosts with a2dissite siteFile.

When Apache starts, it includes files in /etc/apache2/conf.d/ in its 'global' servers configuration. Files created in the /conf.d/ directory will not be overwritten upon package upgrades. Therefore, hand-edited changes should go in the /conf.d/ directory.

The 000-default has 000 prepended to /etc/apache2/sites-enabled/default by the a2ensite script to ensure that the default VirtualHost is the first VirtualHost included by Apache (which sorts files alphabetically).

Why *nix uses text configuration files instead of e.g. Registry-database entries ...

• Text configuration files can be edited with any text editor, rather than requiring client-configuration GUI interface software and supporting .dll-like files.
• Text configuration files can be edited, remotely, e.g. via a "ssh" terminal session from anywhere in the world.
• Text configuration files obviate remembering which GUI menu path at which a particular setting was located.

Changing Web site content does not require changing or restarting Apache; however, httpd.conf (or /etc/apache2/apache2.conf in the case of Debian/Ubuntu) changes require re-starting Apache.

re-starting Ubuntu Apache

	$ sudo /usr/sbin/apache2ctl restart
	$ sudo /usr/sbin/apache2ctl stop
	$ sudo /usr/sbin/apache2ctl start

Apache quick setup - simple as 1, 2, 3

1. Make /etc/hosts domain entries, if, for development, one is NOT using a DNS server.
2. Enter AddHandler application/x-httpd-php .php .phtml into either a /etc/apache2/conf.d/ <VirtualHosts> file(s) or into /etc/apache2/apache2.conf
3. Enter <VirtualHost>s either in a single file or separate files within /etc/apache2/conf.d/

Each of the above is explained in expanded sections, below.

apache2.conf or httpd.conf configuration

• On Windows httpd.conf, resides at: \xampp\apache\conf\httpd.conf
• On Linux httpd.conf resides at: /etc/apache2/httpd.conf
• On Debian/Ubuntu Linux Apache is configured via /etc/apache2/apache2.conf , which includes /etc/apache2/httpd.conf - so one need not edit /etc/apache2/apache2.conf .

apache2.conf or httpd.conf are organized into three sections:

1. global environment,
2. [main] server configuration and
3. virtual hosts

apache2.conf or httpd.conf vs.  .htaccess files

• For httpd.conf changes to take effect the Apache httpd daemon/service must be re-started.
• Since .htaccess operates at the directory level, changes to an existing .htaccess take effect, immediately. Creating a new .htaccess may have to wait until the server cache is cleared to take effect.

Per "Apache Cookbook" p. 224, .htaccess files should only be used where apache2.conf file access is unavailable e.g. by a web-hosting ISP. Any Directive in an .htaccess file can, instead, appear in a /etc/apache2/apache2.conf <Directory> block, governing that same directory, avoiding the overhead of searching a directory tree for .htaccess files.

order of Apache configuration processing

See "Apache Cookbook" p. 254.

1. The Apache configuration file is parsed top to bottom.
2. Includeded files are parsed right at their include location e.g. within the configuration file.
3. If a Directive is called more than once, the last call overrides previous calls.
4. If a Directive is called more than once in a directory tree, the lowest call in the directory tree takes precedence.
5. .htaccess Directives take precedence over the main configuration file Directives.

The Apache configuration file(s) may be:

    /etc/apache2/apache2.conf
    /etc/apache2/conf.d/whatever.conf       # /conf.d/ files are  included   within apache2.conf

    /httpd.conf

apache2.conf or httpd.conf Directives

httpd.conf contains statements, which may be grouped, using “block Directives”, such as <Directory> </Directory>. Debian/Ubuntu Apache global Directives are controlled via:

      $ gksudo gedit /etc/apache2/apache2.conf

That said, one can, generally, leave /etc/apache2/apache2.conf un-edited so that your changes will not be lost upon system updates. Instead, place your configuration edits and changes in a /etc/apache2/conf.d/ file(s), such as /etc/apache2/conf.d/VirtualHosts.conf . Debian/Ubuntu Apache will automagically include any file names within the /etc/apache2/conf.d/ directory, as if the file(s) were within /etc/apache2/apache2.conf.

AddHandler vs. AddType

An Apache handler specifies specific processing methodology.

• AddHandler associates a file extension with a server-side Apache handler.
• AddType associates a file extension with a MIME-type for file-processing.

Per "Apache Cookbook" p. 189, AddHandler is the correct Directive to use to map .php files to the Apache PHP handler e.g.

    AddHandler application/x-httpd-php .php .phtml

AddHandler application/x-httpd-php .php .phtml worked in either a /etc/apache2/conf.d/ <VirtualHosts> file(s) or in /etc/apache2/apache2.conf. The benefit of using an /etc/apache2/conf.d/ <VirtualHosts> file(s) is that /etc/apache2/apache2.conf can remain unmodified - in case of updates.

AcceptPathInfo

Defined here:  http://httpd.apache.org/docs/2.0/mod/core.html
… controls whether URL requests, containing routing segments (e.g. http://host.com/class/method) will be accepted or rejected. AcceptPathInfo = On may be set inside /etc/apache2/apache2.conf or httpd.conf.

Syntax:

AcceptPathInfo On|Off|Default

Access Control

Access control refers to controlling access to any resource.

Access control by Host

syntax: Allow (or Deny) from IP address (or Host) e.g.

    Allow from domain.com
    Deny from 192.168.205.29

Alias

The Alias Directive permits VirtualHosting in file system locations outside the DocumentRoot directory tree. See documentation at:  httpd.apache.org - Alias.

A “virtual folder” may be located anywhere on the file system, as long as a \xampp\apache\conf\httpd.conf Alias entry points to that directory.  For example (note: forward-slashes are required to specify the Windows path because Apache expects *nix!),

	Alias /dbs/		"C:/DbS/"
	Alias /dbs		"C:/DbS"

can be called as: .  http://localhost/dbs

The Alias Directive is case-sensitive.

When using a directory Alias, rather than VirtualHost, you may get around a 403 (“No authorized access”) error by specifying a specific page.  For example, http://localhost/dbs will generate a 403 error.  However, specifying a page within that directory http://localhost/dbs/default.htm will render the page, properly.  Specifying the default page via the DirectoryIndex directive precludes having to type the default.htm.

The user, under which Apache runs (www-data), must have execute Permission on every directory within a web document tree, right up to the file system root.  Otherwise, a 403 error “No authorized access” will be generated.  To permit directory access, a <Directory> directive block is used, as follows:

    Alias /DbS "C:/DbS"
    <Directory  “C:/DbS”>
    	Order  allow, deny              #  Apache wouldn’t re-start with this line.
    	Allow from all                  #  cured the 403 denial error
    	DirectoryIndex  default.htm
    </Directory>

Supplying a default DirectoryIndex will work around the 403 (“No authorized access”) error! The XAMPP-distribution Apache default DocumentRoot directory is \xampp\htdocs\.

AllowOverride

apache2.conf or httpd.conf can be overridden by the .htaccess file. AllowOverride switches (All or None) whether or not to enable .htaccess files.

    Syntax:	AllowOverride All|None|directive-type

If a 'Directive-type' is specified, AllowOverride specifies which Directives/Properties an .htaccess file can override. AllowOverride (see section below) enables/disables control by directory-specific files (e.g. .htaccess ). AllowOverride is only valid in .conf <Directory> blocks. Recommendations: To use .htaccess file control, set:

    AllowOverride All 		# for development
      or
    AllowOverride None 		# for production

Value	Meaning
None	All .htaccess Directive overrides are ignored.
All	All .htaccess Directive overrides are implemented.
Directive-type	Only the specific Directive override is implemented.

Do not set AllowOverride All at the root directory / , because, then, Apache will check for .htaccess files in every directory - right up to the drive root ( / … or C:\  ).  In fact, it is not necessary to set AllowOverride All at the webRoot ( /htdocs/ ) level, either. Just set AllowOverride All at the VirtualHost <Directory> block level.

Apache won't re-start, if there's a comment ( # comment) in/after AllowOverride All! The Apache AllowOverride default = All; the Red Hat default = None.

DocumentRoot

The Debian/Ubuntu Apache default DocumentRoot location is /var/www/. To change the default DocumentRoot, edit the /etc/apache2/sites-available/default file, changing

    DocumentRoot /var/www

to

    DocumentRoot /path/to/whatever/documentroot/directory

Better yet, change the DocumentRoot within a <VirtualHost> block ... and leave /etc/apache2/sites-available/default unedited for automatic .svn updates.

required Permissions

root Privileges are required to edit the /etc/apache2/sites-available/default file.

The DocumentRoot (default: /var/www/ ) and its parent-directories Permissions must be world-readable and world-executable (755).  Since the DocumentRoot parent directory Permissions must be world-readable and world-executable, it is easier if the DocumentRoot directory is a top-level directory; then, you do not have to worry about Permission issues due to DocumentRoot parent-directory Permissions. .  If you receive the error: " 403 Forbidden - You don't have Permission to access / on this server ", check the DocumentRoot and all of its parent-directory Permissions to be both world-readable and world-executable (755) e.g. manually with the command:

	# chmod 755 directoryName

… where "directoryName" is the actual directory name.   Note:  A DocumentRoot Directive (Property) exists for the server default and for each VirtualHost block; so, watch where you are changing it.

redirect 301

SEO specialists state that a redirect 301 directive is the optimal way to change page URL's with minimal search engine Page Rank disruption.

syntax: redirect 301 /oldPath/oldFileName.html http://yourDomain.com/controller/function/newFileName.html

Note: Redirect takes a relative path for the old path and a full http:// path for the redirected path.

Order

The order statement specifies the order of precedence by which Directive statements will be recognized.

• Order deny,allow means allow statements, preceding deny statements, will be ignored.
• Order allow,deny means that deny statements, preceding allow statements, will be ignored.
• The default Order is deny,allow .

ServerAdmin

ServerAdmin expects an eMail address.  This eMail address is often picked up by spammers; so, if not running sendmail , do not bother specifying an eMail address.

ServerName

ServerName should contain a registered DNS domain name e.g. www.mikecoughlin.net . The domain name can skip the www, if the DNS or /host name is specified that way.  If you don't have a valid DNS name, you can use an IP address (e.g. 192.168.1.102) … or, for local PC development & testing, one can use the loopback address: 127.0.0.1 or localhost .

ServerType

The ServerType Directive may be set to:

Value	Meaning
standalone	Single instance (higher performance)
inetd	Multiple instances

VirtualHosts (a.k.a. vHosts)

VirtualHosts are web sites, served by an Apache server. Documentation is located at:  httpd.apache.org/.../vhosts/

VirtualHost types:

1. Name-based have multiple Host names, assigned to one IP address, implemented by the NameVirtualHost Directive repeating the same IP address. In general, use name-based VirtualHosts unless SSL is required.
2. IP-based assign a unique IP address for each Host domain site.
3. mixed Name/IP

Unless there is a restrictive need to use mixed name-based and/or IP-based hosts (e.g. for SSL security), generally, it is easier to use a name-based VirtualHost.

Each <VirtualHost> block needs at minimum:

• a ServerName Directive, designating which Host name is to be served and
• a DocumentRoot Directive, specifying the filesystem path to that Host's content.

To enable VirtualHosts on Debian, within e.g. /etc/apache2/conf.d/VirtualHosts.conf make sure the default site in /etc/apache2/sites-available contains a ServerName Directive:

    ServerName hostName.domainName

Tip: Using the domain organization .local helps distinguish at a glance between one’s live site vs. one’s local-test site.

add a VirtualHost tag directive for localhost or 127.0.0.1; otherwise, you will only be able to call the listed VirtualHosts and CodeIgniter routing will not work (i.e. after rendering the default page, upon clicking a /function/method/ , you will receive 404 ... file not found errors.

local Hosts configuration

In the absense of a DNS server, edit /etc/hosts or C:\WINDOWS\system32\drivers\etc\hosts to get local development domains to resolve to the local loopback IP, 127.0.0.1, as follows:

    127.0.0.1   localhost
    127.0.0.1   domainName.local
    127.0.0.1   domainName2.local

i.e. for development, add fake .local domains, as needed/desired.

Note: Multiple <VirtualHost 127.0.0.1> Directive blocks with different ServerNames can host different, registered DNS domain names at the same VirtualHost IP address! ... i.e. one can Host various ServerNames by repeating the VirtualHost IP address and adding various (i.e. different) ServerNames. On Debian/Ubuntu, place these VirtualHost blocks in (separate, if you like) files within /etc/apache2/conf.d/. Apache will include one or many files, placed in the /etc/apache2/conf.d/ directory - regardless of the file(s) names.

NameVirtualHost

To use name-based VirtualHosting, you must designate the IP address (and ports, if multiple ports are used on one server) on the hosting server via the NameVirtualHost Directive. Note: you can use the * wildcard to designate server IP addresses, as follows:

     NameVirtualHost *:80

Debian/Ubuntu defines this generic, local NameVirtualHost, as above, in:

    /etc/apache2/sites-available/default

For the same server to be known/accessible by multiple domain names, use the ServerAlias Directive in a <VirtualHost>; block (example further below):

    ServerAlias domain1.local domain2.local

For multiple host names to work, the multiple host names must be listed in the /etc/hosts file or DNS (as in "local Hosts configuration", above).

'name-based' VirtualHost examples

… a default VirtualHost setup:

    NameVirtualHost *:80
    <VirtualHost *:80>
        ServerName domainName.local
        DocumentRoot  /var/public_html
        <Directory /var/public_html>
             AllowOverride ALL          # to enable .htaccess control, but do not leave this comment 'in'
        </Directory>
    </VirtualHost>

Note that the <VirtualHost *:80> address argument must match the address argument in a NameVirtualHost *:80 Directive.

DreamWeaver will complain that Remote URL doesn't match site URL, if the Windows drive letter is not included (even though Apache does not need the Windows drive letter)! … a Debian/Ubuntu VirtualHost:

    <VirtualHost 127.0.0.1>
		ServerName  domainName.local
		DocumentRoot  /var/www
    </VirtualHost>

order of VirtualHost processing operations

Apache looks up URL's, IP addresses and VirtualHost Directives, as follows:

1. Cross-reference the incoming URL for an IP address in /etc/hosts.
2. Check the incoming IP address for a NameVirtualHost IP address match.
3. The incoming IP address is checked in each <VirtualHost> section for a matching IP address and for a URL-matching ServerName or ServerAlias.
4. If no matching ServerName or Alias is found, then the first listed <VirtualHost> block, matching the incoming IP address, is used.
5. Configuration Directives, set in the main server context (in /etc/apache2/sites-enabled/default i.e. outside any <VirtualHost> block), will only be used if they are not overridden by the e.g. <VirtualHost> configuration file settings.
6. The first listed <VirtualHost> is the default <VirtualHost>. The DocumentRoot from the main server will never be used when an IP address matches the NameVirtualHost Directive.
7. Place requests that do not match any VirtualHost, in a <VirtualHost> block and list it, first, in the configuration file e.g. /etc/apache2/conf.d/VirtualHosts.conf .

module management ... on Debian/Ubuntu Linux

The Debian/Ubuntu Linux distribution employs distribution-specific ways of managing the Apache web server. The Debian distribution provides the command scripts a2enmod to enable and a2dismod to disable Apache modules. a2enmod enables Apache modules by creating symbolic-links from /etc/apache2/mods-enabled to etc/apache2/mods-available. The Debian Apache module management syntax is simply:

    sudo a2enmod moduleName     e.g.
    sudo a2enmod rewrite

a2enmod without a moduleName will list available modules ... and offer to enable a module. After enabling a module, a2enmod prescribes re-starting Apache:

    /etc/init.d/apache2 restart

sudo apache2ctl restart will, also, re-start Apache.

For more on the Debian/Ubuntu Linux Apache-management approach see: Managing Apache the Debian way

mod_rewrite

Apache mod_rewrite reference For Apache mod_rewrite to work, un-comment mod_rewrite.so in httpd.conf and, of course, re-start Apache.  RewriteEngine on can not enable mod_rewrite , if mod_rewrite.so is not un-commented in httpd.conf .

AllowOverride ALL (rather than None) – enables .htaccess file control e.g. if PHP.ini access is un-available in a web hosting environment.

To direct all incoming requests to a single PHP script (index.php in this case),

    RewriteEngine on
    RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

If you add these Directives to httpd.conf, directly, you must re-start the web server; however, using an .htaccess file obviates the need to modify httpd.conf and re-start Apache (web-hosting may preclude an Apache re-start), since . .htaccess operates at the directory level.

An include_path Directive can appear in either an .htaccess file or in php.ini , which requires an Apache re-start – to take effect (again, maybe not permitted by your web-host).

  php_value include_path "/path/to/library"

RewriteCond

\… defines a condition, required to execute at RewriteRule , using a test string, which in addition to plain text can be:

• rule pattern back-references ($N, N = 1,2,...),
• condition pattern back-references (%N, N = 1,2,...), or
• server variables (%{SERVER_VARIABLE_NAME}).

For example,

	RewriteCond %{HTTP_HOST} ^mydomain.org$

… means, if HTTP_Host is mydomain.org

Relative paths

Instead of trying to specify ‘up’ the directory path from a file location and then ‘down’ the directory path to a file, simply specify the path down from the VirtualHost DocumentRoot directory.  For example, to specify:

	http://domain.com/images/SH.jpg 

from

	http://domain.com/application/views/index.php 

use:

	“images/SH.jpg”

instead of:

	“../../images/SH.jpg”

Unfortunately, this will work with Apache, but will not work with PHP Expert Editor (unless PHP Expert Editor is set to use Apache, instead of its internal html rendering server).

A nice html paths tutorial is at:    http://www.webdiner.com/webadv/begin/paths.htm

Though domains are case-insensitive, directories are case-sensitive.

Maintenance

The log files ( access_log and error_log ) can grow too big (particularly access_log), if the log rotate utility is not used.

Apache newsgroup

Although httpd.apache.org offers no forums, Apache discussions occur in: comp.infosystems.www.servers.Unix

Sessions

Session variables are not accessible until a session has been started (via: session_start(); ).  Session variables, once set, retain values until changed because session variables won't go away until the browser is closed.

Security

In the default Debian/Ubuntu Apache installation, the Apache web-site directories ( /var/www/ ) are assigned to the root Owner and Group, which has NO password assigned - so that a hacker can not do the unthinkable. Note that even the root Group only has Read (not Write) Permission.

Despite many forum threads advising to chown from those default Permissions, doing so lessens security by opening up the possibility of a hacker gaining access via the www-data Apache User account.

Permissions

Ubuntu/Debian Linux runs Apache as a service under the service User, www-data (not displayed in users-admin, since www-data is a service, rather than application User ... see previous Permissions paragraphs, above).

Apache, generally, (only) needs Read Permissions, since Apache only needs to Read (not Create or Write) .html files. However, for development, Apache needs to Write log files for CodeIgniter. A developer will need full Read, Write and file create/delete Permissions.

FTP & Permissions

If you are not permitted to edit/replace the home page (e.g. index.html ), verify that the Apache DocumentRoot directory grants Write Permission to your Linux login User account, used while running FTP.

an example Apache configuration

First, create the directories, you will need. Because these directories are /var/ sub-directories, which are under root Ownership and Group Permissions, sudo Permission will be required to create them and the default installation will have, initially, assigned them to the root Owner and Group.

    sudo mkdir /var/CodeIgniter/ /var/public_html/

For development (only), assign Read, Write and Create Permissions.

    sudo chmod -R 777 /var/CodeIgniter/ /var/public_html/

Add your development login User account to the www-data Apache User Group.

    sudo adduser yourAccountName www-data

Change the Owner and Group on the Apache directories.

    sudo chown -R www-data /var/CodeIgniter/ /var/public_html/
    sudo chgrp -R www-data /var/CodeIgniter/ /var/public_html/

FTP and subVersion updates will be executed under your login User account and revert the Owner and Group Permissions from www-data to your login User account; so, repeat the above after each FTP or subVersion update.

easy, open, but highly insecure web-site development

Many in forum threads advocate opening up the web-site directory tree with Read, Write and eXecute Permissions (777) for owner:group:others via:

    sudo chmod -R 777 /var/www/

This, too, must be repeated after each FTP or subVersion update. The -R directs that the command is to be applied Recursively i.e. to all contained sub-directories and files.

Due to this rather complete lack of security, 777 should only be used to facilitate programming development i.e. never on a Production or Internet-facing server.

HTTP authentication … web server-controlled authentication

Prior to serving a page, if no authentication is present for the desired directory in the browser request, the web server presents an authentication form.  Apache controls directory authentication via .htpasswd.

.htaccess configuration

To require directory authentication, include the following in httpd.conf (which requires re-starting Apache) or in that directory’s .htaccess file:

    <Directory /path/to/desired/directory>
         AllowOverride AuthConfig
    </Directory

An .htaccess file, in the directory to be protected, needs to specify the following:

    AuthName "Registered Users Only"
    AuthType Basic
    AuthUserFile /usr/local/apache2/password/.htpasswd
    Require valid-user

AuthName will label the authentication dialog box.
AuthType Basic means clear text.
AuthUserFile is the user/password repository, which should not reside in the webHost path.  However, you will need to maintain the file via PHP.

.htpasswd

XAMPP Apache includes a utility (located in c:\xampp\apache\bin\htpasswd.exe) to create an Apache password in the .htpasswd file, which will prompt for a password to maintain .htpasswd. For an IBM PHP HTTP authentication walkthrough, see:
https://www6.software.ibm.com/developerworks/education/os-phptut3/section3.html

Back Home