This creates an LTI extension to pass text or urls along
with the score when doing an LTI 1.1 outcome request.
Test Plan:
* use a tool that supports this extension on an assignment
* After doing the tool activity the submission should have the expected value
refs #mebipenny
Change-Id: I296df1e7c7d99af61724a904511f9bf63d5d2613
Reviewed-on: https://gerrit.instructure.com/12878
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@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>
fixes#9954
test plan:
- create a wiki page
- put in links to pages, assignments, discussion topics,
and files, and also to the index pages for these
- retrieve the page via the API, and check that the
data-api-endpoint and data-api-returntype attributes
are set
Change-Id: Ife67f3119aa73971153f88fe46787d7e1563f0ef
Reviewed-on: https://gerrit.instructure.com/12925
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
This adds an alternative method for uploading files by giving Canvas a
public URL in the first step, rather than uploading the file data directly.
test plan:
- create a course file via the API upload mechanism
- make sure the return values are as documented
- make sure the file was correctly uploaded
- create a course file via the URL approach
- make sure the return values are as documented
- make sure the file status endpoint returns valid responses
- make sure the file was correctly stored in Canvas
- repeat that process with a file that has at least one redirect
- repeat that process but creating a homework submission file
- try to create a course file with a malformed URL
- confirm that the appropriate error message is returned
- try to create a course file with a relative URL
- confirm that the appropriate error message is returned
- try to create a course file with a URL that doesn't return 200
- confirm that the appropriate error message is returned
Change-Id: I2dcf711347ec4ef26d767ae1c1fa0bb056986651
Reviewed-on: https://gerrit.instructure.com/12143
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Explaining when to store access tokens locally, and some basic tips on how to
securely do so.
Change-Id: Ie17843b6c657961c1de358b28d5f737ebc9567db
Reviewed-on: https://gerrit.instructure.com/12723
Reviewed-by: Zach Pendleton <zachp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* generate an access token
* use the logout endpoint
* verify that the access token is no longer accepted
Change-Id: Iaac94e35d81711cff87604b6a996c41fdae3c640
Reviewed-on: https://gerrit.instructure.com/12674
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Course/group/users file uploads must be checked
against the context's storage quota before new
files can be added. This commit adds that check
for API uploads. It also adds a note to the API
documentation since this is an additional type of
response developers will need to anticipate.
test plan:
- preflight a file upload in a course that is not over quota
- ensure everything works correctly
- set a small quota for a course
- preflight a file upload in a course that is over quota
- ensure that an appropriate error message is returned
- set a quota of zero for a course
- preflight a file upload for a homework submission
(a case that isn't quota-enforced)
- ensure everything works correctly, even though the
course is at quota
Change-Id: I28cc02d91799b1ff27501c3ff919c54834597d74
Reviewed-on: https://gerrit.instructure.com/12142
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
the current code doesn't work because of the attr_accessible on
DeveloperKey
Change-Id: Id6cf7a3eab5808c05c22c43e6095ab6011ec0f76
Reviewed-on: https://gerrit.instructure.com/12275
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
API documentation and examples for Calendar Events and Appointment Groups.
Clean up some value_as_boolean usage, and fix a couple little issues in
the calendar APIs
test plan:
* build documentation
* it should generate and be correct
* run API specs
* they should pass
Change-Id: I4c57ac91a99e4eb04f5ba1741bb4f5968d0a0b14
Reviewed-on: https://gerrit.instructure.com/12209
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
A complete api for folder and file management
Also updates the alphabetical sorting features to escape
a backslash caused errors when casting a string to a
bytea in postgres
Test Plan:
* CRUD yourself some files
* CRUD yourself some folder
closes#9163
Change-Id: I0b937f9273077b66ab9d6c37171bec1fcc5380dd
Reviewed-on: https://gerrit.instructure.com/12085
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
External Tool extension previously needed their own urls,
custom fields, and text. Now they use the settings from
the main tool config as the defaults. So an extension
only needs a hash to be enabled.
Test Plan:
* Add a tool by xml that has custom parameters and that only has the enabled property in the course_navigation settings
* Launch that tool and verify that it used the main tools launch url and custom parameters
closes#8786
Change-Id: If760bbfe5c1dc10814d2a4b900a53abceab08e2e
Reviewed-on: https://gerrit.instructure.com/11700
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
For example to link to the collection item description:
Each collection contains many {api:collections:Collection+Item Collection Items}.
Change-Id: I633645be9e12481aa21e6c03d876ee159ec6437d
Reviewed-on: https://gerrit.instructure.com/11775
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
adds support for flagging individual endpoints, not just resources, as
beta.
test plan: generate the api docs and verify that the tagged endpoints
have a beta message.
Change-Id: Iba815db309ee71482e1f471eaf613527cd7114ec
Reviewed-on: https://gerrit.instructure.com/11585
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
This standardizes the "user display" sub-object returned by the
discussions api, and returns that same data for each collection item.
test plan: make api calls to return collection items, verify the user
sub-object is present and contains the expected user data.
Change-Id: Ie5b1468816ffbf27a005044effbc49082bdf679b
Reviewed-on: https://gerrit.instructure.com/11276
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Create a discussion topic with support for most of the options -- the
only thing missing is the ability to create an assignment discussion,
that will be added to the assignment create api.
You can also create an assignment linked to the discussion at the same
time you create the discussion. I refactored the assignment api
functionality to support this.
Added a topic delete API as well.
Also fix a bug where we weren't properly validating discussion_type
test plan: hit the api and exercise the various options, such as delayed
posting and require first posting.
Change-Id: I4afdd20313b5cea3ab7b05bf1c005c9f55debe7b
Reviewed-on: https://gerrit.instructure.com/10912
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
This already worked and was used by the Canvas front-end internally, but
wasn't officially supported.
test plan: make an API POST or PUT, and send an application/json body
rather than an application/x-www-form-urlencoded request body.
Change-Id: I2ecf2dce8ed8a592a101b6566c0b483737a68702
Reviewed-on: https://gerrit.instructure.com/10930
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
test plan: generate the api documentation, the collections api should
have a beta warning (but none of the other pages)
Change-Id: I0d7401566cbb3ec9ef76bad79094dad1628ef11c
Reviewed-on: https://gerrit.instructure.com/10720
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
* Allow linking to individual endpoints on the page.
* Give each endpoint a summary string, and list the summaries at the top
of the page, with links to the endpoint details.
* Make an omnibus "all resources reference" page, which has been a
common request. This only includes the endpoint details, not the
summary descriptions of the resources.
* Syntax highlighting for JSON
test plan: visit /doc/api/index.html and see the changes (run rake
doc:api first if on a dev box)
Change-Id: Ib126805825d40770c36b3688668c62938348412d
Reviewed-on: https://gerrit.instructure.com/10516
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
This explicit confirmation step is an improvement on our
login-and-implicitly-accept workflow from before. And it allows us to do
the oauth workflow without forcing a logout, which is much more ideal
especially for embedded LTI tools that want to use oauth.
Eventually this dialog will contain more information on the app and the
permissions requested.
test plan:
As a client application, kick off the oauth workflow for a logged-in
user, verify the user goes straight to the confirmation screen. Verify
you only get a code back if they accept, and an error if they deny. Do
the same without a web session, verify you go to the confirmation screen
straight after logging in.
Change-Id: Idf9905b795979339aec0cb5e4e058f4507a81bac
Reviewed-on: https://gerrit.instructure.com/9804
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
count can be slow if there are a lot. also remove the "last" link
from api responses that skipped the count
test plan:
* go to a user's page with less than 50 page views; they should show
and it should not try to load more
* go to a user's page with hundreds to thousands of page views; they
should load on demand, and when you reach the bottom, it should
stop trying to load more
Change-Id: I934cd7260232b78c33ae5fc1be5e49b2ea686614
Reviewed-on: https://gerrit.instructure.com/10135
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
closes#7775
Allows specifying the folder to upload to as a slash-separated string,
as well.
test plan:
upload to both the current user, and an allowed course, verify the
workflow for s3 and local files. verify you can't upload to course you
don't have permissions to, or another user.
verify that you can specify a folder, and the folder will be created if
it doesn't exist.
Change-Id: Ib9082f047c1c93824fe65decf4789606d82450c6
Reviewed-on: https://gerrit.instructure.com/9603
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
This API abstracts away the difference between S3 uploads and local
storage uploads, while still allowing direct-to-S3 functionality to
avoid typing up Rails processes during S3 uploads.
The only concrete starting endpoint I've implemented in this changeset
is for submission file uploads. Uploads to course and user files is
coming in a subsequent changeset.
test plan:
see the api doc (generate with rake doc:api). repeat this test for both
s3 and local storage configurations.
first, post to the submission file upload endpoint, get your
upload_params back. use that to post the actual file data to the url
returned. then follow the redirect back to canvas, and verify you can
download the file from the url given in the json response. verify you
can attach the new file as part of an assignment submission.
edge cases to test:
* in local files, verify that attempts to modify the policy will fail
the request. in s3, amazon handles this.
* verify that if you do step 2 without step 3, the file isn't available.
* if you do step 1 but wait more than 30 min to do step 3, the upload
will be rejected.
* make sure you can't upload twice in the 2nd step
* make sure you can't verify twice in the 3rd step
Change-Id: I9b16b6e75defe9da551b965d9401f2cad8801f1d
Reviewed-on: https://gerrit.instructure.com/9552
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Change all curl examples to use an oauth access token with the
Authorization header. Also cleanup of the pages discussing authorization
and oauth, and some general sprucing up of the documentation front pages.
test plan: n/a
Change-Id: I64dfe89932c4e98b6ea0f67b3ef09ba10a315444
Reviewed-on: https://gerrit.instructure.com/7764
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
test plan: run the doc:api rake task, verify the docs are still
generated
Change-Id: I9f372a8e68de1019619b452c14f1ebbb1895cecf
Reviewed-on: https://gerrit.instructure.com/7745
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
Cinches up the padding on the left nav a little bit and
adds a new section on LTI and our extensions to LTI.
test plan:
- run rake doc:api
- check out the new api
- make sure all links work
- make sure documentation makes sense
- make sure it links to IMS pages in the right places
Change-Id: I99de960b9e0262d7bda89515b9a7be10dd981ce7
Reviewed-on: https://gerrit.instructure.com/7528
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
as outlined in the oauth2 bearer token documentation:
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-08
test plan: make any api requests passing the access_token in the
authorization header, rather than the query string, and verify you can
successfully make those calls. also verify that the query string method
still works as before.
note that we are not yet responding with a proper 401 and
www-authenticate header, as described in the oauth2 bearer token spec.
that is coming in a subsequent commit, after some refactoring of our api
error response mechanisms.
Change-Id: I2cf470ce2dd33442bb71ea2d3c756410b418b1ca
Reviewed-on: https://gerrit.instructure.com/7664
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
this isn't supported, just an error in the docs
test plan: n/a
Change-Id: I957c6b030b269a93204f66416d65dd7ab9c65dee
Reviewed-on: https://gerrit.instructure.com/7520
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
except we don't even use jquery in the api docs
testplan: n/a
Change-Id: I6d4be9e25ca68e64f62414a1e81ac40549a5b99f
Reviewed-on: https://gerrit.instructure.com/6617
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Finding users is a bit different, since the user's sis information is
actually stored on the pseudonym. Before, we were working around this in
the submissions api. I've generalized it to work everywhere that uses
the Api find functionality, and in the process fixed the page views api
so that it works with sis ids.
This is necessary as we add more user apis, like the upcoming
/users/:user_id profile API.
Also added the /users/self shortcut to query the various user apis for
the user accessing the api.
Also for consistency, deprecate users/activity_stream in favor of
users/self/activity_stream
Change-Id: Icb0776231070b838bb341893d12b1061b90c5d04
Reviewed-on: https://gerrit.instructure.com/5628
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Hudson <hudson@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>
periods were being interpreted as the beginning of a file extension,
rather than part of the sis id. fixing this meant completely changing
our routing, unfortunately, since rails resourceful routing is very
oriented on numeric ids, with format extensions.
the .json extension is now optional for api requests, in api v2 we'll
drop it completely. there is the unfortunate edge case that a sis id
ending in ".json" can't be send through the v1 api -- except...
we also now support hex encoding sis ids in the api calls. this allows
arbitrary strings to be used. in theory this could just use uri
encoding, which is also "supported", but there are bugs in various
releases of apache and the rack/rails stack that make this impossible to
use with some characters, such as "." and "/".
the api documentation has been updated as well
Change-Id: Ifa4b529dffee0f30ef5384f94c64aa6e8f8f2542
Reviewed-on: https://gerrit.instructure.com/4940
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Once rake doc:api or canvas:compile_assets is run, the API will be
accessible from within Canvas at /doc/api/index.html
Change-Id: I503701c0ef3dc0df0ea67477053b328411553352
Reviewed-on: https://gerrit.instructure.com/4723
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
users have both a SIS user_id and login_id, return both in the API and
allow both as ids when specifying a user in API calls using the syntax
sis_user_id:someid and sis_login_id:someid
These columns in the db aren't well named, unfortunately, but we'll try
to at least be consistent in the API.
This is technically a breaking change for the API. We've decided to go
ahead with it, as this API functionality was only recently added.
Change-Id: I8eabe4226580aa3b1aec7e5b7082b045f786e605
Reviewed-on: https://gerrit.instructure.com/4556
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@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>
Bracken Mosbacker