LON-CAPA LON-CAPA Help

LON-CAPA Help

Prior to LON-CAPA 2.7, default language and authentication type/argument were defined in the domain's entry in the domain.tab file. Those settings will continue to be used by servers in your domain until you have displayed and saved the Default authentication, language, timezone data table. Once that has been done, whenever values need to be determined for these settings in the domain they will be retrieved from the configuration.db file on the primary library server in your domain, which is where information saved from the "Domain Configuration" data tables is stored. Any information in the domain.tab file will no longer be consulted, except by servers running pre-2.7 versions of LON-CAPA.

Default domain configurations can be assigned for:

default language used by users in your domain, unless overridden by a user preference
default authentication type for new users in the domain. You will need to set the default authentication if you intend to allow a user to create a LON-CAPA account if the user successfully authenticated via a central service at your institution (e.g., Kerberos), but is without a LON-CAPA account. The default authentication is also the default offered when Course Coordinators or Authors create new accounts, assuming user creation is permitted in these contexts.
default timezone - this will be the timezone used when showing any times in your domain, unless overridden at a course level, by a course-wide timezone. The timezones available are mostly in the form Continent/City, although for the USA there are some in the form America/State/City as well as EST5EDT, CST6CDT, MST7MDT, PST8PDT and HST (for Eastern, Central, Mountain, Pacific and Hawaii Timezones, which adjust for daylight savings as appropriate). If no default timezone is set times will be displayed according to the timezone of the server hosting the user's LON-CAPA session.
portal/default URL - starting with LON-CAPA 2.10, a default URL can be specified. This URL will be included in e-mail sent to confirm self-enrollment etc. and might be for a load-balancer LON-CAPA server, or in the case of a multi-domain server, for a specific alias used for the domain.

Institutional user types can also be defined for the domain via the same screen.

Prior to LON-CAPA 2.11, institutional user types were defined in the &inst_usertypes subroutine in localenroll.pm, which would be customized for consistency with types defined in institutional data feeds. Setting of user types via the Domain Configuration web GUI supersedes use of localenroll::inst_usertypes(). Items that can be set are:

Internal ID (e.g., faculty)
Name Displayed (e.g., Faculty/Academic Staff)
Order (Listing order, 1 through N, when the type is to be selected from a list).
Assignment to "email-based" usernames Whether status type can also be assigned to a non-institutional user with an e-mail address as username

Mapping for missing usernames via standard log-in can be enabled for the domain via the same screen.

For a user who logs-in to LON-CAPA via the standard log-in screen, customization is available to support credentials checking with an alternate username (but same password) if the username, as originally entered by the user, should be altered in a predictable way, to make it consistent with the format expected for usernames in the domain.

An example is where an email address is supplied as the username by the user, but the part of the email address which precedes the @ in the email address is what is actually used in LON-CAPA for the user's username.

A complication is the fact that a domain may support both types of username, e.g., userID, and userID@example.tld, as legitimate usernames for different types of user. For example the usernames for official users may look like: userID, but privileged users may also create user accounts for guest users (including "fictitous" usernames for themselves, to use to test course behavior as a student) which look like: userID@example.tld.

To accommodate that possibility, LON-CAPA will first attempt to authenticate the username and password, but if a user does not exist for the supplied username in the domain, can then see if a "real" username can be extracted from the one supplied, and make a second attempt to authenticate using the derived username with the password. Accordingly, authentication would fail for: userID@example.tld if that user did not exist, but might succeed for userID if that user did exist, and the password supplied matched what was expected.

Two routines: &unamemap_rules() and &unamemap_check() in localenroll.pm (which is found in: /home/httpd/lib/perl/ ) need to be customized to enable this functionality. There are stubs for both of them (with documentation) in the uncustomized template file: localenroll-std.pm in the same directory. Restart of loncontrol is required after making changes to localenroll.pm.

Once &unamemap_rules() contains at least one rule, then the "Default authentication / language / timezone / portal / types" domain configuration will include a checkbox for at least one rule in "Available conversions" listed in the "Mapping for missing usernames via standard log-in" section. Checking the checkbox and pushing "Save Changes" will make the corresponding conversion for that rule, as coded in &unamemap_check(), available to create a derived username for a second authentication attempt, if the original username did not exist, but matched the required format for the conversion.