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>
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>
Now when adding ?become_user_id=XXXX to a URL, the admin will be redirected to
a page where they confirm that they want to masquerade as that user. This is
to prevent people from being able to change who an admin is logged in as with
simple img links.
It also adds a "Stop Masquerading" link to the identity bar.
Thanks to Patrick Michaud for pointing this out. Fixed gh issue 22.
Change-Id: I196f9f1412022de371da7a8f4670bcd4a1c35653
Reviewed-on: https://gerrit.instructure.com/3904
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
These are no longer used and can have a significant db cost.
Change-Id: I8fcf7cfe3a20e056310d760d97ca3a04ca387bb7
Reviewed-on: https://gerrit.instructure.com/2825
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Raphael Weiner