Participating Frequently

Question

SCORM 2004 Bookmarking issue with new update

Forum|Forum|9 years ago
July 22, 2016
8 replies
2456 views

My team has spent countless hours trying to find a hack, fix, or solution to what we are currently experiencing. So, without further ado....

**Scenario 1 (Issue - browser not closed)**

User 1 logs into our LMS and launches a Captivate 9 (after April /May 2016 version) HTML5 course for the 1st time and watches 5 pages. User 1 then logs out, BUT they do not close the browser. User 2 logs in and launches the same course for the 1st time and the course pops up the Bookmark option to go where the left off. The issue is that User 2 should have been taken to page 1 without a popup. All browsers act the same way.

**Scenario 2 (No Issue - browser closed)**

The same as above, but User 1 shuts down the browser forcing User 2 to open a new browser session. User 2 does not experience the bookmark issue (clean slate).

**Scenario 3 (No Issue - browser not closed or closed)**

User 1 logs into our LMS and launches a Captivate 8 or 9 (pre April 2016 version) HTML5 course for the 1st time and watches 5 pages. User 1 then logs out and either close or do not close the browser (makes no difference with older Captivate). User 2 logs in and launches the same course for the 1st time and the course launches without the bookmark popup.

**Things we have tried**

We updated our logout functionality to try to force a session destroy and to kill any cookies. This has resulted in a new session ID for every logged in user, but does nothing for the "cached" bookmarking issue. Code that we have used is below. Is there anything else that we are missing or way to enforce Captivate to not look at a local bookmarking variable or cache and look strictly at the LMS cmi.location data in the database?

*************************************

// Initialize the session.
// If you are using session_name("something"), don't forget it now!
session_start();

// Unset all of the session variables.
$_SESSION = array();

    // If it's desired to kill the session, also delete the session cookie.
    // Note: This will destroy the session, and not just the session data!
    if (ini_get("session.use_cookies")) {
        $params = session_get_cookie_params();
        setcookie(session_name(), '', time() - 42000,
            $params["path"], $params["domain"],
            $params["secure"], $params["httponly"]
    );
    }

// Finally, destroy the session.
session_destroy();

*************************************

This topic has been closed for replies.

C

christiansen75Author

Participating Frequently

Well, Adobe released a new update to Captivate and it did not address the issue above. Apparently it will require LMS providers and content developers across the world to report this same issue if their end users use shared environments and have difficultly getting them to close the browser after they logout. It's a shame that we now have to hack systems because Adobe changed how they lookup the bookmark location in SCORM courses. I guess it may be time to take that jump to Storyline as our primary tool and put Captivate to bed........

C

christiansen75Author

Participating Frequently

Well, during our troubleshooting, we found that Captivate is looking for local storage 1st and then at the database 2nd for the location. Since this does not work well for shared environments, we pursued wiping out the cookie that it is creating. Hoping to do this on a global scale failed because we could not call up or find the cookie from the LMS itself. The cookie could only be found from within the course content. The fix?

We created a custom JS file that overrode the existing window.DoCPExit function in CPM.js file. We added document.cookie = "" + "=;expires=Thu, 01 Jan 1970 00:00:01 GMT;"; as the 1st command before firing off any of the exit functions. This took care of the cookie when using the internal exit button. For the browser button, we created an onunload function in the index_scorm.html file that used document.cookie = "" + "=;expires=Thu, 01 Jan 1970 00:00:01 GMT;"; to delete the cookie. Now, both the exit button and browser exit button clear the cookie.

After testing, Chrome is the only browser thus far that this will not work with. Chrome is unable to find cookies that have no name, therefore, it cannot delete what it cannot find. We have tried the js.cookie and jquery.cookie libraries too and that also fails on Chrome. On to the drawing board.

M

Michael27983093gma1

Participant

I know this is quite old, but I have a solution to finding nameless cookies. It can be done in Chrome (at least recent versions) by first finding the index of the nameless cookie (not too much trouble), then applying the epoch expiration date as if the value were the name. It looks like this:

// Get an iterable list of cookies
var cookiesobj = Object.fromEntries(document.cookie.split('; ').map(c => c.split('=')));
// set up a receiver variable
var nameless = false;
Object.keys(cookiesobj).forEach((name)=>{
// cookie without name becomes name without value, so we test for an undefined value
    if(cookiesobj[name] === undefined) {
        nameless = name; 
    }
});
// If a nameless cookie exists, delete it
if(nameless !== false) {
    document.cookie = name+expires=Thu, 01 Jan 1970 00:00:00 GMT";
}

I haven't yet implemented this within my LMS, but I have tested against a module with self-paced enabled - and was able to delete the cookie.

M

Michael27983093gma1

Participant

I typo'd the document.cookie line, it should be:

if(nameless !== false) {
    document.cookie = name+";expires=Thu, 01 Jan 1970 00:00:00 GMT";
}

C

christiansen75Author

Participating Frequently

As a follow up, our LMS and other LMS's create a session when a user logs in. On log out, we are destroying that session. But, what we are noticing is that Captivate creates a different unnamed cookie when it launches a course. This cookie has data that looks like "41/1/0,1,2/0,1,//2". This is the cookie that is remaining behind after the LMS logs out and the browser is not closed. If we can determine how to destroy this cookie and its data, we can circumvent the bookmarking issues.

RodWard

Community Expert

Maybe this will help:

javascript - sessionStorage.clear() not working - Stack Overflow

C

christiansen75Author

Participating Frequently

I tried that exact code earlier to no avail. That is when I started looking into what cookies Captivate was creating and found the nameless one that the player is using for bookmarking. If I can figure out how to destroy that one, I think we can find a hack to the issue. It is more difficult because it does not have a name. Even when using document.cookie, the nameless cookie won't show.

C

christiansen75Author

Participating Frequently

To other users of Captivate 9.0.1.320, bookmarking will no longer work properly for any user that is using a shared environment without each user shutting down the browser completely after logging out. Although we encourage users to always close their browsers after logging out of any app for security sake, it is near impossible to ensure it happens. For this scenario and for those that create training for users that share devices, be advised that a change in the Captivate code base has introduced a bug. Adobe's "solution" is to turn off bookmarking (Never Send Resume Data). This is not an option for a lot of developers because it removes the ability for users to resume where they left off (a basic SCORM function). I would advise updating to this version until Adobe fixes the issue. As of today, I was told this was not a bug, but they would "look" into it. If anyone else is experiencing this, please contact Adobe and add additional pressure.

M

MidNite_Media

Known Participant

I have Captivate 9.0.1.320 and, prior to this latest update, bookmarking worked the way it is intended in the SCORM environment. Since the upgrade, Captivate maintains a user's bookmark data, returning the student to where they left off (as it should). However, if that student logged out of their LMS and another logs in with their own unique credentials, Captivate resumes the previous student's bookmark. It is as if the bookmarking were cached locally somehow. I understand that if you completely shut down the browser between students, this bookmarking may be reset, but in many corporate training environments, a student logs off but leave the LMS open for the next student. It is impractical to require the training computer to completely shut down its browser between students (I understand that, for security sake, this should be a best practice - but in reality, this is not the case). This is especially true if that computer were used by other individuals (shared) such as by management or HR where other applications are required to be active all the time in another tab or window (billing, staffing, scheduling, etc.). If someone has to completely shut down the browser to eliminate the bookmarking of a previous session, then management will insist on another tool be employed for training their people. If Adobe's solution is to "shut off" the bookmarking feature, then it completely eliminates one its primary purposes such as tracking student progress on a LMS. This is unacceptable and cause for major concern! You don't mask a "bug" by making us turn off the required and requested "feature" of training departments everywhere. I hope Adobe addresses this problem very soon and releases a "patch" or new version.... before we start migrating to Storyline or Lectora.

RodWard

Community Expert

I'm afraid I have to agree with Adobe here that this is NOT a "bug".

If the current OS user session has not changed (i.e. the different course learners are NOT logging out of the OS and logging in as a different user) then the browser will continue to save and retrieve data from the same local storage location until its session is terminated. That's just the way most browsers are designed to work and your specific requirements are for the browser to somehow discern that the local storage location should change according to which user is logged into the LMS.

As far as the browser knows, the OS user hasn't changed, the web server hasn't changed and the content is coming from the same web address folders, and the content files are all named exactly the same (because each user is viewing the same course), so why should it decide to use a different local storage?

So the reality is simply that unless the browser session is terminated, the browser has no reason to ditch the Local Storage data and start again just because that user happened to change their login credentials for the LMS.

The current behaviour may not be the way you want it to work, but it makes perfect sense to me.

adtiwari

Adobe Employee

Hi David,

I tried scenario 1. I was not able to see the issue, when self-paced learning was unchecked. We need to investigate what is going wrong at your end. I would request you if you could send me the link to your course by uploading to Scorm Cloud. Mailto: (adtiwari@adobe.com)

Thanks,
Aditya

C

christiansen75Author

Participating Frequently

Aditya,

I have sent an invitation from Scorm Cloud to a sample course that we are having issues with. I have tested using 2 different accounts. If I launch it with one account, log out without shutting the browser, and then login with 2nd account, I still get the bookmark popup when I shouldn’t.

The invite will be for the InfoSec Basics course.

Regards,

David

Moderator: I took out your personal credentials, too dangerous on a public forum.

C

christiansen75Author

Participating Frequently

I would have to disagree. SCORM courses are supposed to by default use cmi.location and/or cmi.suspend_data to get and set bookmarking to and from the LMS database through the SCORM API. These are SCORM courses and until recently, have always used bookmarking from the database as it should. Something has changed recently that is causing the users of our LMS issues when accessing training on shared computers.

Lilybiri

Legend

Bookmarking by TOC is disabled when you upload to a LMS. But what I wrote about cookies/local storage is correct, provided you don't use a LMS.

C

christiansen75Author

Participating Frequently

Thank you for your comments, but as you can see from my comments, we are using SCORM 2004 published content in an LMS AND using a TOC. Therefore, local storage should not be used and causing my issue, but somehow it is. We are looking for an answer to the issue we are experiencing.

For additional context, our development team has been using Captivate since its inception and are advanced users using advanced actions and continue to push Captivate to its limits in what it can do.

C

christiansen75Author

Participating Frequently

We are. We do want the learner to have saved bookmarking for most courses. We have tried to turn off the self paced learning option for the TOC to see what would happen, but that still took User 2 to the "bookmarked" page from User 1, but without the normal popup option. What is disheartening to us, is that this issue has only surfaced in the latest update to Captivate 9. We have been using the same settings for our courses for the past 2-3 years and this is just now starting to happen. It definitely is not related to our LMS because no changes to the SCORM API or SCORM Player has been made in the past 9-12 months.

Lilybiri

Legend

Bookmarking by TOC is using local cookies or local storage (depending on output), which means it is logical what you see if multiple users are using the same system to enter the course.

TLCMediaDesign

Inspiring

Are you using a Table of Contents in the course?

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded