+ It is possible to define conditions in more than one options list. The only requiremnt is that conditions are uniquie, meaning that a condition in one option list cannot be used in another list. This can easily be avoided by using numbers for one condition and letters for the other condition, like in the following example: +
@@ -1828,88 +1832,61 @@ Options Location = Main Building{a}, New Building{b}, Old Building{c}
{1&a} ...
+ specifies for example the condition "Linux AND Main Building". If several lines with condition combinations are true, the upper one is used. +
+ Conditional attributes are usually only used for change items
in the entry form. It might however be desirable to have conditional
attibutes also working in the list display (the page where several
entries are shown on a single page). The value of one attribute can then
for example change which other attributes gets displayed via the
list display option. To enable the evaluation of conditional
attributes for the list display, on uses the option
-
+
List conditions = 1+ It should be noted that this option can cause a significant performance degradation if many conditional attributes are defines, so it should only be turned on when it is really needed. +
+ + ++ Note: Starting with version 2.9.0, the password level access using + the options Read password, Write password and + Admin password is not supported any more. Please use the user + level access as described below. +
+ +- Reading and writing into logbooks can be constrained using two different - access methods, either with global passwords for read, write and admin - (config, delete), or with user- level passwords. Both methods can be - combined on the same server using different logbooks. For these two - schemes to work properly, cookies have to be turned on in your - browser. Please consult your browser documentation about how to do - that. -
-Read password = <encoded password>
- Write password = <encoded password>
- Admin password = <encoded password>
- Write password expiration = <hours>
- Admin password expiration = <hours>
-
- These optional password statements define passwords for reading and
- writing to the logbook, to delete entries in the logbook and to configure
- a logbook via the Config menu. The passwords are stored in an
- encoded form. To change them, use elogd directly with
- the -r , -w and
- -a flags. To set the write password of logbook
- "linux" to "test", enter:
-
elogd -w test -l linux
-
- The read password is queried by the browser with a pop-up window and
- usually stays active for the entire browser session. The write and admin
- passwords are stored in cookies on the browser side and expire after the
- browser session. This time can be changed with the statement
- Write Password Expiration = x or Admin
- Password Expiration = x, where x is the expiration time
- in hours. It should be noted that on some systems the daylight savings
- time is calculated incorrectly, which can cause time offsets of one hour
- between a server PC and a client PC. In this case one hour must be added
- to the expiration time. If the expiration is set to "0", which is the
- default, the passwords are kept for the current browser session only.
- When the browser is restarted, the password must be re-entered.
-
+ Following options can be used to control the behavior:
Password file = <file>
@@ -1924,10 +1901,9 @@ Options Location = Main Building{a}, New Building{b}, Old Building{c}
Login user = <user list>
- An alternative to the read/write/admin passwords is the user level access - with a password file. This file contains user names and passwords in - XML format, such as + This file contains user names and passwords in XML format, such as
@@ -1937,7 +1913,7 @@ Options Location = Main Building{a}, New Building{b}, Old Building{c}
<list>
<user>
<name>stefan</name>
- <password>A1kk838Kjl==</password>
+ <password encoding="SHA256">Ebx/a.9tFFQ/iUW3mU8GbnPpCVk74jFt56CmiJXVwdm</password>
<full_name>Stefan Ritt</full_name>
<last_logout>Tue Oct 17 12:59:47 2006</last_logout>
<last_activity>Tue Nov 07 08:15:51 2006</last_activity>
@@ -1948,7 +1924,7 @@ Options Location = Main Building{a}, New Building{b}, Old Building{c}
</user>
<user>
<name>midas</name>
- <password>P387sdkK98ko98==</password>
+ <password encoding="SHA256">t56CmiJXVwdmEbx/a.9tFFQ/iUW3mU8GbnPpCVk74jF</password>
<full_name>Midas User</full_name>
<last_logout>0</last_logout>
<last_activity>0</last_activity>
@@ -1977,15 +1953,9 @@ Options Location = Main Building{a}, New Building{b}, Old Building{c}
Password file =
<file> in the configuration file
Self register = 1 in the configuration file
- Guest menu commands entry, you have to click
- on "Login" to get that screen.
- Admin user = <user> into the
configuration file, using your login name from above
@@ -2060,7 +2030,7 @@ Options Location = Main Building{a}, New Building{b}, Old Building{c}
Self register = 0|1|2|3
+ Self register = 0|1|2|3|4
@@ -2075,10 +2045,13 @@ Options Location = Main Building{a}, New Building{b}, Old Building{c} Setting this option to 0 disables self registration. With option 1, users can silently register, while setting it to 2 causes elogd to send an email notification to the admin user(s). The - option 3 is used to only send an email notification to tha + option 3 is used to only send an email notification to the admin users(s), which then can validate the account and commit it by - hitting the URL given in the email notification. -
+ hitting the URL given in the email notification. Setting this to 4 + causes and email notification to be sent to the user, which then can + validate the account herself/himself proving to have a working + email account. +Allow password change = 0|1
@@ -2153,6 +2126,57 @@ Options Location = Main Building{a}, New Building{b}, Old Building{c}
If the password statements are in the individual logbook sections, one
has to log in to each logbook separately.
+
+ + Starting from version 2.9.0, site authentication has been implemented + in elog using the Kerberos + authentication scheme. This widely used system is also used in MS Windows + Domain Controllers, and can be used for site logins, meaning that the + same credentials can be used on all computers of a site. +
+
+ To use that authetication, Kerberos has to be installed on the server
+ running the elogd daemon. Please read the Kerberos documentation how to
+ do this or talk to your site administrator. There are packages for Linux,
+ Windows and Mac OSX. If you compile the elogd program yourself, make sure
+ to have the flag HAVE_KRB5> defined in the compilation process.
+ To configure elogd to use Kerberos, use following options:
+
Authentication = <method(s)>
+ Kerberos Realm = <realm>
+
+ where <method(s)> can be File or
+ Kerberos or both such
+ as in Kerberos, File. If the authentication option contains
+ Kerberos, the user credentials are authenticated using the default
+ Kerberos Realm. This is typically obtained from the file
+ c:\windows\krb5.ini (Windows) or
+ /etc/krb5.conf (Linux). If another than the default
+ realm should be used, this can be overwritten with the Kerberos
+ Realm option.
+
+ When Kerberos authentication is used, the password file is still used + to store additional user information such as the full name and the email + address, but the authentication is done via the Kerberos server. +
+
+ If both authentications Kerberos, File are enabled,
+ the credentials are first authenticated via the Kerberos server, and - if
+ not successful - via the password file. This allows combined elog
+ installations with centralized and local elog accounts.
+