Section 3.35. <AuthBy FILE>

3.35. <AuthBy FILE>

AuthBy FILE authenticates users from a user database stored in a flat file. It ignores (but replies to) accounting requests. It is implemented in AuthFILE.pm. It understands standard Livingston user files. For more information about Livingston user files, see Section 9.2. Flat file user database.

For performance reasons, AuthBy FILE opens and reads the user database at start-up, reinitialisation and whenever the file’s modification time changes, (i.e. the database is cached within Radiator). Since the user database is cached in memory, large databases can require large amounts of memory.

AuthBy FILE supports a Nocache parameter that causes the user database to not be cached, and forces the file to be reread for every authentication. It will do a linear search for the user. You should be very careful about using this because it could be very slow for more than 1000 users or so. Also, authentication speed will depend on the user's position in the file, and will be faster for users near the beginning of the file. If you need Nocache in a production setting, you should consider DBFILE instead.

When attempting to authenticate a user, AuthBy FILE will first compare all the check items associated with the user. It understands and handles check items. For more information, see Section 7.1. Check items.

If all the check items agree with the attributes in the Access-Request message, AuthBy FILE will reply with an Access-Accept message containing all the attributes given as reply attributes in the user database. Some reply attributes are given special handling. For more information, see Section 7.2. Reply items. If the user does not appear in the database, or if any check attribute does not match, an Access-Reject message is sent to the client.

<AuthBy FILE> understands also the same parameters as <AuthBy xxxxxx>. For more information, see Section 3.32. <AuthBy xxxxxx>.

3.35.1. Filename

This specifies the filename that holds the user database. The default value is %D/users, which means the file named users in DbDir. The file name can include special formatting characters. For more information, see Section 3.3. Special formatters.

Here is an example of using Filename:

# user database is called rad_users in DbDir
Filename %D/rad_users

Tip

Do not use %U or %u (which are replaced by the user name) in Filename, otherwise the filename changes with every authentication.

3.35.2. GroupFilename

This defines the filename that holds the user group database. The default value is %D/groups, which means the file named groups in DbDir. The file name can include special formatting characters. For more information, see Section 3.3. Special formatters.

For usage examples, see goodies/authorize-group1.cfg and goodies/authorize-group2.cfg.

3.35.3. Nocache

Disables caching of the user database, and forces Filename to be reread for every Authentication. If not set, AuthBy FILE will only reread the user database when the files modification time changes. Do not use this parameter unless you have to, because it can be very slow for any more than 1000 users or so. If you need think you need Nocache, you should consider DBFILE instead.

# Do not cache so we can do some simple testing
# without restarting the server all the time
Nocache