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>
I removed the api_routes plugin, since the code is currently too tied to
canvas to be pulled out into a generic plugin anyway. The yardoc
templates now live in doc/templates, and I've done some major cleanup
and refactoring -- they don't have much in common with the default YARD
templates anymore, and they work much better as API documentation.
The styling is now a little bit more "canvas-like" now, too.
Change-Id: I80edd02e63d7815a292306741f2e8ea52872aae2
Reviewed-on: https://gerrit.instructure.com/2535
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>