fixes CNVS-13010
test plan
- request an oauth token
- it should not be valid after 10 min by default
- it should allow changing the value as a setting
Change-Id: I2fd0457ab8a2e0e16729ce6b5fc854e1f834640b
Reviewed-on: https://gerrit.instructure.com/35713
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
fixes CAT-66
Auto-authorize trusted developer keys during without prompting the end-
user. This will allow for more seamless integrations with other in-house
apps.
Also fix remember-me access so it works when you re-auth into canvas
(previously it only worked if you were already authenticated into
canvas)
Expand test coverage around oauth login scenarios
test plan setup:
* set up a web-based oauth integration with canvas
* ensure your app doesn't currently pass force_login=1 during oauth
* ensure your app doesn't currently delete access tokens during logout
* for part 2, ensure your app uses the /auth/userinfo scope (for part
1 it doesn't matter)
* for part 3, ensure your app does token request flow (not userinfo)
test plan part 1 (trusted keys):
1. in the canvas console, set trusted=true on the app's developer key
2. do an oauth login as and end-user
3. confirm that you are authenticated into the app without being prompted
to give it canvas access
4. log out of the app (but not canvas)
5. click to log in again
6. confirm that you are automagically logged in without any prompts
test plan part 2 (remember access):
1. in the canvas console, set trusted=false on the app's developer key (or
set up your app to use a different one)
2. do an oauth login as and end-user
3. confirm that you are prompted to authorize the app
4. check the box to remember access
5. log out of canvas and the app
6. do an oauth login again
7. confirm you are not prompted to authorize the app
8. log out of the app (but not canvas)
9. click to log in again
10. confirm that you are automagically logged in without any prompts
test plan part 3 (untrusted key, not-userinfo)
1. in the canvas console, set trusted=false on the app's developer key (or
set up your app to use a different one)
2. do an oauth login as and end-user
3. confirm that you are prompted to authorize the app
4. confirm there is no box to remember access
5. log out of canvas and the app
6. do an oauth login again
7. confirm you are prompted to authorize the app again
8. log out of the app (but not canvas)
9. click to log in again
10. confirm that are prompted to authorize the app again
Change-Id: Ifb2eb29e4da163b595cb070455ebae21a4618ba4
Reviewed-on: https://gerrit.instructure.com/32926
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
fixes CNVS-10966
test plan:
1. create a user
2. add the user to another shard
3. log in to that shard (domain) via oauth (using an app that uses canvas
for identity, i.e. scopes=/auth/userinfo)
4. check the "Remember my authorization" box
5. log out
6. log in again
7. you should not get prompted to reauthorize the app
Change-Id: I6045bbbf69dab46010232d96e09cf284918f14b4
Reviewed-on: https://gerrit.instructure.com/29625
Reviewed-by: Dan Dorman <ddorman@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
refs CNVS-5794
test plan:
* go through the oauth flow, adding purpose=something to the first
step
* at the end, when you view the access token in your user profile,
it should show the purpose you put in
Change-Id: I3f7f55df5540931ef5844c7f265dc720af153372
Reviewed-on: https://gerrit.instructure.com/26249
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
refs CNVS-7597
given Object#to_json's default implementation, the old to_json
overrides follow from the new as_json overrides. and now we can also
call as_json and get the expected non-serialized data.
test-plan: N/A
Change-Id: Ia57562e0c73752a13023cad4ef6bae9435790bee
Reviewed-on: https://gerrit.instructure.com/23647
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
ActiveSupport::SecureRandom was merged into the ruby stdlib. In rails
3.0 it is just an alias to ::SecureRandom, and is removed completely in
rails 3.1.
This stdlib exists in ruby 1.8.7+
Change-Id: I096b212c020fd60e3799a9d1635129944ac3b6e4
Reviewed-on: https://gerrit.instructure.com/19080
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
Product-Review: Brian Palmer <brianp@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>
this fixes an issue that allows 3rd parties to request multiple oauth
tokens with the same code until the code exiles on its own in redis
test plan:
* follow the oauth token flow
- request canvas access
- exchange the code for the final access token
* you should get an access token
- repeat the previous request to exchange the code for the access token
* you should get an 'invalid code' message
Change-Id: I7724988c16ac307be7dd4b762a07e936c3ad38bd
Reviewed-on: https://gerrit.instructure.com/18592
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>
refs #CNVS-523
This will now pass the canvas_login parameter
on through the oauth workflow.
there are also several small refactors to pull
the oauth workflow out of the pseudonyms
controller and into a couple lib objects
TEST PLAN:
1) As a site admin, attempt to use the OAuth
through a domain that uses delegated authentication
2) add the "canvas_login=1" url parameter to your
oauth url
3) you should be taken to the regular canvas login
screen instead of the CAS url.
Change-Id: I8b68e5b1c6914b6109af6aabcbba03ed15c4f9cf
Reviewed-on: https://gerrit.instructure.com/16240
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Ethan Vizitei <ethan@12spokes.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Cody Cutrer