fixes#6510
Most of this is a refactor so that all API JSON generation goes through
an api_json method, in order to standardize stuff like permissions and
:include_root. The existing specs verify that this doesn't inadvertently
change any existing responses -- except the discussion topics responses,
which were returning the :permissions array in the json unintentionally.
The refactor fixes the locked assignment response as a side effect.
Change-Id: I287b366fe05ef6116f713fc52075aff93d5e87b6
Reviewed-on: https://gerrit.instructure.com/7262
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
test plan:
* don't start delayed jobs
* go to your local jobs page: http://localhost:3000/jobs
* open script/console and type: "now or later".send_now_or_later :later, :to_s
* refresh the "Jobs List" and see if a String#to_s job appeared
* start DJ and refresh to make sure the job was run
Change-Id: Iab997a4fcb252b481774309194dc6a0e937ecf4a
Reviewed-on: https://gerrit.instructure.com/7194
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
test plan:
ensure canvas works and specs pass in postgres 9.0 and 9.1 (as well as
mysql and sqlite)
Change-Id: I30889e7fd960848f7ea372d5b5e6877d017ea228
Reviewed-on: https://gerrit.instructure.com/7005
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
closes#6382
Previously, the "stay logged in" cookie just used the authlogic default
implementation, which is the pseudonym persistence_token. This is a
problem, because that persistence_token only ever changes when the
pseudonym password changes, so it's the same everywhere; so if that
cookie is stolen, it's valid for a very long time.
This switches us to one-time-use tokens that expire as soon as the token
logs the user in once. Each user agent also gets a different
one-time-use token.
Change-Id: I4f20cd7759fd74590e82ed55797552e342243d49
testplan:
* Check that no token is set at all when "stay logged in" isn't
selected.
* Check "stay logged in", and verify:
* That you don't have to login again after restarting your browser,
but your _normandy_session got reset.
* That if you save and try to replay using the same
pseudonym_credentials, they don't work the second time.
* That a second browser will get a different pseudonym_credentials
value, and using one token doesn't affect the other.
* That once the token is used, a new one is generated and set in
your cookies. Verify this new token works as well.
* That logging out removes the pseudonym_credentials cookie in your
browser. And also that manually restoring this cookie still
doesn't log you in, since it was removed server-side as well.
* Change your password, and verify that the existing "stay logged in"
tokens no longer work.
* Delete your pseudonym, and verify the same.
Reviewed-on: https://gerrit.instructure.com/7093
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
refs #6382
testplan:
* Login without selecting "stay logged in", and verify that no
pseudonym_credentials cookie is set, not even a session cookie.
* Verify the same when logging in via SSO.
Change-Id: I3bbb4f1057d2876541772b868f03f13df947c96a
Reviewed-on: https://gerrit.instructure.com/7092
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
testplan:
* login with "stay logged in" and without "stay logged in"
* in both cases, check your _normandy_session cookie, it should have
no expiration set (which means it expires when the browser session
ends)
* for the non-"stay logged in" case, close your browser, re-visit the
site, you'll have to login again
fixes#6364
Change-Id: Ibff32aa2f4225fd9cf05f5ce3abf9dd9f448d4ff
Reviewed-on: https://gerrit.instructure.com/7084
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
testplan: post a list of ids that contain non-numeric data or SQL
commands to /users/XXX/files/reorder (or another reorder URL) and verify
that such data does not make it into the SQL query.
closes#6377
Change-Id: If5cee005853a944cb14761ce3d910ea4cae09433
Reviewed-on: https://gerrit.instructure.com/7025
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
also made general purpose methods for ranking (in ruby and sql) and
distinct on.
Change-Id: I4052472eb700cbdfe6b586ed6d12f61fd51bf08f
Reviewed-on: https://gerrit.instructure.com/6593
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Assessment questions can be shared among multiple contexts, so we need to make
the Canvas links used inside authorized to anyone with the link.
Change-Id: I0df4907405fd518ee0efebccf1b9fb8717dca141
Reviewed-on: https://gerrit.instructure.com/6341
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
fastercsv is not supported in 1.9, instead csv in the stdlib has been
modified to be api compatible with fastercsv. in this first step, we
alias CSV to FasterCSV when running under 1.9. This allows 1.8.7 to
continue working with no changes.
Change-Id: I34c3a9031b6f4946380510e4833203e29a05073a
Reviewed-on: https://gerrit.instructure.com/5835
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Just use Rails.cache.fetch directly. This fixes some problems that
find_cached wasn't fully serializing the object.
Also, be sure to change cache keys so that we don't get data back
using the old format.
Change-Id: I8beea2f2ba446a97249a495789b25c3a71de420e
Reviewed-on: https://gerrit.instructure.com/5857
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
don't use a setter when we didn't use a getter
Change-Id: I081f114060e0aef395a955c212abe11df38d6933
Reviewed-on: https://gerrit.instructure.com/5988
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
these are syntax errors in 1.9.x
Change-Id: I7cbd66643cb371e4be9f8da0365bf1e988ee5de8
Reviewed-on: https://gerrit.instructure.com/5833
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Whenever we create a migration that drops or renames a column, in that
same commit we need to add that column to the list in this initializer.
Then, when we deploy and restart, AR will already see the column as
removed, and we can safely run the drop migration after deploy without
any window where users will get page errors due to stale column
information.
Change-Id: I1c95fd146ac8046af579256cccf95b42f01442b7
Reviewed-on: https://gerrit.instructure.com/5823
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
update_all's update hash doesn't have any magic performed on bare Time
objects; it assumes any Time object it's given is already in UTC. using
a TimeWithZone object (regardless of timezone), which Fixnum#ago and
friends happen to return, is still fine.
Change-Id: I297b2a3211b896b5225ebcfaaee3c1eb56e55fb6
Reviewed-on: https://gerrit.instructure.com/5351
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
* Daily job to evaluate alerts
* Spawns a new job for each root account (for parallelization).
It could be broken down to per-course level if needed (i.e.
if there is a *huge* root account).
* Evaluating criteria at a course level using efficient queries.
* UI for CRUD on alerts
* Render existing alerts
* Delete existing alerts
* Create a new alert
* CRUD for criteria, recipients, repetition
* Validations
* Improve instructure_helper's formErrors to support passing errors
for specific elements
* Improve Rails' :include to be able to :exclude an :include
inherited from a named scope
* Specs!!
* Note that we want to slowly roll this out, so there is a setting on
root accounts to enable it
So I ran an alert with just an interaction criterion on a test
cluster against 50,000 courses, and it took less than 10 minutes
without any parallelization. That seems like acceptable
performance to me (since there are only just over 3000 courses
in production that would even be elligible to have alerts sent
right now). Of course, that's probably skewed because I'm sure
a bunch of those 50,000 courses were essentially empty.
Change-Id: Ie028ef206c9155b9a72fb2a820f3e0e516de562a
Reviewed-on: https://gerrit.instructure.com/4799
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
also pull in course/group user so we can use it in the future
Change-Id: I34c2aea2fea9b56c988d4903fb2fcf32d96d4f10
Reviewed-on: https://gerrit.instructure.com/5190
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
optimize crosslisting itself:
* use ids where possible to avoid unnecessarily loading up objects
* Don't worry about keeping track of if we need to save; we're gonna
save anyway
* update account associations on any account change, not just root
account change (if you re-crosslist a section from one sub-account
to another sub-account, the users may no longer be associated with
the first sub-account).
optimize sis imports:
* really batch up update_account_associations
Change-Id: Ic0fbe1601afcbcd3e6540e69febc2e6a1a94157f
Reviewed-on: https://gerrit.instructure.com/5137
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
Basically, being an admin doesn't imply full access. Instead, it
only implies :read_as_admin, which only lets you see things like
course name and section names.
Add two new role overrides:
* :read_course_content implies :read on the course
* :manage_content is now a full fledge RoleOverride instead of
an internal permission implicitly given to Teachers and Admins
Actually start using :view_all_grades override so that Admins
without it won't see grades (replaces :read_as_admin that was
granted to concluded teachers; :view_all_grades is always granted to
concluded teachers, but not to Admins).
Spiffy up several helper functions to take an array of permissions,
and return if any of them are true.
Make sure not to show course tabs that the user does not have access
to.
Fix up lots of permission checks, especially around viewing users
(:read_roster, :manage_students, or :manage_admins might allow you
to see the users in a course; :read_roster only allows you to see
prior enrollments if it was granted to you as an account admin).
Change-Id: Iafcab7956649e9d28e17bd5eedcb155a9ea76af4
Reviewed-on: https://gerrit.instructure.com/5092
Reviewed-by: JT Olds <jt@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Conflicts:
app/controllers/context_controller.rb
config/assets.yml
spec/integration/files_spec.rb
spec/models/user_spec.rb
also removed test "ContextController GET 'inbox_item' should exclude
recipients if protect_recipients" since ContextMessage inbox items
aren't used any more on this branch.
Change-Id: I99d0e4914cb1bf9617993c1cb1afdbca0e9ba32f
Fixing this required some minor refactoring:
* A model can now define "filter_hash_for_user" to filter serialized data out
of the model based on user. In this case, we were sending the assignment to
the browser in json, and we wanted to strip out the description if the
assignment was locked for the user.
* The lock_explanation generator was not i18n'd before. That was fixed, and
similar code in javascript was also refactored so it can be called by
anybody. (In this case, by the assignments in the calendar.)
Change-Id: Ia606be2a16df9bd87222306445f548b3a7a78801
Reviewed-on: https://gerrit.instructure.com/5051
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@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>
This was already a small issue if the job queue was on a different
database driver than the main database, and it'll become more important
as more AR connections are introduced.
Change-Id: I204becadd32bb935df096e8c937a04bb6962f0b2
Reviewed-on: https://gerrit.instructure.com/4601
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>