Skip navigation
All Places > System Administrator Community > Blog > 2019 > October

Continuous Improvement in SaaS

Posted by dg35344 Oct 23, 2019

With SaaS continuous delivery, Blackboard can quickly respond to specific issues that affect our users. We know problems with new releases could seriously impact teaching and learning, so we push new releases to Test/Staging environments 3 weeks before moving into full Production. This way, working with our clients we can identify any potential problems early and fix them as quickly as possible. 


For evidence of our improved agility, look no further than two recent bug fixes in Assessments and Grading in the Ultra Course View. Our thanks go out to the clients that helped to raise these issues directly and in a timely fashion. Wade Fields


1) Correct and credited answers to matching questions displayed as Incorrect to some students.

       - This high-impact issue was first reported by a client on September 11 with v3700.11.0 in Test/Staging environments. Our development team quickly identified a root cause and a fix. After internal testing and verification, we pushed the fix to Test/Staging environments—crucially, ahead of the scheduled Production release. 


2) When instructors reused a question pool, answers to Multiple Choice questions didn’t randomize correctly.

       - This high-impact issue was client reported on October 7 with v3700.11.0 in Production environments. Our development team quickly identified a root cause and a fix. We’re now completing internal testing and verification, and within the week the fix will be pushed to both current Production instances and v3700.14.0 Test/Staging environments.


We are looking to interview system administrators who oversee Blackboard Learn Ultra at their college or university. Remote interviews (conducted online) will take place on Thursday, October 31, and last approximately 45 minutes. Participants will receive $75 as a token of appreciation for their time.


If you are interested in learning more and signing up, please visit this link. (

November 12th UPDATE:  The Rustici SCORM patch will be included in SaaS version 3700.16, Q2 2019 Cumulative Update 5 (3700.0.5), 9.1 Q4 2018 Cumulative Update 9 (3500.0.9) and 9.1 Q2 2018 Cumulative Update 14 (3400.0.14).  All three Cumulative Updates are targeted for general release on Thursday, November 14th.  Flexible Deployment Option clients will receive Q2 2019 Cumulative Update 5 to Test/Stage environments on Wednesday, November 20th and Production on Wednesday, December 4th. 


October 10th UPDATE: The Google Chrome team is postponing the changes until version 80.   There isn't a release date for version 80 yet but based on their release cadence, it could be available in January. 


On October 22, 2019, Google Chrome will release version 78 of Chrome to users which removes key functions that may impact a user’s ability to complete SCORM-related Assignments and Assessments.  Google Chrome 78 (and later versions) may block the completion of the course when users exit the course by closing or navigating away from the window containing the SCORM player. Relevant details such as completion, success, score, and duration would remain in an incomplete status even though the user completed the course.


Rustici has provided a patch that uses other mechanisms that are not blocked in Google Chrome version 78 (or later versions).  Blackboard is quickly working to include the fix in a Learn SaaS release as well as Cumulative Updates for Learn 9.1, Q2 2019, Q4 2018 and Q2 2018.  In the meantime, Rustici has provided a workaround for end users.


Users can disable the new behavior in Google Chrome version 78.  Workaround details provided from Rustici include:


1. Chrome has a flag that can be modified to change this behavior in a user's browser. The user can navigate to chrome://flags/#allow-sync-xhr-in-page-dismissal in the browser and enable it.
     Note: in Chrome 77, there is a preview setting #enable-forbid-sync-xhr-in-page-dismissal that can be used to test the behavior before the release goes out.


2. This flag can also be set using the AllowSyncXHRInPageDismissal enterprise policy flag, if that's something being used by your organization.


3. There is also a temporary opt-out available via GoogleOrigin Trial "Allow Sync XHR In Page Dismissal". This feature allows you to register your domain for a token that you can then include in a header when serving the player files, and it will trigger Chrome to enable the synchronous requests during page dismissal. More details about enabling and using this method are outlined in this Google page.


This workaround is planned to be available until Google Chrome version 82 which is planned to be released in April 2020.


You can read more about the Chrome 78 issue on Rustic’s knowledge base page.

guardLogin pages are important.  There are many UX principles and security regulations that apply to them.  Among many good ideas, we want login pages to be aesthetically appealing and guard the main doors to the system.  It is best when users type in credentials to the same login page across the organization (such as in Shibboleth technology) instead of retyping the same credentials on multiple login pages (such as LDAP and others).  This moves many organizations to use SAML/Shibboleth as web authentication technology.  In Blackboard Learn this is called third-party account.


The problem:

If an administrator configured SAML/Shibboleth for Blackboard Learn, an authentication URL is created automatically on the default login page (sample default page URL:  However, the Username and Password prompts remain.  On a custom login page such prompts can be removed and direct link can be used (sample direct link URL:  Since Shibboleth requires web interfaces, the Blackboard mobile app must be forced to the web with "Web Login".  Unfortunately, after password is accepted users are forwarded to the main Institutional Page location.  In iOS the mobile app doesn't recognize it as a successful login and integrations, such as Panopto SSO, are not correctly redirected to their destination.



As long as you provide the default login page in the Blackboard mobile services B2 "change mobile login url", students will be able to use the default prompts or use the drop-down selection to Shibboleth on the default page with this design:


default prompts



So what's the problem with the workaround?

We would like the custom page to work for the mobile apps and third-party integrations without default login prompt.  This keeps the institutional branding consistent.  Also, if the organization uses only Shibboleth the default black (above picture) Username and Password prompts will not work.  It is necessary to use the link in the bottom drop-down.  The prompts will work with LDAP or internal database authentication, but these may be disabled.  As a security principle, we don't want users to put username or password into any other prompts but the main organizational Shibboleth prompts.  We would also like to understand the root problem. 


As a side note, the name Shibboleth has an interesting story:

Shibboleth - Wikipedia 


Let's get started.  The customization of the Blackboard login page provides important benefits to student engagement and system adaption.  Much can be communicated and advertised. Nathan Cobb wrote up a great piece on how to create a custom login page to Blackboard Learn: Show us your ... Learn Ultra Login Page .   


The basic design is to use the a starter file with about 100 lines of code that begin like this:


<!-- This login.jsp file is tagged with comments identifying sections for easy editing -->

<!-- This section below calls various servlets from the Learn environment and other things you don't want to touch. Do not delete anything in this section -->
<%@ include file="/webapis/ui/doctype.jspf" %>
<%@ page import="blackboard.servlet.util.CourseCatalogUtil" %>



You can download the full starter file here: 


This is  a great start, but it includes design elements, such as credential prompts, which are not wanted in Shibboleth-only approach.  What if you don't want to display the Username and Password prompts that require either local database authentication or LDAP?  Again, if we're using Shibboleth, the internal prompts will break our login process.


So, out of necessity, some administrators created a custom login page with a simple link to the third-party authentication URL.  This link can be extracted from the default login page drop-down.  Here is a simplified code of a custom page that works and uses Shibboleth only:


<a id="loginurl"

Sign In</a>



The code above is a minimalistic approach, but will work perfectly for logging into Blackboard Learn in a browser.  It will process Shibboleth prompts, and redirect back into /ultra home.


However, at this point the mobile app, which has to be switched to forced web login for Shibolleth prompts, will not work.  Support sometimes applied this known issue to tickets reporting the behavior:

MOBI-9602 - iOS 4.4 Doesn't Poll to Native View after External Authentication Until a User Action - Persisting Behavior of MOBI-9247

Article #000050914 - iOS Doesn't Establish Native Session View after External Authentication Until a User Action  


The problem is not with iOS or the mobile app.  The problem also persists in any external single signon application such as Panopto.  So, the functional workaround is to force the mobile app to the default login page and enable at least LDAP to get the prompts workings.


The root cause of this behavior is the redirectUrl and new_loc URL parameters.  If you trace the clicks, the login page from the mobile app or Panopto includes a return URL to successfully receive the authenticated session.  Ok, so there is a JS that can be added to the login page to capture new_loc and forward properly.  After writing that code, it became obvious that there is a better way, more maintainable and sustainable across future upgrades.


The successful trick is to display the Blackboard generated login prompts with the custom drop-down, then hide them, then assign back in HTML the properly formatted custom login URL.


This is how it works:


/* onLoad event on body tag let's us wait for all HTML elements
to be loaded before we detect the custom authentication URL */
<body onLoad="setLogin()">

/* include any HTML/CSS/JS code you have for your custom page.
The only important element below is id="loginurl",
which will let you replace the href dynamically.
The link can be anywhere on your custom login page. */
<a id="loginurl"
href="" >

Sign In</a>

/* this section will build the hidden login prompts with
correctly structured third-party URL.
We are going to pull the first row from the drop-down,
so the first URL in case you have multiple. */

<%@ taglib uri="/bbNG" prefix="bbNG" %>
<%@ taglib uri="/loginUI" prefix="loginUI" %>

<div id="login-form" class="login-form"style="display: none">
<loginUI:loginForm />

<script lang="JavaScript">
function setLogin() {
var a = document.getElementById("loginRedirectProviderList");
var b = a.getElementsByTagName('a');





This approach will fix the login process to the mobile app, SSO to Panopto, and ensure that Shibboleth authentication prompts are presented at the login page and all integrations entry points.


This article applies to Blackboard Learn clients who are not using LDAP, local database authentication, but instead try using SAML/Shibboleth by itself.