fixes PLAT-3176
fixes PLAT-3179
fixes PLAT-3181
fixes PLAT-3177
Test plan:
* Create a DeveloperKey
* Create an AccessToken
* Ensure that everything can be accessed as normal
* Set require_scopes to true on the DeveloperKey
* Ensure that nothing can be accessed
* Add some scopes to the AccessToken from the list of available scopes
TokenScopes::SCOPES
* Ensure that the endpoints associated with those requests work but that
others don't
* Ensure that HEAD requests work for GET endpoints
* Ensure all api endpoints behave normally when scopes are not turned on
for developer key
Change-Id: I0e7c1758ae2d51743490f243cfa21714255c8109
Reviewed-on: https://gerrit.instructure.com/143026
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Reviewed-by: Nathan Mills <nathanm@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Karl Lloyd <karl@instructure.com>
fixes PLAT-3018
test plan:
- create a developer key at a sub account
- use it to get an access token for a user
- use the access token to access resources in the sub account, i.e
a course via the api
+ it should allow you to get access resources in the sub account
- use it to access a user via the api
+ it shouldn't allow you to access a user
- use it to access a resource in a different sub account
+ it shouldn't allow you to access resources in other sub accounts
Change-Id: Ie6e18399770e2dd3590be2c8407cdd5c3a230e69
Reviewed-on: https://gerrit.instructure.com/139268
Tested-by: Jenkins
Reviewed-by: Andrew Butterfield <abutterfield@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Nathan Mills <nathanm@instructure.com>
just pretend it's empty. the caller should be responsible for dealing
with missing consul data as appropriate
Change-Id: I2c37d33481b55776b14c6c17e109005a75dd600b
Reviewed-on: https://gerrit.instructure.com/125567
Reviewed-by: Tyler Pickett <tpickett@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
closes CNVS-35834
* allow specifying tree, service, and cluster for consul stuff
* check multiple consul keys for each setting (cluster, env, region, global)
test plan:
* an existing consul environment still works
Change-Id: I48e8fadeac2e140973bfc4b41c1cfb386532d15c
Reviewed-on: https://gerrit.instructure.com/125271
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Tucker McKnight <tmcknight@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Change-Id: Ic6e4f64874021639f5e8950e2fe42f714ae31250
Reviewed-on: https://gerrit.instructure.com/120225
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
fixes CNVS-37391
test plan:
* generate an access token
* hit /login/session_token with your access token
* in an incognito window, paste the returned URL in (quickly)
* you should be logged in
Change-Id: Ic12f98156f070e9932d0ff3e12c07b2de9e02db5
Reviewed-on: https://gerrit.instructure.com/115271
Tested-by: Jenkins
Reviewed-by: Tyler Pickett <tpickett@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-35919
also, prefer SIS pseudonyms over non-SIS pseudonyms from any given
account
test plan:
* have a non-SIS pseudonym and a SIS pseudonym on a user
* do an LTI launch
* the LTI tool should get the info from the SIS pseudonym
Change-Id: I60a3c48a32eae94db93b0e72f1f0f6c5b6a5f5c2
Reviewed-on: https://gerrit.instructure.com/107785
Reviewed-by: Nathan Mills <nathanm@instructure.com>
Reviewed-by: Tyler Pickett <tpickett@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Tested-by: Jenkins
Product-Review: Cody Cutrer <cody@instructure.com>
Also, make Consul container accessible from the host.
Fixes: CNVS-35831
Refs: CNVS-34341, CNVS-32864
Test Plan:
- Smoke test RCS and Canvas running together to make sure they still
play nice.
Change-Id: I418d54a176677b1df8ec42a009752807908a847c
Reviewed-on: https://gerrit.instructure.com/99443
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Tucker McKnight <tmcknight@instructure.com>
Product-Review: Tyler Pickett <tpickett@instructure.com>
refs #CNVS-32574
Change-Id: I4e255b989f8ad3fc6ec2f2699d4950dc0e5a419a
Reviewed-on: https://gerrit.instructure.com/99483
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
fixes CNVS-28330
TEST PLAN:
1) generate a JWT with the "for_user" method
2) if a masquerading user is provided, it should be included in the
body
3) eventually, using a wrapping service should be able to preserve
audit trail across an external api call with JWT
Change-Id: Ic10bcc4ac2e8b4222005d765cec2df3dd4740f64
Reviewed-on: https://gerrit.instructure.com/75741
Tested-by: Jenkins
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
closes CNVS-27672
This could stop all API requests from working
if consul suddenly catastrophically loses it's data.
With the patch in place, we'll still fail for
requests that need that data to decrypt (JWT), but regular
access tokens will still work ok. This is better than
total system failure.
TEST PLAN:
1) connect to consul, but put no data in it (particularly no
signing/encryption secrets)
2) hit canvas with an API request using a regular access token
3) it should not blow up
Change-Id: Ia435814929968373f22ab8d120153368267a3f32
Reviewed-on: https://gerrit.instructure.com/73492
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
closes CNVS-26734
distributing env vars through production is harder
than updating a shared highly available store. We put this stuff
in consul now so it's easy to update everywhere at once.
also clean up webmock spec usage, it causes a lot of errors
because it's configuration seeps outside the specs it's currently used
in
TEST PLAN:
1) no production changes (does not touch app code)
2) clean install, clean config directory
3) copy docker-compose/config/ files to your config directory
4) you shouldn't be missing any config files when you start your
compose file up
5) Canvas::DynamicSettings.find("canvas") should give you a hash
with your secrets from the init values in your config file
6) ServicesJwt.signing_secret and ServicesJwt.encryption secret
should pull those same values
7) if you have env vars for ECOSYSTEM_KEY or ECOSYSTEM_SECRET, they
should be ignored
Change-Id: I3b3c1b19d6e2a05af3e6caa2e0af6c5d1dc6df66
Reviewed-on: https://gerrit.instructure.com/71559
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
closes CNVS-26405
Some access tokens were generated which, when base64 decoded, happened
to have the right number of dot-delimited segments to look like a JWT,
and then the decoding library would choke parsing what it thought
was a JSON segment. This catches that parse error, and lets
access_token processing continue.
TEST PLAN:
1) create an access token for your user, and then overwrite it's token
value to be the same token as is in the specs accompanying this
patch set
2) you should be able to use the APi with that token ok
Change-Id: I7d6ee4e2d40f1fef08bd223e90fdd8dca3bb5779
Reviewed-on: https://gerrit.instructure.com/70160
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
closes CNVS-18870
CNVS-18870 as described in the ticket description is not a bug. see
comments on the ticket for more details. but while investigating and
confirming that, it became obvious that the odd structure and scattered
implementation of the CSRF protection was both making it hard to reason
about and easy to introduce new bugs. after the refactor, we still:
* don't perform CSRF validation on GET requests
* don't perform it on token-authenticated API requests
* do perform it on session-authenticated API requests
* do perform it on non-API requests regardless of authentication method
additionally, we now:
* don't perform CSRF validation on HEAD requests
finally, we _don't_ support a csrf_token in the session anymore. that's
been deprecated forever; we can remove the code now.
test-plan:
- should not perform CSRF validation for:
- GET requests
- token-authenticated POST requests to API endpoints (path prefixed
by /api/) without an authenticity_token parameter or X-CSRF-Token
header
- token-authenticated POST requests to API endpoints even with an
authenticity_token parameter
- token-authenticated POST requests to API endpoints even with an
X-CSRF-Token header
- should perform CSRF validation for:
- POST requests to non-API endpoints
- session-authenticated POST requests to API endpoints
- when CSRF validation should occur, but the user has cookies off:
- POST requests to non-API endpoints should redirect to a "need
cookies" page
- XHR POST requests to non-API endpoints should not redirect
- POST requests to API endpoints should not redirect
Change-Id: I3dbb3a68623bc9d03a3e744a9d4e1f038a32709c
Reviewed-on: https://gerrit.instructure.com/65103
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
closes CNVS-24286
Add JWT (wrapped and signed by shared secret)
as a viable authentication method.
Also remove deprecation errors from login template
TEST PLAN:
1) have ECOSYSTEM_* env vars set (docker helps)
2) login as a user
3) take a token from "/jwts/generate"
4) wrap that token in another token signed
with the shared secret (ECOSYSTEM_SECRET,
see services_jwt_spec.rb for a way to do this)
5) use the base64 encoded string as a bearer
token for canvas
6) try it again in 70 minutes or so (the same
token), it should now be expired.
Change-Id: I721f42d7c9ca7edc82bc75b116354dd3edc50a88
Reviewed-on: https://gerrit.instructure.com/66110
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
fixes CNVS-23333 (again)
test plan:
* configure SAML auth on an acocunt
* set up a link to say http://canvas.dev/, http://canvas.dev/login,
http://canvas.dev/login/saml in a Word document
* be not logged in to canvas yet in your browser
* click the link
* it should properly work sending you to the login page
Change-Id: Ic219220ede9a6e398fe361addf5089f5431d23cc
Reviewed-on: https://gerrit.instructure.com/66478
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
we'll need to check the access token to make sure its allowed to access
the requested account.
This will make it so tokens can not be used for any account other than
the account/sub_accounts tied to the dev key to the dev key
Fixes PLAT-1201
Test Plan:
Create a couple of accounts
give some of them sub accounts
create dev tokens for the accounts (use console)
authorize keys with users
make sure the access tokens are scoped correctly
postman stand alone app was very helpful in testing
Change-Id: Ied854160ea27a1656c0b275c281e14d9de5faa74
Reviewed-on: https://gerrit.instructure.com/60842
Tested-by: Jenkins
Reviewed-by: Brad Humphrey <brad@instructure.com>
Product-Review: Brad Horrocks <bhorrocks@instructure.com>
QA-Review: August Thornton <august@instructure.com>
test plan:
* use an access token to do an API request
* the X-Canvas-Meta header should have a dk key, with a global id
Change-Id: I85139bffb16750a4bfffb241eaaf54de4d9601ae
Reviewed-on: https://gerrit.instructure.com/60597
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
test plan:
* using "mailto:example@example.com," in a link should
not break course copies (or anything else) because it
doesn't know how to rescue a URI::InvalidComponentError
closes #CNVS-22120
Change-Id: Iaac362a5bf33cd5fde05b01a578a1325f4126c6e
Reviewed-on: https://gerrit.instructure.com/59213
Tested-by: Jenkins
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
authentication
Fixes PFS-1084
Parent Registration:
When a Saml config is designated for Parent Registration the parent
signing up will be redirected to a Saml login page where they will log
in with their child's credentials. After login the child user's
Saml session will be ended and the parent registration process will complete.
Parent Adding Student:
When a Saml config is designated for Parent Registration the parent
adding another observee will be redirected to a Saml login page
where they will log in with their child's credentials. After login the child user's
Saml session will be ended and the observee creation process
will complete.
---------------------------------------
TEST PLAN:
SETUP:
1) In your account settings check the box for 'Self Registration' (and
either of the sub-options)
2) Add the following users to your account (these will be the students):
billyjoel
eltonjohn
3) In Authentication Settings add a SAML authentication service
and enter the following fields (I've set up a remote SAML Idp):
IdP Entity ID: http://107.170.212.143/saml2/idp/metadata.php
Log On URL: http://107.170.212.143/simplesaml/saml2/idp/SSOService.php
Log Out URL:
http://107.170.212.143/simplesaml/saml2/idp/SingleLogoutService.php
Certificate Fingerprint:
9C:11:68:93:95:CD:18:01:EC:52:2B:9E:22:7F:73:55:ED:6D:82:D4
Parent Registration: check
TEST:
Parent Registration:
* Go to '/login/canvas'
* Click on the signup banner
* sign up as a parent for billyjoel or eltonjohn
(on SAML login page the password for either user is: tantrum)
Add Student:
* Log in as a parent user w/ a Canvas Auth login
* Go to '/profile/observees'
* Add Student 'billyjoel' or 'eltonjohn'
Authentication Settings (new parent reg checkbox):
* Go to Authentication Settings
* Add a second SAML config
* check the parent registration checkbox
- it should warn that selection will deselect the other
and in fact do so upon save.
- the selected config is the one used for
parent reg/add student
---------------------------------------
Change-Id: Ief83b604fc252c88dbb912c56de65d8620fe802f
Reviewed-on: https://gerrit.instructure.com/49691
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
fixes CNVS-20394
split it into appropriate concerns. main points are:
* /login never renders a login form - it redirects forward to the
default auth controller based on the first account
authorization config (or discovery url on the account)
* /login/canvas is the new home of the old login form. this form is
never rendered in-situ anymore - other places that used to render
it now redirect to /login (and then forward to here), reducing
their knowledge of SSO
* /login/ldap ends up at the same place (cause LDAP auth is handled
transparently)
* /login/cas and /login/saml redirect forward to the first SSO
configuration of the appropriate type. /login/:auth_type/:id can
be used to select a specific one
* if an SSO fails, it redirects back to /login with flash[:error]
set. this can forward to the discovery url appropriately, or
render an error page appropriately (the old no_auto=1, but now
it's not layered on top of the login partial that didn't show a
login form)
* ?canvas_login=1 is deprecated. just go directly to /login/canvas
* /saml_consume, /saml_logout are deprecated. they are processed
directly by /login/saml and /login/saml/logout
* /login/:id is deprecated - it forwards to /login/:auth_type/:id
as appropriate (presumably only saml, since that was the only
one that previously should have been using these links)
* OTP has been split into its own controller, and separated into
multiple actions instead of one all-in-one action
* /logout has been vastly simplified. the login controller should
set session[:login_aac], and on logout it will check with that
AAC for a url to redirect to after logout, instead of /login.
SSO logout is handled by each controller if they support it
test plan:
* regression test the following functionality -
* login with canvas auth
* login with LDAP auth
* login with SAML auth - and multiple SAMLs
* login with CAS auth
* MFA (configure, using, auto-setup)
* Canvas as OAuth Provider flow
* redirects to the login page when you're not
logged in
* failure of SAML/CAS (i.e. can't find user)
show a decent error page and allows retry
* "sticky" site admin auth (site admin is CAS/SAML,
going directly to another domain logs you in with
site admin)
Change-Id: I1bb9d81a101939f812cbd5020e20749e883fdc0f
Reviewed-on: https://gerrit.instructure.com/53220
QA-Review: August Thornton <august@instructure.com>
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes gh-587
test plan:
* configure CAS, local file storage, and *don't* have a separate domain
for files
* masqeurade as a user
* you should be able to upload a file (for example, to a course)
Change-Id: Ieb427e838265c5fc53204eaa41df8917445f75c3
Reviewed-on: https://gerrit.instructure.com/49014
QA-Review: Cody Cutrer <cody@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins
Product-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-16884
test-plan:
- in HTTP-session environment (`secure: false` or unset in
config/session_store.yml), CSRF cookie should be sent without secure
flag
- in HTTPS-session environment (`secure: true` in
config/session_store.yml), CSRF cookie should be sent with secure
flag.
- on a non-files host, javascript should be able to read the CSRF
cookie: value of "document.cookie" in javascript console should
include "_csrf_token"
- on a files host, javascript should not be able to read the CSRF
cookie: value of "document.cookie" in javascript console should not
include "_csrf_token"
Change-Id: Ifd57c973478a6d07497a404dcf1a9b9caa9014af
Reviewed-on: https://gerrit.instructure.com/44451
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes: CNVS-16746
ruby-saml-mod gem v0.2.1 reverts the auth_request back to its state
before v0.2.0. In v0.2.0 it started to sign the auth_requests but never
included the Destination attribute in the xml which is required if an
auth_request is signed.
Test Plan:
- Setup a SAML environment with Canvas.
- Log in while observing the requests in a browser console.
- Make sure the auth request is not signed.
Change-Id: Id89aff70d5a77db94f7c2ae58f87727801386bc3
Reviewed-on: https://gerrit.instructure.com/44021
Reviewed-by: Paul Hinze <paulh@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Matt Fairbourn <mfairbourn@instructure.com>
fixes: CNVS-16363
Adds a method to saml_logout which allows Canvas to accept an IDP
initiated SAML logout redirect.
Test Plan:
Setup:
- SAML server with IDP initiated logouts.
- SAML account in Canvas using the SAML server.
* It would be good to test with multiple SAML providers including:
https://www.feide.no/sites/feide.no/files/documents/Feide_integration_guide.pdf
Tests:
- Log in as a user within the SAML account.
- Logout the user from the SAML Server.
- The user should be logged out of Canvas and redirected back with
a SAMLResponse in the query string.
Change-Id: I381189cee6759b178fccec4bef9be31b4a81448d
Reviewed-on: https://gerrit.instructure.com/43227
Reviewed-by: Paul Hinze <paulh@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Nick Cloward <ncloward@instructure.com>
fixes: CNVS-15843
Changes how we associate a CAS ticket with the Canvas session. When we
recieve a logout request from the CAS server we mark the ticket as
expired and each time the user performes a request we check their
session cas ticket to the ticket we stored to see if its expired or not.
Test Plan:
- Setup CAS Server
- Log in to Canvas with a user
- Log in to Canvas with the same user in a different browser.
- Have the CAS server send a SLO request for one of the tickets.
- First session should be logged out on the next request.
- Second session should not be logged out.
For additional details see:
https://github.com/instructure/canvas-lms/pull/516#issuecomment-57340629
Change-Id: I189f70e58db6444b1747a686a6a50f46c53f3697
Reviewed-on: https://gerrit.instructure.com/42312
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
test plan:
* in one tab, start to fill out an ajax form
(e.g. editing a quiz)
* in another tab, log out of canvas
* return to the original tab and try to
submit the form (e.g. save your changes)
* should get an error message with a link to
login in a new tab
* login in the new tab
* return to the original, and try to resubmit
* should save successfully
closes #CNVS-3957 #CNVS-13673
Change-Id: I7758514de8ce09361fef469034645d8a29e2a5e5
Reviewed-on: https://gerrit.instructure.com/40396
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Cosme Salazar <cosme@instructure.com>
refs CNVS-14595
instead of waiting for an InvalidAuthenticityToken to catch it
test plan:
* log in to one browser, and go to an assignment page
* in another browser (or incognito) log in and log out as the same user
* in browser 1, refresh. you should have to login again
* watch your requests - pings should be happen periodically, and
succeeding
* log in/out in browser 2
* back in browser 1, a ping should fail. check your logs or
errorreports - it should be a LoggedOutError, and InvalidAccessToken
* refresh and log back in
* log in/out in browser 2
* try to edit a rubric (or another AJAX request that's not API) -
it should fail, again *not* with InvalidAccessToken
Change-Id: I04c72e12fbcee7dd0aa4ce7dafcb698167a82015
Reviewed-on: https://gerrit.instructure.com/38755
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes: CNVS-13703
Adds a configuration to the rubycas-client gem to parse extra attributes
as a raw version since it defaults to parsing as yaml.
Test Plan:
- In a CAS response add some additional data that cannot be parsed as
yaml.
- Without this fix it should throw an error that the extra attributes
cannot be parsed as yaml.
Error: Failed to validate CAS ticket: #<ArgumentError: Error parsing extra
attribute with value...
Change-Id: I464c296fcf129bc882420f5f4f3913ac37585b02
Reviewed-on: https://gerrit.instructure.com/37191
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Nick Cloward <ncloward@instructure.com>
fixes CNVS-10415
test plan:
* configure site admin with its own domain, and to use CAS auth
* log in at site admin
* go to another account with the same base domain (i.e.
siteadmin.canvas.dev and accounta.canvas.dev)
* it should redirect you to site admin's CAS server; and likely
directly log you in to canvas, cause you're still logged in
there
* go directly to a course on a different account without being
logged in; it should send you to site admin cas
* log out on the site admin domain and the other domain
* go to the other domain to log in; it should no longer redirect
you to site admin cas
Change-Id: I72d5327193832264228305f73e849282c48780d3
Reviewed-on: https://gerrit.instructure.com/34425
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-7297
test plan:
* set your clock in the future
* log in then log out
* fix your clock
* log in - it should not kick you out
Change-Id: Ie6b9749b921dd8c20f6b1e6be6b5abee977d52b4
Reviewed-on: https://gerrit.instructure.com/34489
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
refs CNVS-6040
This gem will help us output json error responses in the API using error
codes, since by itself ActiveRecord::Errors just deals in human-readable
i18n'd strings, and doesn't store detailed machine-readable information
on the error.
BetterErrors is mostly compatible, there's a few differences that mean I
had to change some unrelated code:
* errors[field_name] always returns an array, even if there's only one
error on the field. This is an improvement IMO.
* errors is indexed by symbol, not by string
* iterating over the errors object now yields
|attr, error_object| rather than |attr, string_message|
This includes a backport of the gem to rails 2.3.
On rails 3, we just use the vanilla gem.
The error codes aren't yet documented in the API docs, support for doing
that will come in a subsequent commit.
test plan: specs, plus you can hit the one api endpoint i've converted
so far -- account authorization configs. try to create an invalid
config, such as adding both cas and ldap configs to the same account,
and verify the error response formatting
Change-Id: Iaadd843ca9ff3f52c64e0256d82b64595c5559fb
Reviewed-on: https://gerrit.instructure.com/26178
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Andrew Butterfield