How to change configuration settings in php from .htaccess

To change the configuration for php running as cgi those handy module commands won't work.. The work-around is being able to tell php to start with a custom php.ini file.. configured the way you want.

With multiple custom php.ini files


The trick is creating a wrapper script to set the location of the php.ini file that php will use. Then it exec's the php cgi.

 shell script /cgi-bin/phpini.cgi
 export PHPRC=/site/ini/1
 exec /cgi-bin/php5.cgi

Now all you have to do is setup Apache to run php files through the wrapper script instead of just executing the php cgi.

 In your .htaccess or httpd.conf file
 AddHandler php-cgi .php
 Action php-cgi /cgi-bin/phpini.cgi

So to change the configuration of php you just need to change the PHPRC variable to point to a different directory containing your customized php.ini.. You could also create multiple shell wrapper scripts and create multiple Handler's+Actions in .htaccess..

 in your .htaccess
 AddHandler php-cgi1 .php1
 Action php-cgi1 /cgi-bin/phpini-1.cgi
 AddHandler php-cgi2 .php2
 Action php-cgi2 /cgi-bin/phpini-2.cgi
 AddHandler php-cgi3 .php3
 Action php-cgi3 /cgi-bin/phpini-3.cgi

The only caveat here is that it seems like you would have to rename the file extensions, but there are ways around that too outlined by AskApache:  Custom PHP.INI with .htaccess tricks.

Multi-Language and Content-Negotiation for Mirror

AskApache Intro and Mirror Update

Hash: SHA1

Hi guys,

I just made some fixes to the mirrors I run at:

This is the .htaccess file that I came up with, note I painstakingly
determined the languages..  (In the future it would be great to get each
corresponding charset for the AddCharset directive)

Note I also added compression for basic text/ plain/ type files and
added some simple Cache-Control through the mod_expires module.

Options FollowSymLinks Indexes MultiViews
Order allow,deny
Allow from all
SetEnv SERVER_ADMIN webmaster@xxxxxxxxxxxxx
SetEnv TZ America/California
DirectoryIndex index

# German (de)
# English (en)
# Spanish (es)
# Farsi (fa)
# Suomi (fi)
# French (fr)
# Italian (it)
# Japanese (ja)
# Korean (ko)
# Dutch (nl)
# Norwegian (no)
# Russian (ru)
# Portugese (pt)
# Polish (pl)
# Svenska (se)
# Turkish (tr)
# Simplified Chinese (zh-CN)

AddLanguage de .de
AddLanguage en .en
AddLanguage es .es
AddLanguage fa .fa
AddLanguage fi .fi
AddLanguage fr .fr
AddLanguage it .it
AddLanguage ja .ja
AddLanguage ko .ko
AddLanguage nl .nl
AddLanguage no .no
AddLanguage pl .pl
AddLanguage pt .pt
AddLanguage ru .ru
AddLanguage se .se
AddLanguage tr .tr
AddLanguage zh-CN .zh-cn

# TODO: Get all the charsets for each lang
AddCharset ISO-8859-1 .iso8859-1 .nl .se
AddCharset UTF-8 .utf8

AddDefaultCharset UTF-8
DefaultType text/html
DefaultLanguage en

LanguagePriority en de es fr ja ko pt-br ru tr
ForceLanguagePriority Prefer Fallback

AddType text/html .tr
RemoveHandler .pl

<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html text/plain text/css
AddOutputFilterByType DEFLATE text/xml application/javascript

<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault M3600

- --

- -- 

Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


Proxy Authentication with Squid

How does Proxy Authentication work in Squid?

Users will be authenticated if squid is configured to use proxy_auth ACLs.

Browsers send the user’s authentication credentials in the Authorization request header.

If Squid gets a request and the http_access rule list gets to a proxy_auth ACL, Squid looks for the Authorization header. If the header is present, Squid decodes it and extracts a username and password.

If the header is missing, Squid returns an HTTP reply with status 407 (Proxy Authentication Required). The user agent (browser) receives the 407 reply and then prompts the user to enter a name and password. The name and password are encoded, and sent in the Authorization header for subsequent requests to the proxy. Also see this example Authorization Header from .htaccess files.

NOTE: The name and password are encoded using “base64” (See section 11.1 of RFC 2616). However, base64 is a binary-to-text encoding only, it does NOT encrypt the information it encodes. This means that the username and password are essentially “cleartext” between the browser and the proxy. Therefore, you probably should not use the same username and password that you would use for your account login.

Authentication is actually performed outside of main Squid process. When Squid starts, it spawns a number of authentication subprocesses. These processes read usernames and passwords on stdin, and reply with “OK” or “ERR” on stdout. This technique allows you to use a number of different authentication protocols (named “schemes” in this context). When multiple authentication schemes are offered by the server (Squid in this case), it is up to the User-Agent to choose one and authenticate using it. By RFC it should choose the safest one it can handle; in practice usually Microsoft Internet Explorer chooses the first one it’s been offered that it can handle, and Mozilla browsers are bug-compatible with the Microsoft system in this field.

The Squid source code comes with a few authentication backends (“helpers“) for Basic authentication. These include:

  • LDAP: Uses the Lightweight Directory Access Protocol
  • NCSA: Uses an NCSA-style username and password file.
  • MSNT: Uses a Windows NT authentication domain.
  • PAM: Uses the Unix Pluggable Authentication Modules scheme.
  • SMB: Uses a SMB server like Windows NT or Samba.
  • getpwam: Uses the old-fashioned Unix password file.
  • SASL: Uses SALS libraries.
  • mswin_sspi: Windows native authenticator
  • YP: Uses the NIS database

In addition Squid also supports the NTLM, Negotiate and Digest authentication schemes which provide more secure authentication methods, in that where the password is not exchanged in plain text over the wire. Each scheme have their own set of helpers and auth_param settings. Notice that helpers for different authentication schemes use different protocols to talk with squid, so they can’t be mixed.

For information on how to set up NTLM authentication see NTLM config examples.

In order to authenticate users, you need to compile and install one of the supplied authentication modules found in the helpers/basic_auth/ directory, one of the others, or supply your own.

You tell Squid which authentication program to use with the auth_param option in squid.conf. You specify the name of the program, plus any command line options if necessary. For example:

auth_param basic program /usr/local/squid/bin/ncsa_auth /usr/local/squid/etc/passwd

How do I use authentication in access controls?

Make sure that your authentication program is installed and working correctly. You can test it by hand.

Add some proxy_auth ACL entries to your squid configuration. For example:

acl foo proxy_auth REQUIRED
http_access allow foo
http_access deny all

The REQUIRED term means that any authenticated user will match the ACL named foo.

Squid allows you to provide fine-grained controls by specifying individual user names. For example:

acl foo proxy_auth REQUIRED
acl bar proxy_auth lisa sarah frank joe
acl daytime time 08:00-17:00
http_access allow bar
http_access allow foo daytime
http_access deny all

In this example, users named lisa, sarah, joe, and frank are allowed to use the proxy at all times. Other users are allowed only during daytime hours.

How do I ask for authentication of an already authenticated user?

If a user is authenticated at the proxy you cannot “log out” and re-authenticate. The user usually has to close and re-open the browser windows to be able to re-login at the proxy. A simple configuration will probably look like this:

acl my_auth proxy_auth REQUIRED
http_access allow my_auth
http_access deny all

But there is a trick which can force the user to authenticate with a different account in certain situations. This happens if you deny access with an authentication related ACL last in the http_access deny statement. Example configuration:

acl my_auth proxy_auth REQUIRED
acl google_users proxyauth user1 user2 user3
acl google dstdomain
http_access deny google !google_users
http_access allow my_auth
http_access deny all

In this case if the user requests then first second http_access line matches and triggers re-authentication unless the user is one of the listed users. Remember: it’s always the last ACL on a http_access line that “matches”. If the matching ACL deals with authentication a re-authentication is triggered. If you didn’t want that you would need to switch the order of ACLs so that you get http_access deny !google_users google.

You might also run into an authentication loop if you are not careful. Assume that you use LDAP group lookups and want to deny access based on an LDAP group (e.g. only members of a certain LDAP group are allowed to reach certain web sites). In this case you may trigger re-authentication although you don’t intend to. This config is likely wrong for you:

acl ldapgroup-allowed external LDAP_group PROXY_ALLOWED

http_access deny !ldapgroup-allowed
http_access allow all

The second http_access line would force the user to re-authenticate time and again if he/she is not member of the PROXY_ALLOWED group. This is perhaps not what you want. You rather wanted to deny access to non-members. So you need to rewrite this http_access line so that an ACL matches that has nothing to do with authentication. This is the correct example:

acl ldapgroup-allowed external LDAP_group PROXY_ALLOWED

http_access deny !ldapgroup-allowed all
http_access allow all

This way the http_access line still matches. But it’s the all ACL which is now last in the line. Since all is a static ACL (that always matches) and has nothing to do with authentication you will find that the access is just denied.

More Info

Example .htaccess

Send Custom Headers

Header set P3P "policyref=\"\""
Header set X-Pingback ""
Header set Content-Language "en-US"
Header set Vary "Accept-Encoding"

Blocking based on User-Agent Header

SetEnvIfNoCase ^User-Agent$ .*(craftbot|download|extract|stripper|sucker|ninja|clshttp|webspider|leacher|collector|grabber|webpictures) HTTP_SAFE_BADBOT
SetEnvIfNoCase ^User-Agent$ .*(libwww-perl|aesop_com_spiderman) HTTP_SAFE_BADBOT
Deny from env=HTTP_SAFE_BADBOT

proxy_auth acl causing challenge loop
> Well, I really prefer the old behaviour, so I hope the behaviour is not
> hardcoded, but configurable.

It’s not hardcoded, instead it is dependent on how your http_access rules
are constructed.

Squid prompts for login credentials if the user is denied access by an
authentication related acl (proxy_auth, proxyauth_regex, external using

http_access deny someacl authacl
prompts for new credentials if matched (denied by authacl)
http_access deny authacl someacl
does nor prompt for new credentials (denied by someacl)

Further Resources

  1. smb.conf man page
  2. smbclient man page
  3. ntlm_auth man page
  4. Configuring Squid Proxy To Authenticate With Active Directory
  5. Samba & Active Directory
  6. The Linux-PAM System Administrators’ Guide

Original Source: ProxyAuthentication © Creative Commons Attribution Sharealike 2.5 License

Python working on Apache

This page gives some nice but advanced tricks for a moin Apache setup with php and .htaccess.  The directives
on this page assume that you have knowledge about Apache configuration, newbies should
stick to the basic setup. This requires the Apache module “mod_rewrite” for rewriting  (which should be standard).

mod_python is an Apache module that embeds the Python interpreter within the server. With mod_python you can write web-based applications in Python that will run many times faster than traditional CGI and will have access to advanced features such as ability to retain database connections and other data between hits and access to Apache internals.

Continue reading Python working on Apache

List of .htaccess Examples

Some Good Official Tutorials

Sample .htaccess file from htaccess Google Group

Continue reading List of .htaccess Examples

Apache .htaccess

%d bloggers like this: