Framing and Browser Cookies

An LTI launch opens NETLAB+ inside the LMS page, in a frame on the LMS’s own origin. That is what the LTI specification is designed for, and it is the only situation in which NETLAB+ is meant to be framed by another site. Two things follow from it that an administrator may need to know about: the framing policy NETLAB+ sends to browsers, and the cookies a learner’s browser must accept.

The Framing Policy

NETLAB+ tells browsers which sites may frame its pages through the frame-ancestors directive of its Content Security Policy. This policy is sent only while CSP is enabled under Security > Web Server Security; see Content Security Policy (CSP) in the Administrator Guide. CSP is disabled on a new system, and with it disabled NETLAB+ sends no framing policy at all, so nothing described in this section restricts an LMS.

With CSP enabled, the policy for the site as a whole is restrictive: by default only NETLAB+ itself may frame NETLAB+ pages, which protects against clickjacking.

The LTI endpoints are the exception. The pages an LMS opens during a launch or a dynamic registration (the LTI 1.1 launch page, the LTI 1.3 login, launch and registration pages) carry their own policy, identical to the site policy except that they may be framed by an LMS. By default any site may frame them, so no configuration is needed to make LTI work. None of these pages does anything without a signed launch message or a registration token from the LMS.

The two login steps a launch passes through after the LTI endpoint, and a logout clicked inside the frame, are also allowed to be framed, but only for a browser that is in an LTI session. For everyone else those pages keep the site policy. Arriving from an LMS is what marks the browser’s session; the mark is removed when the NETLAB+ session ends.

Note

The list of sites allowed to frame the LTI endpoints can be narrowed to a specific LMS. It is the LTI frame-ancestors field on the administrator’s Content Security Policy page; see Content Security Policy (CSP) in the Administrator Guide. Enter the address learners see in the browser when they use the LMS, which for a hosted LMS is your institution’s own LMS address rather than the vendor’s.

Browser Cookies

Because NETLAB+ runs inside the LMS page, the cookies NETLAB+ sets for the learner’s session are, from the browser’s point of view, third-party cookies. A browser that blocks third-party cookies cannot hold a NETLAB+ session inside the frame.

When that happens, the learner is shown the message “Cookies are not enabled” in place of the lab, asking them to configure their browser to allow cookies for the NETLAB+ site. NETLAB+ cookies are erased when the browser is closed, so nothing is retained on the learner’s computer between sessions.

What the learner can do:

  • Allow cookies for the NETLAB+ site in the browser’s settings. In most browsers this is an exception added for the NETLAB+ address rather than a global change.

  • Use a browser, or a browser profile, that does not block third-party cookies.

Tip

A launch that reaches NETLAB+ but ends at the cookie message is not a configuration problem on the LMS or NETLAB+ side. Everything up to that point worked; the browser declined the session cookie. The same learner launching from a different browser is the quickest confirmation.

Two other dialogs change inside the frame. When the learner logs out of NETLAB+ from within the LMS page, the logout dialog offers Close in place of a link to log in again, since the way back in is the lab link in the LMS. When the NETLAB+ session expires inside the frame, the dialog asks the learner to reload the page in their browser to renew the session.

Note

An LMS that opens external tools in a new browser tab rather than a frame avoids the third-party cookie question entirely, because NETLAB+ is then the top-level site. Whether a link opens in a frame or a new tab is a setting on the LMS side.