gistfile1.txt

The problem is the way EDX implemented LTI. The parameter tool_consumer_instance_guid is not required, but strongly recommended, because is the only way for uniquely identification of the origin of the LTI request.

See what the specification (http://www.imsglobal.org/LTI/v1p1/ltiIMGv1p1.html) says:

tool_consumer_instance_guid=lmsng.school.edu
This is a unique identifier for the TC.  A common practice is to use the DNS of the organization or the DNS of the TC instance.  If the organization has multiple TC instances, then the best practice is to prefix the domain name with a locally unique identifier for the TC instance.  In the single-tenancy case, the tool consumer data can be often be derived from the oauth_consumer_key.  In a multi-tenancy case this can be used to differentiate between the multiple tenants within a single installation of a Tool Consumer. This parameter is strongly recommended in systems capable of multi-tenancy.

They don't even announce the product code which is fundamental for profiling!

tool_consumer_info_product_family_code=desire2learn
In order to better assist tools in using extensions and also making their user interface fit into the TC's user interface that they are being called from, each TC is encouraged to include the this parameter.   Possible example values for this field might be:
                learn
                desire2learn
                sakai
                eracer
                olat
                webct
This parameter is recommended.

Now, yes, we can workaround using a custom parameter, I would need you to add it as

custom_tool_consumer_instance_guid=yourhost.yourdomain.com

It would be used for all the links.


Now, there is another option. If you can't add custom parameters or it is going to be a difficult to add custom parameters, we can make a change to our LTI broker to force the use of your domain, but it is going to take some development time.