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>
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>
Jacob Fugal