canvas-lms/lib/lti/app_util.rb

60 lines
2.2 KiB
Ruby
Raw Normal View History

#
# Copyright (C) 2011 - present Instructure, Inc.
#
# This file is part of Canvas.
#
# Canvas is free software: you can redistribute it and/or modify it under
# the terms of the GNU Affero General Public License as published by the Free
# Software Foundation, version 3 of the License.
#
# Canvas is distributed in the hope that it will be useful, but WITHOUT ANY
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
# A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
# details.
#
# You should have received a copy of the GNU Affero General Public License along
# with this program. If not, see <http://www.gnu.org/licenses/>.
#
module Lti
module AppUtil
TOOL_DISPLAY_TEMPLATES = {
'borderless' => {template: 'lti/unframed_launch', layout: 'borderless_lti'}.freeze,
'full_width' => {template: 'lti/full_width_launch'}.freeze,
'in_context' => {template: 'lti/framed_launch'}.freeze,
'default' => {template: 'lti/framed_launch'}.freeze,
'full_width_in_context' => {template: 'lti/full_width_in_context'}.freeze,
}.freeze
Render simplified launch params into NRPS v2 responses - Output a smaller version of a LTI 1.3 launch payload for each NRPS v2 member when the NRPS request includes a `rlid` query parameter. - Most claims and custom params from the launch payload are excluded either because: - They describe the context and would thus be redundant, or - They pose performance problems (N+1 queries, usually), or - They are absent from the spec example, e.g. `https://purl.imsglobal.org/spec/lti/claim/version`, or - They require additional development and thus need to be handled as a separate task. - See `memberships_provider.rb` ~line 68 for list of custom params supported in this commit. (More coming later.) - Vast majority of the patch has to do with tests against `JwtMessage`, which was modified to allow claims to be turned on/off via a new white/blacklist mechanism in `AppUtil`. - Custom param white/blacklisting is handled directly in `VariableExpander` to satisfy the LTI rule that unsupported params should just be echoed as-is. This (instead of keeping all the white/blacklist support in `JwtMessage` ensures consistent behavior w/r/t `VariableExpander`'s more sophisticated features, specifically its suport for expanding variables embedded into larger strings. Closes LTIA-40 Test Plan - Configure a LTI 1.3/Advantage tool with the supported set of custom params listed in `memberships_provider.rb` starting ~line 68. If using the POST `/api/lti/accounts/:account_id/developer_keys/tool_configuration` API, this is done by setting `tool_configuration.settings.custom_fields` to a JSON object where keys are the param name to be rendered into LTI payloads and values are the $-prefixed custom param names themselves. Include several nonsense entries as well as unsupported entries e.g.: ``` // ... snip ... "tool_configuration": { "settings": { // ... snip ... "custom_fields": { "person_name_full": "$Person.name.full", "person_name_display": "$Person.name.display", "person_name_family": "$Person.name.family", "person_name_given": "$Person.name.given", "canvas_user_isrootaccountadmin": "$Canvas.user.isRootAccountAdmin" "unsupported_param_1": "$unsupported.param.1", "unsupported_param_2": "$unsupported.param.2" } // ... snip ... } // ... snip ... } // ... snip ... ``` - Place this tool into a course, ensure the course has several active members. - Launch the tool in order to observe the course context's LTI identifier. Use that identifier as the value of the NRPS `rlid` parameter, e.g. a GET to: `/api/lti/courses/1/names_and_roles?rlid=4dde05e8ca1973bcca9bffc13e1548820eee93a3` - Each `members` array element in the response should have a `message` array with a single element being the simplified representation of a LTI 1.3 launch payload, were that user to launch the context referenced by `rlid`. - The `message` entry should have two top level claims: - `"https://purl.imsglobal.org/spec/lti/claim/message_type": "LtiResourceLinkRequest"` - `"https://purl.imsglobal.org/spec/lti/claim/custom": <object>` - The `custom` claim should include an entry for each `custom_fields` key/value pair configured above, with supported entries being correctly expanded and nonsense and unsupported entries being echoed as-is. - Repeat for a group context in the same course (still using the course's LTI ID as the `rlid` value). Results should be the same, though scoped to group membership. Change-Id: If2591c62c494756d65774e3115abeca19935c988 Reviewed-on: https://gerrit.instructure.com/169090 Tested-by: Jenkins Product-Review: Karl Lloyd <karl@instructure.com> Reviewed-by: Weston Dransfield <wdransfield@instructure.com> Reviewed-by: Marc Phillips <mphillips@instructure.com> QA-Review: Bill Smith <bsmith@instructure.com>
2018-10-19 07:47:37 +08:00
BLACKLIST_WILDCARD = '*'.freeze # to set up 'deny all' rules
def self.display_template(display_type=nil, display_override:nil)
unless TOOL_DISPLAY_TEMPLATES.key?(display_type)
display_type = 'default'
end
if display_override
if TOOL_DISPLAY_TEMPLATES.include?(display_override)
display_type = display_override
end
end
TOOL_DISPLAY_TEMPLATES[display_type].dup
end
def self.custom_params(raw_post)
form_pairs = URI.decode_www_form(raw_post)
form_pairs.each_with_object({}) do |(k,v), hash|
captures = k.match(/^external_tool\[custom_fields\[(.*)\]\]/).try(:captures)
hash[captures.first] = v if captures.present?
end
end
Render simplified launch params into NRPS v2 responses - Output a smaller version of a LTI 1.3 launch payload for each NRPS v2 member when the NRPS request includes a `rlid` query parameter. - Most claims and custom params from the launch payload are excluded either because: - They describe the context and would thus be redundant, or - They pose performance problems (N+1 queries, usually), or - They are absent from the spec example, e.g. `https://purl.imsglobal.org/spec/lti/claim/version`, or - They require additional development and thus need to be handled as a separate task. - See `memberships_provider.rb` ~line 68 for list of custom params supported in this commit. (More coming later.) - Vast majority of the patch has to do with tests against `JwtMessage`, which was modified to allow claims to be turned on/off via a new white/blacklist mechanism in `AppUtil`. - Custom param white/blacklisting is handled directly in `VariableExpander` to satisfy the LTI rule that unsupported params should just be echoed as-is. This (instead of keeping all the white/blacklist support in `JwtMessage` ensures consistent behavior w/r/t `VariableExpander`'s more sophisticated features, specifically its suport for expanding variables embedded into larger strings. Closes LTIA-40 Test Plan - Configure a LTI 1.3/Advantage tool with the supported set of custom params listed in `memberships_provider.rb` starting ~line 68. If using the POST `/api/lti/accounts/:account_id/developer_keys/tool_configuration` API, this is done by setting `tool_configuration.settings.custom_fields` to a JSON object where keys are the param name to be rendered into LTI payloads and values are the $-prefixed custom param names themselves. Include several nonsense entries as well as unsupported entries e.g.: ``` // ... snip ... "tool_configuration": { "settings": { // ... snip ... "custom_fields": { "person_name_full": "$Person.name.full", "person_name_display": "$Person.name.display", "person_name_family": "$Person.name.family", "person_name_given": "$Person.name.given", "canvas_user_isrootaccountadmin": "$Canvas.user.isRootAccountAdmin" "unsupported_param_1": "$unsupported.param.1", "unsupported_param_2": "$unsupported.param.2" } // ... snip ... } // ... snip ... } // ... snip ... ``` - Place this tool into a course, ensure the course has several active members. - Launch the tool in order to observe the course context's LTI identifier. Use that identifier as the value of the NRPS `rlid` parameter, e.g. a GET to: `/api/lti/courses/1/names_and_roles?rlid=4dde05e8ca1973bcca9bffc13e1548820eee93a3` - Each `members` array element in the response should have a `message` array with a single element being the simplified representation of a LTI 1.3 launch payload, were that user to launch the context referenced by `rlid`. - The `message` entry should have two top level claims: - `"https://purl.imsglobal.org/spec/lti/claim/message_type": "LtiResourceLinkRequest"` - `"https://purl.imsglobal.org/spec/lti/claim/custom": <object>` - The `custom` claim should include an entry for each `custom_fields` key/value pair configured above, with supported entries being correctly expanded and nonsense and unsupported entries being echoed as-is. - Repeat for a group context in the same course (still using the course's LTI ID as the `rlid` value). Results should be the same, though scoped to group membership. Change-Id: If2591c62c494756d65774e3115abeca19935c988 Reviewed-on: https://gerrit.instructure.com/169090 Tested-by: Jenkins Product-Review: Karl Lloyd <karl@instructure.com> Reviewed-by: Weston Dransfield <wdransfield@instructure.com> Reviewed-by: Marc Phillips <mphillips@instructure.com> QA-Review: Bill Smith <bsmith@instructure.com>
2018-10-19 07:47:37 +08:00
def self.allowed?(candidate, whitelist, blacklist)
return true if whitelist.blank? && blacklist.blank?
return false if blacklist.present? && (blacklist.include?(candidate) || blacklist.include?(BLACKLIST_WILDCARD))
whitelist.blank? || whitelist.include?(candidate)
end
end
end