Managing Users To use user authentication, you’ll need to edit and manage user files and group files

.

Using htpasswd to manage user files

To deal with user files, we provide a program in the support directory of the distribution called htpasswd. Usage:

htpasswd [-c] file user

The -c, if present, tells htpasswd to create a new passwd file of the specified name instead of editing an old one. file is the pathname of the user file you wish to edit. The user parameter is the name of the user you wish to add or edit.

If htpasswd finds the user you specified, it will ask you to change the user’s password. Type the new password (it will ask twice). HTTPd will then update the file.

If htpasswd doesn’t find the specified user, it will ask you to give the user an initial password.

Group files

The format of the group file is as follows:

groupname: member1 member2 ...

Or, each line contains the name of a group, and a list of members separated by spaces.

<Directory /u/Web>

Options All

<Limit GET>
order allow,deny
allow from all
</Limit>

</Directory>

<Directory /u/Web/docs/info>
AuthType Basic
AuthUserFile /usr/local/etc/httpd/conf/.htpasswd
AuthGroupFile /usr/local/etc/httpd/conf/.htgroup
</Directory>

<Directory /u/Web/docs/info/ncsaonly>
<Limit GET>
order deny,allow
deny from all
allow from .ncsa.uiuc.edu
</Limit>
</Directory>

<Directory /u/Web/docs/info/nonncsa>
<Limit GET>
order allow,deny
allow from all
deny from .ncsa.uiuc.edu
</Limit>
</Directory>

<Directory /u/Web/docs/info/carlosonly>
AuthName Carlos Gold Info
<Limit GET>
require user cvarela
</Limit>
</Directory>

<Directory /u/Web/docs/info/xmosdonly>
AuthName The X Club
<Limit GET>
require group mosaic-x-dev
</Limit>
</Directory>

<Directory /u/Web/docs/info/carlos-and-void>
AuthName Carlos Gold Info
<Limit GET>
order deny,allow
deny from all
allow from void.ncsa.uiuc.edu
require user cvarela
</Limit>
</Directory>

<Directory /u/Web/docs/info/carlos-or-void>
AuthName Carlos Gold Info
<Limit GET>
order mutual-failure
deny from all
allow from void.ncsa.uiuc.edu
require user cvarela
</Limit>
</Directory>

NOTE: Not Freeware.

.htaccess manager : New Version 3.3

This is a perl CGI script used to manage multiple usernames/passwords for .htaccess/.htpasswd directory protection. This works on most web sites and can be used to handle many password protected folders. In addition to storing the username and encrypted password, you may add additional info for your members such as name, e-mail and comments to help you manage who has access to your “members only” web site. New features include setting an expiration date for a user, keyword search of your members’ list and batch removal of users.

FEATURES

Adding a New user

The “Add User” function is the first that appears after logging into the script. You just need to supply a username and password then click “Add User”. All the other fields are optional. Even the password field can be left blank and the program will pick one at random. You can also supply the member’s name, e-mail address and a short comments field. If you check the box “Check to email new entry to user”, this will tell the program to send out an email with pre-configured text welcoming the user as a new member to your password protected area. If you do check this box, then you can also provide additional text in the large “Extra E-mail Text” box which will be passed along in the email sent out.

You can now add an expiration date for the user, enter it in the format YYYYMMDD (20030631 for example). The script does not automatically delete users but you have the option of sorting your user list by expiration date. This field is optional and you do not have to enter an expiration date.

View, Modify and Delete Users

The “List User” screen does three things, it provides a list of all your members, allows you to delete a member and modify any information for a particular member. The user list shows “Username – Member Name – Email address – comments”. You can easily control the size of this box by changing the scrollsize option in the program settings. To delete a user all you have to do is highlight then click the delete button. To Modify a user, you also highlight the record then you can modify the password, name, email and comments field. You can even check the box to resend their confirmation email. If one of your members forgets their password, you just come to this screen, highlight them, enter a new password, check the “e-mail” box and click “Modify User”.

Sort By Expiration : Will sort all of your members by expiration date in ascending order.
Sort by username : Sorts the list by username (the default view)
Keyword Search : Will search the username, name, email, comments and expiration field for whatever you type in

Change Directory

“Change Protected Directory” screen allows you to manage password protection on another folder. This also makes it easier than going back to the login screen. This screen displays the path you have setup where your password protected directories will be located. You just type in the new folder name and click “Change Directory”. This way you can use the script to manage as many password protected folders as you like. If you are protecting a folder within another folder then you type in for example : member_area/secure1 and then the script will manage the “secure1″ folder located in the “member_area” folder. You will also find two additional buttons on this screen. One is to view the .htaccess file and the other for the .htpasswd file. This is a good thing to do every now and then so you can make backups of your member database.

Generate .htaccess File

When you first setup password protection on a folder, you need to create a .htaccess file inside it. You can either do this manually or have the script create this file for you. You do not need to do this every time you add a user. Once a .htaccess file has been created in a folder, you don’t need to run this function again. The Directory field will display the folder name you are about to generate a .htaccess file for. The Realm is for the message that will be displayed in the pop-up box that appears when a user tries to login to your secure area. If you want the script to create the file, then check the “Create .htaccess file on Server”. As for the format you want, the majority of unix servers use “.htaccess file for apache” Some web hosting companies use Cobalt RAQ or Zeus.

Password Retrieval (Version 3.2+)

You can now have your members generate new passwords for themselves if they forget their login information. To activate this feature in the script, send your users to :

http://www.yourdomain.com/admin.cgi?action=F&targetdir=dirname

Where “dirname” is the name of the directory you are protecting (same directory you type in when accessing admin.cgi)
If a member forgets their username, they just type in their email address and it will be sent to them. If they forget their password, they just type in their e-mail and username then a new password will be generated.

Version 3.3 just added the option for users to select their own new password if they supply their username and their old password.

Extract E-mails

Extract E-mails allows you to export a list of all your members’ email addresses. The list will be formatted one email address per line. Some email programs require that each address have a comma after it which you can select when exporting. The addresses will appear on the next page which you can then copy/paste into Eudora/Outlook etc.

Mass E-mails (Version 3.2+)

Allows you to send a broadcast email message to all members. E-mails can be configured to send specific information about each user using the %tag%.
Example : Hello %name%,
Your userid is : %username%
Your email is : %email%
Your account expires on : %expiration%
Comments about your account : %comments%

Manual Import

If you have a large list of usernames that you want to add as members in just one click then the Manual Import feature will handle this. All you do is copy/paste or type the list into the large text box. Here is a sample of what the list would look like :
username,password
joe,joe123
jack,jack887
jane,janepass

You can also import the additional fields :
username, password, name, email, comments, expiration
joe,joe123,Joe Smith,joe@smith.com,friend
jack,jack887,Jack Smith,jack@smith.com,

Also, you can even leave the password field blank to have the script automatically generate it for you :
joe,,Joe Smith,joe@smith.com
jack,,Jack Smith,jack@smith.com
(note the two commas after eachother)

You can also automatically send an email to each member that you import by checking the “Send E-mail” box. Even the comments field can be sent if you wish.
Whenever you run the import, the script will always check to make sure that the username doesn’t already exits. If any username in your list exists, no records will be imported.

Import From File

The import from file feature is if you have a list of members too large to fit in the manual import box or maybe you have another program that exports the list of usernames/passwords to a file that need to be imported later. By default, the name of the file that the program looks for is called htimport.txt and will be located in the directory you are protecting. The format for records to be imported is the same as the manual import :
username,password
or
username,password,name,email,comments, expiration
or
username,,name,email,comments

Whenever you run the import, the script will always check to make sure that the username doesn’t already exits. If any username in your list exists, no records will be imported.

Change Program Settings

This screen allows you to update configurations in the program without having to manually edit the admin.cgi script. The settings you can change are :
Base directory : The physical server path to where your protected folder or folders are located. (Not to be confused with the URL or domain name to your web site). example : /www/yourdomain/htdocs/

Password : The master password to access the admin.cgi script with.
Sendmail : The path to sendmail for your server.
Scroll Size : The number of members that will be displayed in the “List Users” screen before it scrolls.
Email From : Your e-mail address goes here. This is also the address used when sending email confirmations to your new members, they will see this in the From field. You can also add your name in parenthesis : joe@smith.com (Joe Smith)
Email Subject : The subject of the emails which are sent out to new members.
Top of Email : The text that will appear in the email sent to users. After this text will come the username and password.
Bottom of Email : The text that will appear after the username/password and the end of the email.
The data for all these variables is stored in a file called adminvars.cgi
You do not need to create this file on the server. If the file is not there it will be created with default settings. If for some reason your script does not have permission to create the file, you may need to upload a blank one and chmod it to 777. The default admin password is test.

FAQ

Some web hosts allows you to create multiple users per account. Each user can have domain assigned to its home home directory accessible via FTP or SSH/SCP. The problem with multiple users on the same account is that they share the same default unix group, and default permissions allow their files to be easily modified by the members of this group. Usually this doesn’t pose a problem as each user is probably trusted by account owner to not to mess with others files, but if one of the users have their web application hacked then all other users on the same account will be in danger.

By default (on DreamHost) all files in your account are created with 644 privileges and directories are with 775. That means any user can read your files and any user from the same account can move and add files in your freshly made directories. Your home directory is different, though. By default it carries 751 attribute meaning that only members of your group can see your files, but can’t add any new. These group access schemes are possible, because every user in your account has its primary/default group set to “pgxxxxxx”, which is assigned to every new file you create by default. The normal way to secure users from web-intrusion is to assign a separate group to the web-server user, removing it from default group. This way, exploited scripts will not be able to traverse into home directories of other users on your account. To allow account users to update centralized web-site they could be added to web-site group explicitly. But this “normal way” doesn’t work with DreamHost, because you can’t delete web-user from the default group and unless you set access for every new file explicitly, it will be possible for an intruder to read it.

To make managing privileges easier in interactive sessions “umask 007″ command can be specified in your .bash_profile – this makes all new files carry xx0 mask. You also need to control your scripts (web based or cron/shell) so that they set mask for critical files explicitly. To secure account users from access by means of hacked user script you would also like to define another group for every user in your account and change group ownership of the user’s home directory to that group with “set gid” bit set (and optional umask 007 in .bash_profile).

1. Add a separate user and group for every domain where apache will be running
2. Add a separate group for other user accounts
3. Change the default group for new files created by your users by changing the group of their home directory and setting set gid bit for it (it is impossible to do this with FTP accounts, therefore you will need to login in each account via SSH)
4. Add users who need access to web-site into the web-user group
5. Optionally set umask 007 in .bash_profile for every user to tweak default DreamHost 775/664 permissions to something like 770/660 for directories and files that are not meant to be read by Apache (660 could also be used for all web scripts including .php as they are not read by dhapache CGI, but merely executed)

Apache Security

All your web files that need to be read by Apache should be readable by everyone as Apache itself is run under dhapache user. However, executable scripts like .php are executed under your own user and do not have to be world readable as they are not actually read by Apache, but executed via suEXEC. Quite the opposite – to prevent your code or database settings from being messed by any third-parties you SHOULD set permissions to these files explicitly to something like 640 or even 600 depending on who do you trust.

Multiuser security setup example

For our example, we will create a example_www user and a new_webroot group for serving web files with apache and setup a example user with a ‘rfrc group to manage mail and keep other files on DH privately. Since these records already exist, you will need to subsitute your own names.

• Login to DreamHost panel and create the users example_www and example with shell access.
• From groups tab create two groups – new_webroot and rfrc. Note that users created in previous step are still members of the same default pgxxxxxx group.
• Add example_www to ‘the ‘new_webroot group and example to both the new_webroot and rfrc groups
• Move your domain to example_www account (mine is example.org)
• Now login to SSH with your example_www user and change the default group for your home directory with “sgid” bit set to make all current and new files/directories created in this directory have the same new_webroot group.

 $ chgrp -R new_webroot .
 $ chmod 2751 .
 $ chmod 2771 example.org

By setting 2771 the directory will be writable by the owner, the group and will be only executable by others. The contents of an executable only directory cannot be listed, but the files inside it can be read (if the permissions of the file allow it). It is important that the directory can be executable in order to allow static content (e.g. .html files) inside it to be read. Remember that directories you don’t want anyone to have web access to, should be 0770 (writable by the owner and group, or 0750 writable by the owner and readable by group). Such strict permissions should by applied to password files, php include files or databases files (such as SQLite, BDB, etc).

• Do the same for example user, but specify rfrc group instead.

chgrp -R rfrc .
chmod 2751 .

• Optionally modify umask in .bash_profile in user’s home to 007 to make all files created by this user have 660 permissions set by default. If you want that newly created files by accessible by the web, you need to manually setup it’s permissions to 664.

Now I can login as the user “example” and update the web-site in the ../example_www/example.org directory. There is one more setup needed. Because files copied from other accounts can have 644 permissions set instead of 664, you need a script which will update permissions to 664 or 660 to allow other group members modify such files.

Subversion can be a very useful tool for developing Web sites or Web-based applications. You may wonder, though, how that would work. After you commit your changes to your repository, how do you have them reflected on your site? The easiest method is to have your site’s directory on the server be a working copy checked out from your Subversion repository. If you elect to do this be certain to modify your site’s .htaccess to prevent users from browsing Subversion’s control files. Something simple in the root of your site such as the following will suffice.

RedirectMatch 403 /\.svn.*$

Additionally you can configure your site to automatically check out the current sources from your repository by using Subversion’s “hook scripts“. In short, the script called hooks/post-commit will be executed by the web server each time new sources are checked into your repository. Be advised that when the web server executes this script it is running in the security context of the dhapache user — this user does not and should not (for security reasons) have the necessary permissions to modify the files in your web site’s directory. As such we need to arrange for the post-commit script to run the update in the security context of a user with the privileges necessary to update your site.

Users familiar with UNIX systems will recognize that this is a task for a setuid binary. Unfortunately the DreamHost /home/ directories are NFS filesystems which are, for security reasons, mounted with setuid disabled. Fortunately the workaround is trivial — simply set up your update script as a CGI script and have the Subversion post-commit hook invoke this script. Instructions follow.

1. Create a private directory on your website to host your updater script such as /home/username/mysite.com/cgi-bin/pri

1b. And set its permissions so that only the user has write access to it.

chmod 755 pri

2. Secure the private directory by creating a .htaccess file with contents similar to the following.

AuthName "Dialog prompt"
AuthType Basic
AuthUserFile /home/username/mysite.com/cgi-bin/pri/.htpasswd
Require valid-user

3. Using the htpasswd utility create the .htpasswd file by running the following command in your /home/username/mysite.com/cgi-bin/pri directory. For security reasons make up a new username and password and do not re-use the username and password of a user you have created on your server or a user you have given access to your subversion repository.

htpasswd -bc .htpasswd someuser somepasswd

4. Now that you have created and secured a directory for this special CGI script to live in, create a script in that directory called do_update.cgi with the following contents.

#!/bin/sh
set -f
echo "Content-type: text/plain; charset=iso-8859-1"
echo
/usr/bin/svn update /home/username/mysite.com

4b. Don’t forget to give execution privilege to your file. Only the user can have write access to it.

chmod 755 do_update.cgi

5. Finally, modify your /home/username/svn/projectname/hooks/post-commit to invoke your CGI script so your site will update after each commit.

#!/bin/bash
wget --http-user=someuser --http-passwd=somepasswd -O - http://mysite.com/cgi-bin/pri/do_update.cgi

5b. Don’t forget to give execution privilege to your file. Again, only the user can have write access to it.

chmod 755 post-commit

IP Abuse Detection Script

This shell script checks the access and error logs generated by apache for a particular domain, looking for the IP addresses that have connected to your site the most. It checks for IP addresses that trigger a Concurrent Connection Limit Exceeded error, which is a good sign they are an automated bot of some kind, making over 20 requests to your site at the same time. This script also checks for Internal Recursion Errors which can have very negative effects on your speed and resources, and are basically internal looping problems generally caused by improperly configured Htaccess setups.

Once the script finishes scanning your logs for those events, it automatically generates .htaccess code that you may add to your sites root .htaccess file to block those IP addresses the script identified as abusive. The only IP addresses included in the generated .htaccess file are those that have no reverse dns.

Installation

1. Log in to your account using SSH
2. Save this code in your $HOME directory as ip-abuse-lookup.sh
   1. Run pico $HOME/ip-abuse-lookup.sh
   2. Copy the code to the screen by clicking the right-mouse-button
   3. Hold down the Ctrl button and then press x to save
3. Run the command dos2unix -dv $HOME/ip-abuse-lookup.sh to fix line break issues
4. Run the command chmod -v 744 $HOME/ip-abuse-lookup.sh to make executable

Running the Script

From your $HOME directory (cd $HOME), run ./ip-abuse-lookup.sh to execute the program.

Example Generated .htaccess

This script will also generate code that you can place in your .htaccess file to block specific abusers.

## IP-ABUSE-LOOKUP
Order Allow,Deny
Allow from All
Deny from 6.132.177.129 27.67.117.178 6.135.166.102 8.93.225.133
Deny from 21.194.136.15 22.120.61.3 6.252.139.246 9.64.50.83
Deny from 8.123.144.98 21.249.83.87 29.85.238.28 25.214.237.62
Deny from 22.115.130.23 13.57.156.241 14.121.4.82 6.208.172.177

ip-abuse-lookup.sh

#!/bin/sh
# Version 0.2, 2008-04-20

# User-contributed script. Not sponsored by DreamHost.
# Script created 2008-01-16 by AskApache 

### SHELL OPTIONS
set +o noclobber  # allowed to clobber files
set +o noglob     # globbing on
set +o xtrace     # change to - to enable tracing
set +o verbose    # change to - to enable verbose debugging
set -e            # abort on first error

The full script is here, but the authors has an updated Ip Abuse Blocking with .htaccess page.

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

static const command_rec digest_cmds[] =
{
    AP_INIT_TAKE1("AuthName", set_realm, NULL, OR_AUTHCFG,
     "The authentication realm (e.g. \"Members Only\")"),
    AP_INIT_ITERATE("AuthDigestProvider", add_authn_provider, NULL, OR_AUTHCFG,
                     "specify the auth providers for a directory or location"),
    AP_INIT_ITERATE("AuthDigestQop", set_qop, NULL, OR_AUTHCFG,
     "A list of quality-of-protection options"),
    AP_INIT_TAKE1("AuthDigestNonceLifetime", set_nonce_lifetime, NULL, OR_AUTHCFG,
     "Maximum lifetime of the server nonce (seconds)"),
    AP_INIT_TAKE1("AuthDigestNonceFormat", set_nonce_format, NULL, OR_AUTHCFG,
     "The format to use when generating the server nonce"),
    AP_INIT_FLAG("AuthDigestNcCheck", set_nc_check, NULL, OR_AUTHCFG,
     "Whether or not to check the nonce-count sent by the client"),
    AP_INIT_TAKE1("AuthDigestAlgorithm", set_algorithm, NULL, OR_AUTHCFG,
     "The algorithm used for the hash calculation"),
    AP_INIT_ITERATE("AuthDigestDomain", set_uri_list, NULL, OR_AUTHCFG,
     "A list of URI's which belong to the same protection space as the current URI"),
    AP_INIT_TAKE1("AuthDigestShmemSize", set_shmem_size, NULL, RSRC_CONF,
     "The amount of shared memory to allocate for keeping track of clients"),
    {NULL}
};

/*
 * client list code
 *
 * Each client is assigned a number, which is transferred in the opaque
 * field of the WWW-Authenticate and Authorization headers. The number
 * is just a simple counter which is incremented for each new client.
 * Clients can't forge this number because it is hashed up into the
 * server nonce, and that is checked.
 *
 * The clients are kept in a simple hash table, which consists of an
 * array of client_entry's, each with a linked list of entries hanging
 * off it. The client's number modulo the size of the array gives the
 * bucket number.
 *
 * The clients are garbage collected whenever a new client is allocated
 * but there is not enough space left in the shared memory segment. A
 * simple semi-LRU is used for this: whenever a client entry is accessed
 * it is moved to the beginning of the linked list in its bucket (this
 * also makes for faster lookups for current clients). The garbage
 * collecter then just removes the oldest entry (i.e. the one at the
 * end of the list) in each bucket.
 *
 * The main advantages of the above scheme are that it's easy to implement
 * and it keeps the hash table evenly balanced (i.e. same number of entries
 * in each bucket). The major disadvantage is that you may be throwing
 * entries out which are in active use. This is not tragic, as these
 * clients will just be sent a new client id (opaque field) and nonce
 * with a stale=true (i.e. it will just look like the nonce expired,
 * thereby forcing an extra round trip). If the shared memory segment
 * has enough headroom over the current client set size then this should
 * not occur too often.
 *
 * To help tune the size of the shared memory segment (and see if the
 * above algorithm is really sufficient) a set of counters is kept
 * indicating the number of clients held, the number of garbage collected
 * clients, and the number of erroneously purged clients. These are printed
 * out at each garbage collection run. Note that access to the counters is
 * not synchronized because they are just indicaters, and whether they are
 * off by a few doesn't matter; and for the same reason no attempt is made
 * to guarantee the num_renewed is correct in the face of clients spoofing
 * the opaque field.
 */

/*
 * Get the client given its client number (the key). Returns the entry,
 * or NULL if it's not found.
 *
 * Access to the list itself is synchronized via locks. However, access
 * to the entry returned by get_client() is NOT synchronized. This means
 * that there are potentially problems if a client uses multiple,
 * simultaneous connections to access url's within the same protection
 * space. However, these problems are not new: when using multiple
 * connections you have no guarantee of the order the requests are
 * processed anyway, so you have problems with the nonce-count and
 * one-time nonces anyway.
 */

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 requests to the admin-post.php or admin-ajax.php files.  I’ve added a short article to the codex on how themes and plugins should handle their POST and AJAX requests.

Plugins might also create links that are not properly prefixed with ‘https’.  Any content loaded into a secure page must come via an https link to avoid warnings from the browser about the content being only partially encrypted.  WordPress 2.6 introduces five new functions that take care of using the proper protocol when loading CSS, JS, and other files into an SSL-encrypted admin page.  They are site_url(), admin_url(), includes_ur(), plugins_url(), and content_url().  Each accepts an optional path relative to the site, admin, include, plugins, and content urls, respectively.  For example, to link to wp-content/plugins/foo/foo.php use plugins_url(’foo/foo.php’).  Plugins that load CSS and JS via relative links do not need to use these functions.  Relative links will automatically use the proper protocol.

Selling Free Software

Many people believe that the spirit of the GNU project is that you should not charge money for distributing copies of software, or that you should charge as little as possible — just enough to cover the cost.

Actually we encourage people who redistribute free software to charge as much as they wish or can. If this seems surprising to you, please read on.

The word “free” has two legitimate general meanings; it can refer either to freedom or to price. When we speak of “free software”, we’re talking about freedom, not price. (Think of “free speech”, not “free beer”.) Specifically, it means that a user is free to run the program, change the program, and redistribute the program with or without changes.

Free programs are sometimes distributed gratis, and sometimes for a substantial price. Often the same program is available in both ways from different places. The program is free regardless of the price, because users have freedom in using it.

Non-free programs are usually sold for a high price, but sometimes a store will give you a copy at no charge. That doesn’t make it free software, though. Price or no price, the program is non-free because users don’t have freedom.

Since free software is not a matter of price, a low price isn’t more free, or closer to free. So if you are redistributing copies of free software, you might as well charge a substantial fee and make some money. Redistributing free software is a good and legitimate activity; if you do it, you might as well make a profit from it.

Free software is a community project, and everyone who depends on it ought to look for ways to contribute to building the community. For a distributor, the way to do this is to give a part of the profit to the Free Software Foundation or some other free software development project. By funding development, you can advance the world of free software.

Distributing free software is an opportunity to raise funds for development. Don’t waste it!

In order to contribute funds, you need to have some extra. If you charge too low a fee, you won’t have anything to spare to support development.