问题
I'm hoping someone could enlighten me on the way authentication works with the new D2L REST API. From my reading and playing with the "GetStarted" example code it seems that calls are based on the "User Identity Level" and "User Acceptance".
For us, this is a bit problematic.
We haves several custom tools where a student completes an activity (outside D2L) and is given a grade. These tools are set up so that the grade provided in this manner are associated with a grade book column for a given course in our D2L instance. Currently with SOAP, we just use a privileged web services account so that when a student completed the task, the grade was automatically exported to the associated grade book column in the given course.
My understanding from the REST documentation is that it is no longer possible to use a privileged web services account, as it would have to sign in and accept the use of the tool each time. The student completing the task wouldn't have this information (nor would we want them too) and the student level of access wouldn't allow him to upgrade the grade book column so we wouldn't be able use his "User Identity" either.
The only alternative I can think of would be to store all the grades else where. Then, when appropriate, the instructor for the course would sign on and batch update the grade book using their "User Identity Level" and "User Acceptance"?
Is this correct?
For us, this is very cumbersome as we rely on own tool's authentication methods and the privileged web service accounts quite a bit.
回答1:
An extra manual login is not required and there are two alternatives that I have seen used in this scenario. Both utilize the fact that the Valence authentication system uses keys and signatures. By using signatures rather than sending tokens even plaintext apis are not subject to session hijacking and as a result keys can safely remain valid for a long time. This period is typically set to 30 days, but, when applications like the one you describe are in use it is best to have no timeout. You can contact support about adjusting this timeout for your server. (Keys are still reset if passwords are reset or if they are explicitly revoked).
With long lived keys the following scenarios are possible, without the application directly receiving or storing the users password (key storage still needs to be done securely):
Instructor account context: If the application workflow already requires an instructor to activate or configure the process the userid and userkey for that instructor can be retained during the intial session and later used to submit the grades. This does not require any special accounts or elevated priveleges, but, only applies if the workflow already involves the instructor context.
Utility account context: If the application does not involve an instructor, it is possible to create a utility account that has permissions to update grades. This is often the approach already in use with D2LWS, but, with an extra step. In this scenario, the keys for the utility account are established out of band (for example the getting started sample (http://docs.valence.desire2learn.com/samples/gettingStarted.html) will display the keys). Alternately an install or config type process can be created that automatically records the keys from the utility account. After these keys are recorded no additional interactive sessions are required.
来源：https://stackoverflow.com/questions/9946274/authenticaton-method-for-desire2learn-rest-api-vs-soap