help logoLON-CAPA Help


Log-in Service

If your domain has more than one server you have the option to configure whether any of the servers will redirect to another server whenever the log-in page is requested. This can be useful if you maintain a portal or "Load Balancer" server which forms your institution's gateway to LON-CAPA. You can specify the path to which the user should be redirected, and also whether log-in page requests from specific IP addresses should be exempt from the redirection. The exemption is useful if you run a monitoring script which tests log-in, course display, and logout periodically for each of your LON-CAPA servers.

Log-in Page Items

If your domain only has one LON-CAPA server, or you have multiple servers and will display their log-in pages, their appearance can be customized as follows:

Note: logos displayed in the login page configuration panel are scaled down from the full size used in the log-in page itself.

The following elements are configurable:

A "Log-in Help" link will be displayed immediately above any of the four optional links: Catalog, Contact Helpdesk, Admin Email, and New User. Configuration options determine to which file(s) the "Log-in Help" points. The default file can be replaced with a custom HTML file containing information pertinent to your institution. In addition, versions of the custom file, translated into the twelve languages supported by LON-CAPA can be uploaded, and the link will automatically point to the appropriate (localized) file, depending on the viewer's language preference (as reported by the client web browser).

Log-in Help

Where the "Contact Helpdesk" web form is in use it can be configured to include a CAPTCHA mechanism to discourage robotic form completion. There are two types of CAPTCHA to choose from - the "original" CAPTCHA which uses a self-contained perl module included with the LONCAPA prerequisites, or ReCAPTCHA, which uses an external service - https://google.com/recaptcha - and requires you to create an account and generate public and private keys which will be entered in the domain configuration form. If you have more than one server in your domain, you should request "global" keys, as the same keys will be used by the Contact Helpdesk ReCAPTCHA on all servers in your domain. If using ReCAPTCHA, you can indicate whether version 1 or 2 should be used.

Custom HTML in document head

The head portion of the log-in page may contain custom mark up (e.g., a script block containing javascript for page analytics) in a file which will be uploaded and published public. Different custom markup may be uploaded for each server in a domain, and a comma separated list of IP addresses may be specified for which the custom markup will not be included in the page, when the request for the log-in page originates from one of those addresses. A use case for the exempt IP addresses is where robotic requests for the log-in page and made from a monitoring machine, used to detect when a LON-CAPA server is not working correctly.

Dual login: SSO and non-SSO

For a LON-CAPA node configured to support Single Sign On (SSO), e.g., by operating as a Shibboleth SP, entries in Apache config files (loncapa_apache.conf, if Shibboleth) will cause display of an SSO login page whenever a user accesses /adm/roles without a cookie for an unexpired LON-CAPA session. If it is preferred instead to display /adm/login configured to offer dual SSO log-in (e.g., Shibboleth), and non-SSO login (i.e., LON-CAPA), that will be set via the "Dual login: SSO and non-SSO options" section.

Check the "Yes" radio button for each of the domain's servers which will offer dual login and then set:

The value in the URL field will be /adm/sso for Shibboleth, and an uploaded image file will provide the button to be clicked to load /adm/sso (i.e., to prompt an SSO login). The alt and title attributes for the button can also be set.

In some circumstances the default may be to attempt display of the SSO log-in dialog within an iframe, e.g., when link protection has been enabled for LTI mediated deep link access from another learning management system, and a user is also required to authenticate in LON-CAPA. In such cases, "sameorigin" requirements for the SSO login page may dictate that the SSO login must be displayed in a pop-window instead of the iframe. Setting "Pop-up if iframe" to "Yes" will ensure a pop-up is launched when the button and/or link for SSO login is clicked and the login page is within an iframe.

With dual login in effect the LON-CAPA login page /adm/login will display the following:

If the SSO service is something other than Shibboleth (e.g., CAS or Sentinel) and the PerlVar lonOtherAuthenUrl has been set to a preferred URL (e.g., /adm/sentinel), then the URL item in the SSO entry in the dual login options should be set to that same preferred URL.

Note: if the original page request by an unauthenticated user included a query string with any of the following items: role, symb, and linkkey, then they will be stored in a token file on the server, for access later to support deep-linking. Similarly, if the query string contained an ltoken item from successful launch from an LTI Consumer, where LON-CAPA is the LTI Provider, and for that Consumer LON-CAPA is not configured to accept user information, and the destination is a deep-link URL: /tiny/domain/uniqueID, then the LTI number, type (c or d), and tiny URL will be saved as the linkprot item in a token file.