Site admins can manage developer keys. This provides a
basic interface for allowing key management. Admins can
add new keys, edit existing keys, etc. Also adds an
icon url for each key. If keys have an icon url, then
the oauth screen will display this icon to end-users.
test plan:
- manually add a key from the "developer keys" page in
the site admin account
- confirm that the key is created correctly
- edit the key
- confirm that the changes persist
- delete the key
- confirm that the key is properly deleted
- create more than 15 developer keys
- confirm that the page properly paginates
- set an icon url for a key
- do the oauth dance
- confirm that the icon appears in the approval step
- do the oauth dance for a key without an icon url
- confirm that no icon appears in the approval step
Change-Id: I5d64d14974fdcef8be21c6aa84ab13f681217bd7
Reviewed-on: https://gerrit.instructure.com/10979
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
tool_id can be used to associate multiple context_external_tools
with a single third party tool (i.e. to see how many installs
there are of the youtube tool). When tools are launched Canvas
will also track a custom ganalytics event with this tool id.
icon_url is an attribute that can be set in standard LTI
config that we were ignoring before. In the future this may
be added to the UI when picking external tools.
test plan:
- find an external tool with tool_id and icon configs
(there are some examples on lti-examples.heroku.com)
- configure an external tool using this xml
- confirm that tool_id and icon_url were correctly set
(tool.tool_id and tool.settings[:icon_url])
- launch an external tool from within a course
- make sure that nothing breaks
Change-Id: If8d6386e8a919fa70eacd46b4fa6b68ade4b5c7b
Reviewed-on: https://gerrit.instructure.com/10568
Reviewed-by: Brian Whitmer <brian@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
also search for the default developer key on the default shard
refs #7788
test plan:
* create an api key (on the default shard)
* access the api on a non-default shard
* it should still work
* create an oauth token in the UI on a different
shard
* it should work, and reference a key on the default shard
Change-Id: I8c8aa36ab38f45ba9af2422a42552faeff28ac73
Reviewed-on: https://gerrit.instructure.com/9492
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
accepts a redirect_uri to return the code to, in addition to the OOB uri
support. matches the redirect_uri domain host against the one stored on
the developer key.
this doesn't yet include a UI for registering developer keys.
Change-Id: I6fbfe6ff3dbd6ebea9c2f9fc5ce3e45447a1cbc8
Reviewed-on: https://gerrit.instructure.com/4963
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Added support for oauth 2 API requests. HTTP Basic
only works for Canvas-auth and LDAP accounts, but
oauth 2 will also work with SSO accounts. Also added
ability for users to create access tokens from the
profile page.
Change-Id: I13581b4e77bfa77bf11dbb732900012dd1e50ede
Reviewed-on: https://gerrit.instructure.com/3775
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Brian Whitmer