I'm building an xAPI compliant LMS, using https://learninglocker.net/ as our LRS. Admins can upload a zip file containing an xAPI package. The LMS will unzip it, find the launch file, and allow users to launch that URL, passing in credentials for our LRS as query parameters. The package can then report whatever it wants, directly to our LRS, without our LMS having any control over it.
Additionally, since the LRS credentials are in plain view in the url, tech-savvy users could use them to write any records they wanted to the LRS.
What's the standard approach to avoiding this? Currently the only solution I can think of is to not give packages access to our LRS, and instead proxy all requests to our LRS via our LMS, and give packages access to that proxy endpoint.
Is there a better approach?
The proxy approach should work and is the least burden on the LRS.
In our implementation we use an auto generated short lived (configurable) token that has limited permissions to the LRS. This naturally requires the LRS to have an implementation of a permissions model that allows for such things, I don't know if Learning Locker does (or will). In this setup the user still has direct access to the LRS, but the risk is low because of the limitations on access.
My other suggestion would be to look into cmi5 rather than implementing the Tin Can launch guidelines (which is presumably what you've found). It won't help with the LRS permission model, but is on more of a standards path and is specifically for xAPI based content in the LMS model.