Getting Invalid Token response when trying to create D2L user account - desire2learn

Question

I am trying to modify a D2L database from within a 3rd party application using their Valence API. I've gotten some operations to work but am stuck trying to create a new user account. I have been told that the account I am working under is authorized to do this.
I’ve defined a JSON object to hold the values I want:
{
"OrgDefinedId": "XX000TEST",
"FirstName": "Tom",
"MiddleName": "",
"LastName": "Foolery",
"ExternalEmail": "tom#something.com",
"UserName": "Tom.Foolery",
"RoleId": "78",
"IsActive": "true",
"SendCreationEmail": "false"
}
I copied the above text to the HTTP post buffer and then called the following link:
/d2l/api/lp/1.0/users/?
The parameter string contains the IDs and signatures (x_a, x_b, etc) as specified in the Valence docs. I assume the authorization values are correct, since I'm getting correct results when using the same algorithms on other Valence queries.
Any suggestions on how to get past the "Invalid Token" message would be appreciated.
--stein

Answer 1

If you're getting a 403 "Invalid Token" message then you are not, for some reason, forming your x_a, x_b, x_c, or x_d authentication tokens correctly. Common problems we have seen in the past are:
Trying to re-use x_c and or x_d signatures generated for one API call with another
Getting the tokens swapped around: x_a is App ID, x_c is App Sig, x_b is User ID, and x_d is User Sig
Generating the signatures using the wrong HTTP method (the method is one of the components of the base string for the signatures)
Not using all upper case letters for the HTTP method in the base string (the component should be GET not get)
Not using all lower case letters for the API route in the base string, or including incorrect characters: for example, in your question, you seem to imply that you're passing in the ? as a part of the route; you shouldn't do this. In this case, your base string for creating the URL should be POST&/d2l/api/lp/1.0/users/&1234567 where 1234567 should be replaced with the timestamp you generate and also pass in x_t
Using the API route with API version component provided, but when calling, using another version component (i.e. generating with /d2l/api/lp/1.0/... but calling with /d2l/api/lp/1.1/...)
Using an incorrect/mismatching timestamp value in the base string (the timestamp you use for the basestring should be in seconds, and be the same stamp as the x_t value)
While calls previously worked, suddenly none of the calls work with a 403 invalid token result: the user tokens could have expired and you need to re-authenticate the user
While calls previously worked against a test instance, when you try moving to a different LMS (prod instance for example) the calls don't work: perhaps the App ID/Key pair hasn't shown up on this new LMS, or you're trying to use the user ID/Key pair from one LMS to generate signatures on a different LMS
Also, notice that your JSON object is strictly not correctly formed: the IsActive and SendCreationEmail properties should have values of true and false respectively, not "true" and "false", although it's possible that the LMS parser on the server side will be forgiving about that.
If none of these points assist you, please feel free to open an issue in our issue tracker, or contact our Valence support email address, and we can try to help you out through this issue.
NOTE Please note that invalid tokens will throw you back a 403 (but the message will be "Invalid Token" or "Expired Token" or similar). If your tokens are correctly generated, but your calling user context is not allowed to create a user, then you'll also get a 403, but this time the message will be "Not Permitted" or "Not Authorized" or similar. Make sure you double check what sort of 403 you're getting back.
In this particular case, the permissions around creating a user are a bit tricky; not only must you have a permission to create a user, you must also have permission to modify the properties that you will be passing into the API in the CreateUserData structure (OrgDefinedId, Email, and so on), and you must also be able to see all those fields in the User Information Privacy settings, and you must have permission to enroll the user role you have provided at the organization level... those last two bits have tripped up some of our clients in the past.