API Tin Can xAPI Отправка защищенных отчетов в LRS
Что-то, кажется, ускользает от меня в отношении xAPI. Я постараюсь сделать это по-настоящему простым (и, возможно, даже глупым).
Что я понимаю, чтобы быть правдой...
Любой контент, реализованный в Tin Can, можно запустить с помощью панели запуска. Модуль запуска предоставляет конечную точку и информацию об аутентификации. Конечная точка не должна быть LRS. Это может быть скрипт, который затем передается в конечную конечную точку, которая является LRS. LRS, в данном случае частное облако SCORM (песочница), не может получать отчеты без базовой аутентификации.
Что мне нужно знать...
Генерирует ли LRS токены OAuth? Как бы кто-нибудь передал оператор из файлов Captivate, Storyline, lectora в TinCan_PHP для обработки защищенного соединения с LRS? Зачем мне использовать TinCan.JS, когда базовая информация об аутентификации легко передается конечному пользователю, которая затем может быть использована для нанесения ущерба LRS?
Я совершенно не в курсе?
Большое спасибо...
2 ответа
Просто некоторые пояснения для будущих пользователей по вашему пониманию...
Средство запуска может предоставлять конечную точку и аутентификацию, что является одним из сценариев и, вероятно, основано на рекомендациях по запуску, которые вышли со спецификацией 0,9. Есть и другие способы обработки рукопожатия, например, как это делает cmi5 (который не обязательно более безопасен, за исключением того факта, что учетные данные могут быть запрошены только один раз, и им намеренно отказывают в определенных привилегиях, таких как аннулирование операторов).
Я бы посчитал ваш "сценарий" "несоответствующим" LRS в том смысле, что он получает операторы (в форме запросов xAPI), но не обеспечивает полного соответствия LRS. LRS SCORM Cloud не может получать выписки без какой-либо аутентификации, но вы правы, основной вариант предпочтительнее, потому что OAuth там не имеет большого смысла для производства.
По вопросам...
Да, LRS генерирует токены OAuth, но для наиболее распространенного подхода контент должен иметь уже установленные отношения с этим LRS, а учетная запись на основе OAuth должна быть в LRS (или система, с которой LRS тесно связана, как LMS) не с каким-либо провайдером OAuth в дикой природе (то есть вы не можете использовать учетные записи в Twitter, Facebook, Google и т. Д., Что часто вводит людей в заблуждение).
Они не будут, все эти продукты уже поддерживают прямую связь с LRS через руководства по запуску (Basic Auth), любая система, с которой они взаимодействуют, должна иметь как минимум достаточную функциональность LRS для их поддержки, которая включает в себя API-интерфейс State помимо API-операторов Statements,
TinCanJS сам по себе не является решением только для браузера, есть люди, использующие его на стороне сервера, поэтому язык - это отдельная проблема. Также возможно использовать TinCanJS вне общей парадигмы запуска, и в таких ситуациях возможно, что у пользователя есть индивидуальные учетные данные с рассматриваемой LRS (или системой, которая связана с LRS), и они вводят ее самостоятельно. Букмарклет является хорошим примером приложения.
В итоге все наборы учетных данных должны убедиться, что ваше приложение взаимодействует с LRS через http, и в этом случае используемые учетные данные не являются открытыми, а затем уточните у поставщика LRS, можно ли использовать учетные данные. которые недолговечны и имеют ограниченные разрешения. Это может привести к небольшому "вреду", который может быть нанесен должным образом реализованным LRS, за исключением отмены заявлений или перезаписи (удаления) сохраненных документов, которые могут быть ограничены при использовании надлежащей схемы разрешений и ограниченных полномочий.
Чтобы ответить на ваш вопрос, да, вы совершенно не в курсе!:-)
Если вы отправляете утверждения из курса электронного обучения на основе javascript куда-то, тогда соединение по своей сути небезопасно. Добавление другой (защищенной или иной) ссылки в цепочку после того, как это небезопасное соединение не повышает вашу безопасность. Вы также можете отправить заявления xAPI непосредственно в LRS.
Вы также можете использовать обычную HTTP-аутентификацию. Во-первых, это то, что поддерживают все инструменты авторинга, так что вы должны. Во-вторых, использование OAuth вместо Basic Auth для соединений на стороне клиента похоже на использование блокировки клавиш вместо кодовой блокировки и последующего оставления ключа под матом. Замок с ключом (OAuth) может быть более теоретически безопасным, чем кодовый замок (Basic Auth), но не на практике, если вы оставляете ключ под ковриком (встроенный в код на стороне клиента).
Посмотрите этот SO вопрос-ответ для трех вариантов того, что вы можете сделать с безопасностью аутентификации xAPI.
И просто для полноты: да, в случае OAuth LRS генерирует токены. См. Спецификацию xAPI для самых последних деталей.