3.31. <AuthBy FILE> Previous topic Parent topic Child topic Next topic

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.28. <AuthBy xxxxxx>.