Return to Domain_Configuration_LangTZAuth.tex CVS log

Up to [LON-CAPA] / loncom / html / adm / help / tex

Annotation of loncom/html/adm/help/tex/Domain_Configuration_LangTZAuth.tex, revision 1.13

1.5       raeburn     1: \label{Domain_Configuration_LangTZAuth}
1.2       raeburn     2: Prior to LON-CAPA 2.7, default language and authentication type/argument
                      3: were defined in the domain's entry in the domain.tab file. Those settings
                      4: will continue to be used by servers in your domain until you have
1.10      raeburn     5: displayed and saved the Default authentication, language, timezone data
1.2       raeburn     6: table. Once that has been done, whenever values need to be determined
                      7: for these settings in the domain they will be retrieved from the configuration.db
                      8: file on the primary library server in your domain, which is where
1.3       raeburn     9: information saved from the {}``Domain Configuration'' data tables
1.2       raeburn    10: is stored. Any information in the domain.tab file will no longer be
                     11: consulted, except by servers running pre-2.7 versions of LON-CAPA.
1.1       raeburn    12: 
1.11      raeburn    13: \textbf{Default domain configurations} can be assigned for: 
1.1       raeburn    14: 
                     15: \begin{itemize}
1.11      raeburn    16: \item \textit{default language} used by users in your domain, unless overridden by
1.2       raeburn    17: a user preference
1.11      raeburn    18: \item \textit{default authentication type} for new users in the domain. You will
1.2       raeburn    19: need to set the default authentication if you intend to allow a user
                     20: to create a LON-CAPA account if the user successfully authenticated
                     21: via a central service at your institution (e.g., Kerberos), but is
                     22: without a LON-CAPA account. The default authentication is also the
                     23: default offered when Course Coordinators or Authors create new accounts,
                     24: assuming user creation is permitted in these contexts.
1.11      raeburn    25: \item \textit{default timezone} - this will be the timezone used when showing any
1.2       raeburn    26: times in your domain, unless overridden at a course level, by a course-wide
                     27: timezone. The timezones available are mostly in the form Continent/City,
                     28: although for the USA there are some in the form America/State/City
                     29: as well as EST5EDT, CST6CDT, MST7MDT, PST8PDT and HST (for Eastern,
                     30: Central, Mountain, Pacific and Hawaii Timezones, which adjust for
1.4       raeburn    31: daylight savings as appropriate). If no default timezone is set times
1.6       raeburn    32: will be displayed according to the timezone of the server hosting
1.2       raeburn    33: the user's LON-CAPA session.
1.11      raeburn    34: \item \textit{portal/default URL} - starting with LON-CAPA 2.10, a default URL can
1.7       raeburn    35: be specified.  This URL will be included in e-mail sent to confirm self-enrollment etc.
1.8       raeburn    36: and might be for a load-balancer LON-CAPA server, or in the case of a multi-domain server,
1.9       raeburn    37: for a specific alias used for the domain.
1.1       raeburn    38: \end{itemize}
1.9       raeburn    39: 
1.11      raeburn    40: \textbf{Institutional user types} can also be defined for the domain via the same screen.
1.9       raeburn    41: 
                     42: Prior to LON-CAPA 2.11, institutional user types were defined in the \&inst\_usertypes
                     43: subroutine in localenroll.pm, which would be customized for consistency with types 
                     44: defined in institutional data feeds.  Setting of user types via the Domain Configuration
                     45: web GUI supersedes use of localenroll::inst\_usertypes().  Items that can be set are:
                     46: 
                     47: \begin{itemize}
1.11      raeburn    48: \item \textit{Internal ID} (e.g., faculty)
                     49: \item \textit{Name Displayed} (e.g., Faculty/Academic Staff)
                     50: \item \textit{Order} (Listing order, 1 through N, when the type is to be selected from a list).
                     51: \item \textit{Assignment to ``email-based'' usernames} Whether status type can also be assigned to a non-institutional user with an e-mail address as username
1.9       raeburn    52: \end{itemize}
                     53: 
1.13    ! raeburn    54: \textbf{Mapping for missing usernames via standard log-in} can be enabled for the domain via the same screen.
        !            55: 
        !            56: For a user who logs-in to LON-CAPA via the standard log-in screen, customization is available to support credentials
        !            57: checking with an alternate username (but same password) if the username, as originally entered by the user, should
        !            58: be altered in a predictable way, to make it consistent with the format expected for usernames in the domain.
        !            59: 
        !            60: An example is where an email address is supplied as the username by the user, but the part of the email address
        !            61: which precedes the @ in the email address is what is actually used in LON-CAPA for the user's username.
        !            62: 
        !            63: A complication is the fact that a domain may support both types of username, e.g., userID, and userID@example.tld,
        !            64: as legitimate usernames for different types of user.  For example the usernames for official users may look like: userID,
        !            65: but privileged users may also create user accounts for guest users (including ``fictitous'' usernames for themselves, to
        !            66: use to test course behavior as a student) which look like: userID@example.tld.
        !            67: 
        !            68: To accommodate that possibility, LON-CAPA will first attempt to authenticate the username and password, but if a user
        !            69: does not exist for the supplied username in the domain, can then see if a ``real'' username can be extracted from
        !            70: the one supplied, and make a second attempt to authenticate using the derived username with the password. Accordingly,
        !            71: authentication would fail for: userID@example.tld if that user did not exist, but might succeed for userID if that user
        !            72: did exist, and the password supplied matched what was expected.
        !            73: 
        !            74: To enable this functionality requires customizing two routines in /home/httpd/lib/perl/localenroll.pm:
        !            75: &unamemap_rules() and &unamemap_check(). There are stubs for both of them (with documentation) in the
        !            76: uncustomized template file: /home/httpd/lib/perl/localenroll-std.pm.  Restart of loncontrol is required
        !            77: after making changes to localenroll.pm.
        !            78: 
        !            79: Once &unamemap_rules() contains at least one rule, then the ``Default authentication/language/timezone/portal/types''
        !            80: domain configuration will include a checkbox for at least one rule in ``Available conversions'' listed in the
        !            81: ``Mapping for missing usernames via standard log-in'' section. Checking the checkbox and pushing ``Save Changes''
        !            82: will make the corresponding conversion for that rule, as coded in &unamemap_check(), available to create
        !            83: a derived username for a second authentication attempt, if the original username did not exist, but matched
        !            84: the required format for the conversion.
        !            85: