- APACHE CONFIGURATION DIRECTIVES
- DATABASE SCHEMAS
- SEE ALSO
Apache::AuthCookieDBI - An AuthCookie module backed by a DBI database.
$Revision: 126.96.36.199 $
# In httpd.conf or .htaccess # This PerlSetVar MUST precede the PerlModule line because the # key is read in a BEGIN block when the module is loaded. PerlSetVar WhatEverDBI_SecretKeyFile /etc/httpd/acme.com.key PerlModule Apache::AuthCookieDBI PerlSetVar WhatEverPath / PerlSetVar WhatEverLoginScript /login.pl # Optional, to share tickets between servers. PerlSetVar WhatEverDomain .domain.com # These must be set PerlSetVar WhatEverDBI_DSN "DBI:mysql:database=test" PerlSetVar WhatEverDBI_SecretKey "489e5eaad8b3208f9ad8792ef4afca73598ae666b0206a9c92ac877e73ce835c" # These are optional, the module sets sensible defaults. PerlSetVar WhatEverDBI_User "nobody" PerlSetVar WhatEverDBI_Password "password" PerlSetVar WhatEverDBI_UsersTable "users" PerlSetVar WhatEverDBI_UserField "user" PerlSetVar WhatEverDBI_PasswordField "password" PerlSetVar WhatEverDBI_CryptType "none" PerlSetVar WhatEverDBI_GroupsTable "groups" PerlSetVar WhatEverDBI_GroupField "grp" PerlSetVar WhatEverDBI_GroupUserField "user" PerlSetVar WhatEverDBI_EncryptionType "none" PerlSetVar WhatEverDBI_SessionLifetime 00-24-00-00 # Protected by AuthCookieDBI. <Directory /www/domain.com/authcookiedbi> AuthType Apache::AuthCookieDBI AuthName WhatEver PerlAuthenHandler Apache::AuthCookieDBI->authenticate PerlAuthzHandler Apache::AuthCookieDBI->authorize require valid-user # or you can require users: require user jacob # You can optionally require groups. require group system </Directory> # Login location. <Files LOGIN> AuthType Apache::AuthCookieDBI AuthName WhatEver SetHandler perl-script PerlHandler Apache::AuthCookieDBI->login </Files>
This module is an authentication handler that uses the basic mechanism provided by Apache::AuthCookie with a DBI database for ticket-based protection. It is based on two tokens being provided, a username and password, which can be any strings (there are no illegal characters for either). The username is used to set the remote user as if Basic Authentication was used.
On an attempt to access a protected location without a valid cookie being provided, the module prints an HTML login form (produced by a CGI or any other handler; this can be a static file if you want to always send people to the same entry page when they log in). This login form has fields for username and password. On submitting it, the username and password are looked up in the DBI database. The supplied password is checked against the password in the database; the password in the database can be plaintext, or a crypt() or md5_hex() checksum of the password. If this succeeds, the user is issued a ticket. This ticket contains the username, an issue time, an expire time, and an MD5 checksum of those and a secret key for the server. It can optionally be encrypted before returning it to the client in the cookie; encryption is only useful for preventing the client from seeing the expire time. If you wish to protect passwords in transport, use an SSL-encrypted connection. The ticket is given in a cookie that the browser stores.
After a login the user is redirected to the location they originally wished to view (or to a fixed page if the login "script" was really a static file).
On this access and any subsequent attempt to access a protected document, the browser returns the ticket to the server. The server unencrypts it if encrypted tickets are enabled, then extracts the username, issue time, expire time and checksum. A new checksum is calculated of the username, issue time, expire time and the secret key again; if it agrees with the checksum that the client supplied, we know that the data has not been tampered with. We next check that the expire time has not passed. If not, the ticket is still good, so we set the username.
Authorization checks then check that any "require valid-user" or "require user jacob" settings are passed. Finally, if a "require group foo" directive was given, the module will look up the username in a groups database and check that the user is a member of one of the groups listed. If all these checks pass, the document requested is displayed.
If a ticket has expired or is otherwise invalid it is cleared in the browser and the login form is shown again.
All configuration directives for this module are passed in PerlSetVars. These PerlSetVars must begin with the AuthName that you are describing, so if your AuthName is PrivateBankingSystem they will look like:
PerlSetVar PrivateBankingSystemDBI_DSN "DBI:mysql:database=banking"
See also Apache::Authcookie for the directives required for any kind of Apache::AuthCookie-based authentication system.
In the following descriptions, replace "WhatEver" with your particular AuthName. The available configuration directives are as follows:
Specifies the DSN for DBI for the database you wish to connect to retrieve user information. This is required and has no default value.
Specifies the secret key for this auth scheme. This should be a long random string. This should be secret; either make the httpd.conf file only readable by root, or put the PerlSetVar in a file only readable by root and include it.
This is required and has no default value
The user to log into the database as. This is not required and defaults to undef.
The password to use to access the database. This is not required and defaults to undef.
The table that user names and passwords are stored in. This is not required and defaults to 'users'.
The field in the above table that has the user name. This is not required and defaults to 'user'.
The field in the above table that has the password. This is not required and defaults to 'password'.
What kind of hashing is used on the password field in the database. This can be 'none', 'crypt', or 'md5'. This is not required and defaults to 'none'.
The table that has the user / group information. This is not required and defaults to 'groups'.
The field in the above table that has the group name. This is not required and defaults to 'grp' (to prevent conflicts with the SQL reserved word 'group').
The field in the above table that has the user name. This is not required and defaults to 'user'.
WhatEverDBI_SecretKeyFile - DEPRECATED
The file that contains the secret key (on the first line of the file). This is required and has no default value. This key should be owned and only readable by root. It is read at server startup time. The key should be long and fairly random. If you want, you can change it and restart the server, (maybe daily), which will invalidate all prior-issued tickets.
This directive MUST be set before the PerlModule line that loads this module, because the secret key file is read immediately (at server start time). This is so you can have it owned and only readable by root even though Apache then changes to another user.
I suggest using DBI_SecretKey instead.
What kind of encryption to use to prevent the user from looking at the fields in the ticket we give them. This is almost completely useless, so don't switch it on unless you really know you need it. It does not provide any protection of the password in transport; use SSL for that. It can be 'none', 'des', 'idea', 'blowfish', or 'blowfish_pp'.
This is not required and defaults to 'none'.
How long tickets are good for after being issued. Note that presently Apache::AuthCookie does not set a client-side expire time, which means that most clients will only keep the cookie until the user quits the browser. However, if you wish to force people to log in again sooner than that, set this value. This can be 'forever' or a life time specified as:
DD-hh-mm-ss -- Days, hours, minute and seconds to live.
This is not required and defaults to '00-24-00-00' or 24 hours.
You can subclass this module to override public functions and change their behaviour.
This method returns extra fields to add to the session key. It should return a string consisting of ":field1:field2:field3" (where each field is preceded by a colon).
The default implementation returns false.
For this module to work, the database tables must be laid out at least somewhat according to the following rules: the user field must be a primary key so there is only one row per user; the password field must be NOT NULL. If you're using MD5 passwords the password field must be 32 characters long to allow enough space for the output of md5_hex(). If you're using crypt() passwords you need to allow 13 characters.
An minimal CREATE TABLE statement might look like:
CREATE TABLE users ( user VARCHAR(16) PRIMARY KEY, password VARCHAR(32) NOT NULL )
For the groups table, the access table is actually going to be a join table between the users table and a table in which there is one row per group if you have more per-group data to store; if all you care about is group membership though, you only need this one table. The only constraints on this table are that the user and group fields be NOT NULL.
A minimal CREATE TABLE statement might look like:
CREATE TABLE groups ( grp VARCHAR(16) NOT NULL, user VARCHAR(16) NOT NULL )
Copyright (C) 2002 SF Interactive.
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
2 POD Errors
The following errors were encountered while parsing the POD:
- Around line 478:
You forgot a '=back' before '=head1'
- Around line 867:
=back without =over