Temporarily using a Desire2Learn API key for another domain

Question

Q: Are "domain limited" Desire2Learn API keys 100% locked to the D2L domain they were issued for, or can they be used in a pinch for work on a different domain -- say, several weeks of testing an upgrade?

Details specific to our case:

My institution is preparing to upgrade our D2L Learning Environment. We have one Production LE and one Dev LE, and we're expecting to get a 2nd Dev LE specifically for upgrade testing (all 3 instances hosted by D2L, fyi).

We have 2 homegrown Valence client apps to test with the upgraded LE. I know that our Valence API keys were issued specifically for our existing (not upgraded) Dev domain. I also know our client app is hard-coded with that key.

But it's not clear to me whether we have to get a new API key and edit our client app accordingly, or whether we can use the existing key on a "wrong" domain for just a few weeks while we're testing the upgrade.

Could such an arrangement be used temporarily?

Answer 1

There are several possible approaches; the one you choose will depend upon your circumstances.

Use another test application's key already granted for the new domain. If you already have an App ID/Key granted for an application limited to your new DEV2 LE, then you can try using that application's credentials temporarily. This would require rebuilding, or reconfiguring, your client application with the new credentials. We do not recommend this approach because for effective testing you definitely want to have traceability as to which application is making which calls to the LE; however if you already have a set of app credentials for a narrowly deployed test application, for example, you can in a pinch switch to sharing those credentials.

Use the LMSID/Key credentials from DEV1 LE on DEV2 LE. The "domain limitation" applied to app keys corresponds to the LMSID/Key credentials assigned to an LE instance at deployment. If your DEV2 instance is only being floated to test integrations in an upgrade scenario and these integrations are already (in their test form) all working against your DEV1 instance, then it may be possible to have your DEV2 LE use the same LMSID/Key credentials as your DEV1 LE. This would mean that the DEV2 LE fetches its known-application credential list from D2L's Key Tool Service, it will get exactly the same list of credentials as given to the DEV1 LE. This is the most radical suggestion, will require D2L's Support Desk to get involved, and will most definitely require shepherding by your DEV2 LE's Approved Support Contact -- this kind of deployment can make sense for certain very specific kinds of testing LMS instances, but it is a very big hammer to apply, so it may not be the right choice here.

Note that this solution is the only one that will work if you have no access to change the application's code/configuration itself (an the app credentials are baked into the app) -- if the app you want to test must work against an LE that acts as if it were the DEV1 instance, then this may be the only solution possible, and in this case you may have to wait until the upgraded LE gets deployed on DEV1 to test your application. I am not at all confident that a granted set of app credentials can be "repointed" to a new domain limitation.

Apply for a new application ID/Key pair, and work to expedite the request. The chief latency in granting application ID/Keys and deploying them lies in having the partner and or account managers for the target LMS Domain in question approve the request: if you line up your partner and/or account manager on your end with the situation and ask them to shepherd the request, this latency can get lowered. This would be the desired choice, because it uses the "proper channels" with the existing business relationship in a way it was intended to be used.

Getting a new set of application credentials for a test app in your new DEV2 domain should not take very long, especially if you already have an existing relationship that's been exercised to get app creds granted through a partner and or account manager. This solution still requires you to change/re-configure your app.

If at all possible, you should take this last path.