I don’t spend much time replying to support tickets these days, but for a long time that was a core part of my job as a software developer at Rustici Software. (We don’t put many barriers between the people who buy our software, and the people who make it.) Whenever a customer opens a support ticket, it means that something went wrong. That is always a frustrating experience. We do our best to understand the issue, empathize with the user, and most importantly, find a solution. To me, the most frustrating tickets that we get for Content Controller are actually very easy to understand and solve. It’s just that implementing the right solution is out of our hands, and our customers’ as well.
Whenever we set up a new instance of Content Controller, we default to allowing only secure HTTPS connections, because that’s the right way to set up any web application, especially an eLearning application that deals with personally identifiable information, and intellectual property that needs to be protected. But besides protecting the data that’s being transmitted, HTTPS also protects against harmful data being injected into an otherwise benign website. There is really no good reason not to use HTTPS, and most LMSs already do. As long as that’s the case, then everything is fine for our customer, and all their customers, and all their customers’ learners, and everyone is happy. For a while.
Then, almost inevitably, a new client comes on board with an LMS or next gen eLearning platform that only supports non-secure HTTP connections. They’ll import a Content Controller dispatch package into their LMS, try to launch it, and it won’t work. The actual error message depends on how the systems are configured and what browser is being used, but it always comes down to the same thing: one end of the pipe is using HTTPS, the other isn’t, and the browser (quite reasonably) won’t allow them to communicate with one another.
This is the point where our customer opens a support ticket, and once the problem is identified, we ask them if they can please ask their client to enable HTTPS for the client’s LMS, so their system and Content Controller can communicate securely. This usually means their client needs to relay the request to their LMS vendor, which can go one of two ways: either they enable HTTPS, or they don’t. There’s not usually much we can do to help convince the vendor, because we’re three steps removed from them, but they often don’t need much convincing. Using HTTPS should be a no-brainer. It ensures that data is transmitted securely, and learners are protected from dangerous man-in-the-middle attacks.
Despite that, sometimes LMS vendors decide not to enable HTTPS. We’re not usually a part of that conversation, so I’m not aware of what reasons are given. I assume they’re often along the lines of “Our LMS is working correctly, and no one else is experiencing a problem. It must be your content.” At this point, our only recourse is a workaround that neither we nor our customers are ever happy with: allowing non-HTTPS connections to their Content Controller service, so their client can launch content from their LMS. Learners coming in from other, HTTPS-supporting, LMSs will still have a secure connection, but the new client’s learners are exposed to all the risks that come with sending and receiving data across the internet in the clear.
That’s why HTTPS-related tickets are my least favorite: There’s a solution that is clearly correct, and better for everyone involved, but it isn’t up to us, or our customers to make it happen.
