refs CNVS-13987
what was called CanvasUuid was *not* generating UUIDs. it was generating
slugs. by default, its generate method only creates 4 character slugs.
these should obviously not be used as UUIDs. the misnomer already caused
a bug in EventStream where it used these slugs as UUIDs, causing
collisions. to fix:
(1) rename canvas_uuid gem to canvas_slug, and rename it's primary
class CanvasUuid to CanvasSlug
(2) create new canvas_uuid gem, with class CanvasUUID, extracted from
lib/uuid_singleton for actual UUID generation
(3) fix event stream use CanvasUUID, rather than following the rename
of CanvasUuid to CanvasSlug
test-plan:
- have cassandra set up for audit logs
- create an audit log entry (e.g. change a grade)
- look at the generated audit log entry's id field; it should be a UUID
value, not a 4 character slug
Change-Id: I19758fff4433cd6cb2e21219217dced19ee05c5a
Reviewed-on: https://gerrit.instructure.com/37506
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
refs CNVS-13024
Setting wasn't properly being initialized as unsharded because
it was loading before Switchman. The reason we need Setting before
switchman is just for yaml loading, so split that into its own
class.
Change-Id: I5456e103cb216dba2d5af4e9c20a697b468c923b
Reviewed-on: https://gerrit.instructure.com/35043
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Change-Id: Ic226e61e900532cc3acf08444b316b6e2bb6b368
Reviewed-on: https://gerrit.instructure.com/30049
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
fixes CNVS-9331
instead, as appropriate, use one of (or a combination of, if necessary):
* instance variable caching
* Rails.cache
* query caching (implicit)
also:
* remove the buggy cc.active_pseudonyms (didn't account for
sharding) in favor of cc.user.all_active_pseudonyms
* streamline assignments in the menu to not need to construct method
names
test-plan: N/A
Change-Id: Id0dec60464a283985e39493b90711b32cb5cca82
Reviewed-on: https://gerrit.instructure.com/26936
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
fixes CNVS-5794
links to an access token to get the proper ARN
test plan:
* set up an SNS app in AWS
* configure your credentials in sns.yml
* set sns_arn on a developer key to be the ARN of the app in SNS
* using an access token created from that developer key,
you should be able to create a push channel
* you should see that channel in your profile (named after your developer
key)
Change-Id: I183241d02715252bf558c495d72d4995cea4232d
Reviewed-on: https://gerrit.instructure.com/25281
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
adds scopes to access token and a new scope, 'userinfo'. when this scope is
used, a user may choose to remember authorization for a 3rd party. when this
option is selected, subsequent requests for an access token scoped to userinfo
will skip the the step where the user authorizes the app and will return userinfo
but no access token.
test plan:
* follow the oauth token flow adding a param for scopes=%2Fauth%2Fuserinfo to the initial request
- check the box for to remember authorization
- click login
* repeat the above request
* you should not see the request access page
* delete the tokens that were generated above
* run the test above, this time not remembering access
* you should see the request access page on the second request
Change-Id: I303a55d3c71de517ce6aa5fd8acd74d89aa4c974
Reviewed-on: https://gerrit.instructure.com/17604
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
fixes #CNVS-1886
SQL statements were noted that would fail
when a string was passed to a DeveloperKey
query when trying to match against the id column.
With grep I was only able to find 2 likely vectors,
one of which (developer key special keys) I
wrote a spec to confirm it wasn't an issue,
the other (canvas/oauth/provider) I wrote a spec
that uncovered it could be exploited in the
way described in the ticket, so I've closed
that possibility by including client_id validation
which confirms both that the client_id exists
and that it either is an integer or is
cast-able to an integer.
TEST PLAN:
No behavior has changed, this just closes
a vulnerability to bad data.
1) Try to login to canvas using a valid OAuth
login process, just to confirm there is no
regression.
2) Now, login through an OAuth pathway but make
sure the client ID is something nonsensical like
'XXXXX' or some other non-numeric string.
3) instead of causing a database error, you
should get a 400 and the JSON should have a
message: "invalid client_id"
Change-Id: Ic32a0a4498400eccc75c6d248e888439e61257d6
Reviewed-on: https://gerrit.instructure.com/17050
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
fixes#9995
also validates_as_url the redirect_uri, sometimes people were leaving
off the http:// part when setting up the key
test plan: set up a developer key with a given domain. kick off an oauth
request flow with redirect_uri equal to that domain, it should be
accepted. use a sub-domain of that domain, it should also be accepted.
use a higher-level domain, it should not be accepted.
Change-Id: I55510f463b1faa3339b9908f9941715d93de5a16
Reviewed-on: https://gerrit.instructure.com/12980
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
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>
Jacob Fugal