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>
Change-Id: I398c129ef5f65d94dffc38608c04b21b13fccd2b
Reviewed-on: https://gerrit.instructure.com/29316
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Paul Hinze <paulh@instructure.com>
QA-Review: Paul Hinze <paulh@instructure.com>
Tested-by: Paul Hinze <paulh@instructure.com>
using these stats we should be able to follow SAML logins through their
lifecycle.
- `canvas.saml.{an_account_host}.login_attempt` is the start of the
process, where canvas redirects to the configured identity provider
- `.login_response_received` will track all return requests from
identity providers, regardless of outcome.
- from there, every login response should resolve into either a
`normal` or an `errors` subkey, with further details on the category
of outcome in the next level of nesting.
the logout path is less important (and has less outcomes). we simply
instrument attempts and responses received for this path.
Change-Id: I7eb90776adb06303ee349394266e716ca7e639a2
Reviewed-on: https://gerrit.instructure.com/29315
Reviewed-by: Paul Hinze <paulh@instructure.com>
Product-Review: Paul Hinze <paulh@instructure.com>
QA-Review: Paul Hinze <paulh@instructure.com>
Tested-by: Paul Hinze <paulh@instructure.com>
primarily switching fullpath in place of request_uri
in preparation for rails 3
Change-Id: If14f2cc2da5120a60f04d4cfdfb05a55482a3695
Reviewed-on: https://gerrit.instructure.com/27162
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
rather than CANVAS_RAILS3 or Rails.version
this is to be consistent, and to reinforce that any "special" branches
are for rails 2.3 backwards compatibility while trying to target rails
3, rather than rails 3 "forwards compatibility".
Change-Id: I4494b65e3f71108a43d09032c1569c478646a828
Reviewed-on: https://gerrit.instructure.com/24998
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
fixes CNVS-7383
test plan
- take a quiz
- it should not error
- the token should change on each request
- visit a page in canvas and open browser console(chrome, right click, inspect element) console is on the right side
- run ENV.AUTHENTICITY_TOKEN
- reload the page
- run ENV.AUTHENTICITY_TOKEN
- the tokens should not match
Change-Id: I405e749b37c7195af55b784d6b4f10346a15f377
Reviewed-on: https://gerrit.instructure.com/23506
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
refs CNVS-7008
This middleware reads and caches a blacklist from a Setting, then
compares it against the request (access token || user id) and the
request IP address.
You can change the blacklist and SIGHUP the rails process to reload it
without restarting rails.
Note that because of the limitations of middleware in rails 2.3 apps,
this doesn't look at the access token if it's given in a POST params
body, rather than the HTTP header or query string params.
test plan:
* By default this middleware won't block anybody. Verify that you don't
get 403 errors making canvas requests.
* The blacklist is a comma-separated list of identifiers. To set it:
Setting.set('request_throttle.blacklist', '1234') and then reload
Canvas.
* Add your user global_id to the blacklist, verify you are blocked in
web ui requests.
* Add an access token to the blacklist and use it, verify you are
blocked.
* Add your IP to the blacklist (likely "127.0.0.1" for local dev envs),
and verify you are blocked.
* Verify others are not blocked after these adds.
Change-Id: I4a1c7ef4bab70c586d603dc01f3ca440d211f11d
Reviewed-on: https://gerrit.instructure.com/23293
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
* disable i18nema until we're on rails 3.2
* fix how we access session_options
* fix how we access the basic auth header
* fix attachment_fu callbacks
test plan: none of these fixes should affect rails 2
Change-Id: I7f9b6f18c04d51284ec3e5e9fdd39fb93539c91b
Reviewed-on: https://gerrit.instructure.com/21728
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
Chrome and Firefox send the session from Flash, Safari does not. So allow
inferring the authenticity token whether a session exists or not
Also, the JS no longer needs to worry about if uploading to local or remote
and adding/filtering the authenticity token - just do the same every time.
test plan:
* use local storage
* upload a file by clicking "Upload Files"
* it should work in Safari, Firefox, Chrome, and IE
Change-Id: Ia46bde6ab042f21cd0643d4f5a1dbd2f7f9cee66
Reviewed-on: https://gerrit.instructure.com/21100
Reviewed-by: Jon Jensen <jon@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
when a user explicitly logs out of one pseudonym session, invalidate all
the others
fixes CNVS-1923
test-plan:
- create a user in two different accounts
- log them in to both accounts
- click "log out" in one account
- should be logged out of both accounts
Change-Id: I79e70017d753c8201429901421e015f5d20e2000
Reviewed-on: https://gerrit.instructure.com/20096
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
fixes CNVS-5248
test plan:
- start taking a one-question-at-a-time quiz
- log out in another tab
- hit the next or previous button
- re-login
- you should land back in the quiz
Change-Id: I578d6803bd6deb90ec3c82153d999b478e42a199
Reviewed-on: https://gerrit.instructure.com/19539
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Myller de Araujo <myller@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
This introduces the idea of a public API endpoint, one that doesn't need
an access token or a logged in user session. There aren't yet any
endpoints like this, but there are plans to add some so this lays the
groundwork.
I also cleaned up the permissions checks on some of the existing
endpoints, so that you'll get a 401 and sane error response rather than
a 500 error or empty data now that you can hit them when not logged in.
Also standardized the unauthorized json response. It's now more uniform
in structure, and differentiates between not authenticated and not
authorized. (403 might be more appropriate here, but i'm not going there now)
closes CNVS-4856
test plan: there's not yet an api endpoint you can successfully use
without authentication, but you can hit some of the modified endpoints
such as /users/self/groups or /courses/X/tabs without authentication and
verify that you get a 401 response with a relevant json error message.
Change-Id: I63b12628e95b7e2d9aa06c311078bc8a5170dad4
Reviewed-on: https://gerrit.instructure.com/19008
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
fixes CNVS-4455
you can never have too much context
also, apparently this is the first integration spec that uses the
API from a session (not an access token), so fix API forgery
protection to respect the allow_forgery_protection option
(what's set for specs to not have to worry about forgery
protection), and clean up enabling of it in specs to use
stubbing
test plan:
* do an action that counts as participating, but wasn't a GET
(i.e. comment on a discussion)
* you should see a page view for the user in that course
Change-Id: I8714de45575123d6877e0265623e0fcaf9e7fa58
Reviewed-on: https://gerrit.instructure.com/18504
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
closes #CNVS-3253
test plan:
- as a teacher go to Modules in a publicly available course
- add a module item and choose the "External Tool" type
- also add to the module an "External Tool" type assignment
- log out
- go back to the course's modules page (not logged in)
- click on the module item and assignment previously created,
both should require logging in
Change-Id: I2064cc30f3d2ef85236f386337f73e44ee4ce520
Reviewed-on: https://gerrit.instructure.com/17656
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Joe Tanner <joe@instructure.com>
refs #CNVS-2412
added some spec coverage for the action that
accepts the oath connection and start using
the global_id for the user instead of the local
id.
Also removed an oath method from
lib/authentication_methods that doesn't
get used anywhere (grep says so anyway,
we'll see what jenkins says).
TEST PLAN:
Behavior has not changed, this is just to
prevent a fairly specific authorization hack.
regression tests on oauth workflow should cover
it.
Change-Id: I39dd50276561677be11dd0ed3d3832624cf70a84
Reviewed-on: https://gerrit.instructure.com/16369
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
refs #CNVS-2174
found the bit in the authorization sequence where
saml login was being initiated without checking
for a discovery url. Fixed that, and also wrote
some unit tests around it.
ended up having to alter specs a bit to deal
with the extensions added by the
canvas_zendesk_plugin
TEST PLAN:
1) select an account that is authenticated with SAML
2) without logging in, attempt to hit a 'deep
link' on that domain with the browser (any url
that isn't the login page would be fine, as long
as it's something you must be logged in to access)
3) you should be redirected to the SAML discovery page
Change-Id: Id9c21650d8c053178d4d40ff064051af79c5eb2f
Reviewed-on: https://gerrit.instructure.com/16355
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ethan Vizitei <ethan@12spokes.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
refs #8943
This is phase 1. Once this is rolled out and the migrations have
finished, we can implement phase 2, which is dropping the token field so
that plaintext tokens are no longer stored in the database.
There should no longer be any code that reads the token attribute, it's
kept in the database purely to help with the transition.
test plan: before the postdeploy migration runs, access tokens should
still work. after it runs, access tokens should still work.
newly-created access tokens should work as expected. expired access
tokens should still error. For now, the plain-text token field should
still be populated for new tokens.
Change-Id: Icb1b4fdc8e2627ba6540d96d23eb28d874020acb
Reviewed-on: https://gerrit.instructure.com/14491
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
An account can now have multiple SAML configurations, and
can set an auth discovery url.
The old AAC API has been deprecated and this adds a normal
resource API for AACs
Test Plan:
* Test the api be doing lots of things
* Create two saml configurations
* Test the individual login urls for each (/login/{id}) and verify they work
* Test that the new SAML AAC UI works.
* Test that the SAML configuration in position 1 is used as the default
closes#10497
Change-Id: Ibe35fcf788d9506542b1079cc7420912a1e9d9a2
Reviewed-on: https://gerrit.instructure.com/14042
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
this gets rid of the "getting started" workflow (with the 4
steps: name, assignments, students, save) and just uses a
simple dialog for creating new courses. It is part of the new
user experience stuff.
refs: #9898
test plan:
click "create a new course" on dashboard, make sure
it works.
Change-Id: If1b28f3dd58fa40e3a0c0195dc5db97292566e7e
Reviewed-on: https://gerrit.instructure.com/13003
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
functionally the same, but allows for higher level routing of CAS
requests apart from general login requests
test plan:
* login and log out with CAS configured
Change-Id: Id4a9633f2dd48e9d7fe0cf9d3ec917750eb8c8ce
Reviewed-on: https://gerrit.instructure.com/12961
Reviewed-by: Brian Palmer <brianp@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>
saves me some time when I know I need to use it
test plan:
* canvas_login should work for:
* /?canvas_login=1
* /jobs?canvas_login=1
* /accounts/self/account_authorization_configs?canvas_login=1?
Change-Id: Iac032bc13a65e3f3e1284bf40ed51cadfb02080d
Reviewed-on: https://gerrit.instructure.com/11776
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Sam Olds <sam@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
it's no longer needed for the one customer that wanted it
test plan:
* CAS auth should continue to work
Change-Id: I47bd461769019bb9b57cbbfa8236de14c1614285
Reviewed-on: https://gerrit.instructure.com/11788
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
instead of leaving the key with a nil value
test plan:
* no user visible changes
* creating a new course, accepting invitations, and
registering google docs, linked in, and twitter are good places
to make sure they haven't changed
Change-Id: Ied684744dd23a4c56c1abab0e7c197a28cd66f40
Reviewed-on: https://gerrit.instructure.com/10633
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
we no longer have a usecase for them to be separate, so simplify things back
down to just one require_user method
test-plan:
- click around the various pages rendered by these controllers and make sure
that they still work for a logged in user, and still reject a logged out
user.
Change-Id: I4b55ccf6d889e1b97da4697f14749b99b4d256fb
Reviewed-on: https://gerrit.instructure.com/9786
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
allows course admins to view the course from a student perspective. this is
accessible from a button on the course/settings page. They should be able to
interact with the course as a student would, including submitting homework and
quizzes. Right now there is one student view student per course, so if the
course has multiple administrators, they will all share the same student view
student.
There are a few things that won't work in student view the way the
would for a normal student, most notably access to conversations is disabled.
Additionally, any publicly visible action that the teacher takes while in
student view will still be publicly visible -- for example if the teacher posts
a discussion topic/reply as the student view student, it will be visible to the
whole class.
test-plan:
- (the following should be tried both as a full teacher and as
a section-limited course admin)
- set up a few assignments, quizzes, discussions, and module progressions in
a course.
- enter student view from the coures settings page.
- work through the things you set up above.
- leave student view from the upper right corner of the page.
- as a teacher you should be able to grade the fake student so that they can
continue to progress.
- the student should not show up in the course users list
- the student should not show up at the account level at all:
* total user list
* statistics
Change-Id: I886a4663777f3ef2bdae594349ff6da6981e14ed
Reviewed-on: https://gerrit.instructure.com/9484
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
also search for the default developer key on the default shard
refs #7788
test plan:
* create an api key (on the default shard)
* access the api on a non-default shard
* it should still work
* create an oauth token in the UI on a different
shard
* it should work, and reference a key on the default shard
Change-Id: I8c8aa36ab38f45ba9af2422a42552faeff28ac73
Reviewed-on: https://gerrit.instructure.com/9492
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
* faster discussion loading, uses materialized view
* threaded discussion support
* navigate between unread messages
test plan:
* use every feature within discussions
Change-Id: I9e89028e5a618c36a57dae958a16b0be73c35baa
Reviewed-on: https://gerrit.instructure.com/9584
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
previously, require_user actually required both a user and a pseudonym. this
change pulls them apart into separate require calls, creating the ability to
require at finer granularity.
test-plan: run specs
Change-Id: I0124d4685bd521c16ed47c7e2e35e960adc6598b
Reviewed-on: https://gerrit.instructure.com/9381
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
refs #6605
test plan: masquerade as a user, and then try to upload a file to that
user's /dashboard/files page. you should not get an error.
Change-Id: I0583e3d0192207a2b18ae1824e68745d401c80e9
Reviewed-on: https://gerrit.instructure.com/8552
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
change requirements from needing :become permission in all accounts
associated with the user, to only needing become in @domain_root_account.
also relax the masquerade-as-other-admin requirements to allow masquerading
as an admin that has less than or equal access as you
test plan:
* ensure that an account admin can masquerade as a user that belongs to
multiple accounts (but only within the account the admin has permission
to)
* ensure that an account admin can masquerade as another account admin
* ensure that an admin in a restricted role but is allowed to masquerade
cannot masquerade as a full admin
Change-Id: Id2e1c4bc33d94be3b10f524fbb1633a7478749a0
Reviewed-on: https://gerrit.instructure.com/8844
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
This just gathers all the information for a single saml
login attempt so that an admin can try to debug faulty
configurations
Test Plan:
* Setup a SAML configuration
* Click "Start Debugging" on Authentication page
* Login with a user on that account
* Hit "Refresh" and observe the beautiful xml
closes#5232
Change-Id: Ic6dd2e828196d0bcbde2e301c5326d77fe55cb71
Reviewed-on: https://gerrit.instructure.com/8368
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
this method was a thin wrapper around get_context that redirected to the root
page if a context didn't exist. Ostensibly it also showed the http error as in
flash message if a context did exist but the user didn't, or didn't belong to
the context, but this branch of code never worked due to a state vs
workflow_state bug that rendered the if statement always false.
Change-Id: I5a7353ddf3e1fc082324384a5ea3d3b6196c0dfd
Reviewed-on: https://gerrit.instructure.com/8499
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
refs #6883
Use it when checking if a pseudonym is valid for authentication, but
not for if we need to create a new pseudonym for an account. This
means that you can authenticate via an implicit trust relationship,
but when you are invited to something, it will still try and create
a pseudonym for you in that account.
test plan:
* run existing specs (no behavior is changed without a plugin
to define trust relationships)
Change-Id: Ieb200da27351c185e640e9c50ae1a6054e502c63
Reviewed-on: https://gerrit.instructure.com/8076
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
test plan:
* do an api call providing as_user_id=, but no actual value
* it should succeed
Change-Id: I3114e672ea427935045fa64be7c03c922290d042
Reviewed-on: https://gerrit.instructure.com/8227
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Zach Wily <zach@instructure.com>
A lot of error situations in the API were responding with our HTML
"oops, tell us what happened" form, which is just silly. This commit
starts a framework for handling API errors, and ensures that in the
most generic case, the caller will at least get a JSON response with an
appropriate HTTP status code and a "unknown" error response. No more
HTML responses.
This framework is then used to add detailed error responses for auth
token errors, and ActiveRecord::RecordNotFound errors.
test plan: Make API calls without a proper access token, check the error
response and the www-authenticate header. Make API calls with a dummy id
(like /api/v1/courses/blah), and verify the response JSON.
Change-Id: I052be2a1d9762caf9f74c7f2ea2db40f204d1263
Reviewed-on: https://gerrit.instructure.com/7695
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
This way we can run specs with overrides in a sane way.
test plan: n/a
Change-Id: Iffa749feb04c531a5abd6892a48e6dcd7894e8be
Reviewed-on: https://gerrit.instructure.com/7728
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@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>
fixes#6456
test-plan:
* provide a bogus as_user_id in an API call (e.g. sis_user_id:bogus)
* should return an error response, instead of a normal response in
the original user's view
Change-Id: I989001d459f7570a8fc83700cb0d3e4178219049
Reviewed-on: https://gerrit.instructure.com/7685
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
test plan:
* issue an access_token
* delete the user's pseudonym(s)
* the access token should no longer work
Change-Id: Ib4ecee6b3713827dd997e06481ddae1175042a9b
Reviewed-on: https://gerrit.instructure.com/7637
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
Otherwise the alternate login screen may not get the user back to the
oauth2_token page in a state that the application recognizes.
test plan: Execute the oauth flow against an CAS account with a log_in_url
configured (e.g., with the iOS app). The flow should not redirect to the
alternate url, instead using the primary CAS url. Also confirm that
normal non-oauth logins still use the alternate url.
Change-Id: Iba39b719a5f80727801880660d19afa128b898ce
Reviewed-on: https://gerrit.instructure.com/7368
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
refs #6199, #6177
makes it easier for a plugin to modify the logic. also removed dummy
method in Account that is never hooked into.
Change-Id: I87e2cad5172f6dece4448d61dc4681a94c44cecb
testplan: login
Reviewed-on: https://gerrit.instructure.com/6982
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
this reduces confusion for multiple users trying to share e-mail addresses
also changed to passing the information as
pseudonym_session[unique_id]=<unique_id> and expected_user_id rather than
pseudonym=<pseudonym_id> to prevent a leak of information for users just
putting in arbitrary values for pseduonym_id. Conveniently, this means
that incorrect passwords will pre-fill the form with the username you
just tried.
testplan: add an e-mail in your profile, and then log out before confirming
Change-Id: I51ae5301d509cc6cdca0fbed8118cc4b5279f928
Reviewed-on: https://gerrit.instructure.com/6805
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
* Don't show merge opportunities for confirmation or transfer enrollment flows
* Combine current user and other user sections into a single section
* Use simplified wording for single merge opportunity
* Use "add e-mail address" for logged in, non-matching single e-mail opportunity
* Hide the registration form behind an additional click if there are merge
opportunities
* When a login is required to complete the action, automatically do the action
after login, assuming they logged in as the correct user
Change-Id: If07b38702c15509af6798fc00bc062f286789438
Reviewed-on: https://gerrit.instructure.com/6649
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
refs #5948
adjust specs so that if a login does inject themselves in by adding
additonal redirects, we keep following them
Change-Id: I16e616066ea1bef1aa5ed97718cbd8ddbd2c27c5
Reviewed-on: https://gerrit.instructure.com/6536
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fixes#5573, #5572, #5753
* communication channels are now only unique within a single user
* UserList changes
* Always resolve pseudonym#unique_ids
* Support looking up by SMS CCs
* Option to either require e-mails match an existing CC,
or e-mails that don't match a Pseudonym will always be
returned unattached (relying on better merging behavior
to not have a gazillion accounts created)
* Method to return users, creating new ones (*without* a
Pseudonym) if necessary. (can't create with a pseudonym,
since Pseudonym#unique_id is still unique, I can't have
multiple outstanding users with the same unique_id)
* EnrollmentsFromUserList is mostly gutted, now using UserList's
functionality directy.
* Use UserList for adding account admins, removing the now
unused Account#add_admin => User#find_by_email/User#assert_by_email
codepath
* Update UsersController#create to not worry about duplicate
communication channels
* Remove AccountsController#add_user, and just use
UsersController#create
* Change SIS::UserImporter to send out a merge opportunity
e-mail if a conflicting CC is found (but still create the CC)
* In /profile, don't worry about conflicting CCs (the CC confirmation
process will now allow merging)
* Remove CommunicationChannelsController#try_merge and #merge
* For the non-simple case of CoursesController#enrollment_invitation
redirect to /register (CommunicationsChannelController#confirm)
* Remove CoursesController#transfer_enrollment
* Move PseudonymsController#registration_confirmation to
CommunicationChannelsController#confirm (have to be able to
register an account without a Pseudonym yet)
* Fold the old direct confirm functionality in, if there are
no available merge opportunities
* Allow merging the new account with the currently logged in user
* Allow changing the Pseudonym#unique_id when registering a new
account (since there might be conflicts)
* Display a list of merge opportunities based on conflicting
communication channels
* Provide link(s) to log in as the other user,
redirecting back to the registration page after login is
complete (to complete the merge as the current user)
* Remove several assert_* methods that are no longer needed
* Update PseudonymSessionsController a bit to deal with the new
way of dealing with conflicting CCs (especially CCs from LDAP),
and to redirect back to the registration/confirmation page when
attempting to do a merge
* Expose the open_registration setting; use it to control if
inviting users to a course is able to create new users
Change-Id: If2f38818a71af656854d3bf8431ddbf5dcb84691
Reviewed-on: https://gerrit.instructure.com/6149
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Admins can now masquerade users by giving an SIS id in
the as_user_id param, e.g.: as_user_id=sis_user_id:1234.
Change-Id: I9bb03ecf53c4ceba574dd4d196c0281ac8dd3141
Reviewed-on: https://gerrit.instructure.com/6335
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Authlogic has already read it out of the database at this point, so
the cache doesn't gain us anything.
Change-Id: I4bd21ddf17dbbe0efe288a26a4281440e6e932ad
Reviewed-on: https://gerrit.instructure.com/5972
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
allowing api_key to replace authenticity_token for normal cookie
sessions would open us up to a CSRF attack, by allowing a malicious user
to use the api_key without explicitly having the user credentials.
fixes#5162
Change-Id: Ia2604a6930d660dd04a8783fc983a3fe381ff48d
Reviewed-on: https://gerrit.instructure.com/5028
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
refs #5029
For now we're going to continue to support api key+basic auth as an
alternative to oauth and access tokens, though eventually this will be
phased out.
This also switches all the api specs to using oauth tokens, except for
the new specs that explicitly test the old method is still supported.
There is one change: GET requests now require the api_key as well, if
using the api_key auth method.
Change-Id: I97d6c71be7afaa655da521d774930b2649961ffe
Reviewed-on: https://gerrit.instructure.com/4720
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
closes#4332
* Allow :become_user to be granted to any root account admin role,
not just site admin roles.
* Adjust policy on User objects to properly grant :become_user:
* You can always become yourself (stop masquerading)
* Site admins can become any user besides other site admins
* Root account admins can only become users that are not account
admins, and that belong to accounts that this root account admin
has permissions to
* Adjust masquerading code to check for :become_user on the user
object itself, rather than checking just on the site admin account
* This means we have to figure out the target user before checking
permissions
* Because the permission check already checks for becoming another
site admin user, that special case was removed in the
masquerading code
* Special case the UI to not show the "become" link for the
current user (i.e. you can't become yourself, and you can't
become the user that you already are)
Change-Id: I69bc855b8ee24098b9a63b0b1c8d7edf2063b625
Reviewed-on: https://gerrit.instructure.com/4614
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
URLs that might not require a user were using
render_unauthorized_action, which just rendered the login partial,
rather than redirecting to login_url. This meant that delegated auth
logic in PseudoSessionsController#new was getting skipped. So for
render_unauthorized_action in the specific case that there is no user,
call a method to kick of delegated auth, if necessary.
Also fix a problem that session[:return_to] was getting wiped for
delegated auth, so you'd end up at the dashboard, rather than where
you wanted to go.
Change-Id: I42c24e31ca58cccc33d349bcb451defd3aaa5c9c
Reviewed-on: https://gerrit.instructure.com/3993
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Cody Cutrer