I just finished an exhaustive study of the IIS web logs for our site and see clearly the issue results in a loss of session data such that when the dialog comes back inbound from Cengage to Moodle, it cannot hook up correctly (see following), so it causes Moodle to require whoever is using the module to re-log into Moodle. After that login, the session key changes to reflect the new login.
The dialog back to Moodle doesn't appear to be done by way of a query string that would utilize "slash arguments". The traffic coming back to IIS is a POST, not a GET. The query string coming back into Moodle has the form of:
If there was more to the query string (like a long string of slash arguments) I could troubleshoot more. But IIS does not provide the post data in website log files. And for that matter I don't know any web server that would because post data can be very lengthy like in the case of uploading a file.
The dialog back to Moodle doesn't appear to be done by way of a query string that would utilize "slash arguments". The traffic coming back to IIS is a POST, not a GET. The query string coming back into Moodle has the form of:
course=(course id)&id=(external tool instance id)&sesskey=(moodle session number)
If there was more to the query string (like a long string of slash arguments) I could troubleshoot more. But IIS does not provide the post data in website log files. And for that matter I don't know any web server that would because post data can be very lengthy like in the case of uploading a file.
So my summary conclusion at this point is the POST data is the root cause of the hangup.