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>
Cody Cutrer