refs FOO-739
TEST PLAN:
1) disable request throttling
2) run some requests that are expensive
3) costs should still be tracked in headers
Change-Id: Iec1a60f797451c789c3cdb79682757b8c354005f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/243569
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
test plan:
* do an LTI grade passback
* verify in the server logging that request throttle client identifiers
includes a "tool:<domain>" entry
Change-Id: I90914187848876ebe7a20ef87d0ff933254cc83b
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/226231
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
test plan:
* create an access token
* blacklist your user id in console
* try to access canvas with your access token
* it should not work
Change-Id: I9cf30798e844a648040a396258ca923cb4d77513
Reviewed-on: https://gerrit.instructure.com/199202
Tested-by: Jenkins
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes CORE-2538
test plan
- configure statsd to use data dog
- it should work
Change-Id: Ie8428e4e99973b35506bd7a8e4d1a18f5a7875a1
Reviewed-on: https://gerrit.instructure.com/182083
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
and rename that suite of methods to make more sense
test-plan: N/A
Change-Id: Iffc520ea55141ac47da669663838a4d3c3d8712c
Reviewed-on: https://gerrit.instructure.com/142486
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
closes OUT-1534
Scheduling of outcome import jobs will occur in a separate PS,
after this merges and OUT-1997 is merged too.
test plan:
- start up canvas
- generate api docs:
> docker-compose run --rm web bundle exec rake doc:api
- load api docs in http://canvas.docker/doc/api/index.html
- read over the "Outcomes CSV Format" and make sure it reads well
- read over the "Outcomes Import" and make sure it reads well
- obtain an access token:
https://community.canvaslms.com/docs/DOC-10806-4214724194
- request an outcome import, replace "canvas-path" and "token" values:
curl -F attachment=@<canvas-path>/spec/lib/outcomes/fixtures/demo.csv \
-F 'import_type=instructure_csv' \
-H "Authorization: Bearer <token>" \
http://canvas.docker/api/v1/accounts/1/outcome_imports
- in a rails console, confirm that the import was accepted:
> docker-compose run --rm web bin/rails console
% pp OutcomeImport.last
# confirm that the import is in the 'created' state, associated with
your user and associated with an account context
# note the "id" value for later use
% pp OutcomeImport.last.attachment
# confirm that the attachment is in the 'processed' state and has
the filename "test_outcomes_1.csv" passed in above
- request the status of the outcome import (should return a message
saying "The specified resource does not exist"):
curl -H "Authorization: Bearer <token>" \
http://canvas.docker/api/v1/accounts/1/outcome_imports/latest
- back in the rails console created above, manually transition
the import to "importing":
% OutcomeImport.last.job_started
- run the above curl command again, and this time the latest outcome
import should be returned, in the 'importing' state
- run the above curl command again, replacing "latest" with the "id"
value obtained above. it should return the same response as the
previous step.
Change-Id: Ice7d67b625b443cec70f531f2e673face6d6fbeb
Reviewed-on: https://gerrit.instructure.com/142024
Reviewed-by: Neil Gupta <ngupta@instructure.com>
Reviewed-by: Frank Murphy <fmurphy@instructure.com>
Tested-by: Jenkins
QA-Review: Frank Murphy <fmurphy@instructure.com>
Product-Review: Neil Gupta <ngupta@instructure.com>
fixes CORE-731
Test plan:
* be a site-admin user on a shard that is not the birth shard
* export the gradebook for a course on the birth shard
* it should work
Change-Id: I8cf90111d1c63099f6d18bdf55ea1fabb4cf9f43
Reviewed-on: https://gerrit.instructure.com/136151
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-39263
otherwise they may never get dinged for the cost of the current request
test plan:
* have redis configured
* watch the response headers on several requests
* the X-Rate-Limit-Remaining should never be exactly equal to the
high water mark (defaults to 600); it should be slightly below
Change-Id: I89e85f873b405e0bd93a6e89730dd504ca934104
Reviewed-on: https://gerrit.instructure.com/125866
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins
QA-Review: Tucker McKnight <tmcknight@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-39296
test plan:
* run jobs/web (must be using a web server that doesn't capture HUP
itself)
* HUP your processes
* notice that they don't crash, and the logs will say that the reloader
ran
Change-Id: I150729fdb68c0fd0ff462d794eecfc8da7e17e5e
Reviewed-on: https://gerrit.instructure.com/125968
Reviewed-by: Tyler Pickett <tpickett@instructure.com>
Tested-by: Jenkins
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-39262
test plan
- disable throttling
- it should still return X-Rate-Limit-Remaining
Change-Id: Id6e0110d641d214797ac5657beccc91920207a58
Reviewed-on: https://gerrit.instructure.com/125863
Reviewed-by: Simon Williams <simon@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
this allows customizing the throttle settings value by updating a JSON
hash in the Setting table: `request_throttle.custom_settings` (see
formatting below)
The Setting value is a hash of client identifiers -> custom settings.
A custom setting is a hash with some subset of the following keys: hwm,
maximum, outflow, up_front_cost. the values of those keys are floats.
For example:
Setting.set(
'request_throttle.custom_settings',
{ 'user:10000000000001' => { 'hwm' => 1000.0 } }.to_json
)
these values will be used instead of the default values for requests
from that specific client_identifier
fixes CNVS-35965
test plan:
- set up a script that hammers the API and gets throttled
- create two users with two tokens
- set maximum and hwm to really high values for one (by user id), and
verify that it is no longer throttled
- repeat, but use the access token as the id
Change-Id: I8a5e393721c7cbd4c754989ba219f92f0e280ee1
Reviewed-on: https://gerrit.instructure.com/105302
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Tucker McKnight <tmcknight@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
it can cause reloading problems, since Struct.new returns a new class
everytime. instead, assign to the constant, and use the block form of
Struct.new to add the additional methods
Change-Id: I0dd07b1608ab9226bb5d8cf60a648cc12c98a30c
Reviewed-on: https://gerrit.instructure.com/101620
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
the thread_safe gem has deprecations too, but they'll require Rails 5.1
until they're fixed (when both activesupport and tzinfo no longer
depend on it)
Change-Id: Ic53839d911ba8ed4d463d17f9dd7207673510f3a
Reviewed-on: https://gerrit.instructure.com/100499
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
and use the appropriate rack-level options for passing the
session timeout from plugin settings down to the middleware
and remove "support" for other session stores
Change-Id: I8e6cab65534a150eb116b38deeced4686d9ade33
Reviewed-on: https://gerrit.instructure.com/95399
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
QA-Review: Benjamin Christian Nelson <bcnelson@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
refs CNVS-27581
this ensures we have one correlation ID for a request coming
through the ecosystem rather than a seperate ID for each request
at each service. Each request id must be signed to make sure
others can't just submit whatever they want.
TEST PLAN:
1) make an API request and provide the header 'X-Request-Context-Id'
2) make sure to include the X-Request-Context-Signature header, which
should have the value of the sha512 signature with the shared
secret for the services ecosystem
2) the logs should show your provided value as the context Id for that
canvas request
Change-Id: I610fbe8c4df355d43c05360670f80971d1459644
Reviewed-on: https://gerrit.instructure.com/73166
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
It is a middleware so it was in the wrong place. This solves class
reloading problems in dev.
test plan:
request throttling should still function (you can look for "request
throttling increment" log lines) and should no longer cause "A copy of
Canvas::RequestThrottle has been removed from the module tree but is
still active" errors.
Change-Id: Ied6aaa6de4ac64ddfb14c80c76463f253b988bd7
Reviewed-on: https://gerrit.instructure.com/70265
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
e.g. use .seconds.ago instead of .ago
refs #CNVS-26056
Change-Id: I5af8541116623a8fc8b49682b0829a065aba59c8
Reviewed-on: https://gerrit.instructure.com/69339
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
if the http server passes the "X-Request-Start" header, compute the
difference in microseconds between that time and the time the request
begins processing in rails, and return it as "q" in the canvas meta
header.
fixes CNVS-25192
test plan:
- configure apache to set the X-Request-Start time to the current time
in microseconds, formated as "t=XXX"
- make a canvas request
- inspect the X-Canvas-Meta header returned
- it should include a "q=XXX" value
Change-Id: I3f1c5d6448ac8b53cb2d254ae86b5629cb003db1
Reviewed-on: https://gerrit.instructure.com/67736
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Closes CNVS-23363
Closes CNVS-24692
Include interaction_seconds updates to previous requests in
request metadata.
Instead of passing around a page view id, we are now passing around the
URL used to update the current page view. This URL includes a page_view
token, which is a JWT including the page view id, user id, and page view
creation time.
Previously the DOM was used to store the page view id of the current
page and the update URL. The update URL now is sent via js_env. The
DOM node with the page_view_id is left in place in case any 3rd party
javascript is querying it (but nothing in Canvas should be).
This change also logs in metadata the page view creation time. This
is so we can correctly correlate the updated page view with the original
page view (using its id and creation time).
There is also a mechanism to send a new update URL in AJAX requests,
which is preserved with this change.
Some code to send the page view id with every ajaxJSON request was
removed, as it appears completely unused.
Also fixed a bug that was preventing the "store page view info
in cookie on pageunload so the next request can send the update"
code from working. When setting the cookie, it was not specifying
a Path, so the cookie only got set on the current path. Now it
will always be handled on the next request.
test plan:
* Open Network Inspector to see requests being made
* Open a page that constitutes a "page view" (like a course's
discussion page)
* Note the X-Request-Context-Id response header for the request you
just made. This is your current page view id.
* Move your mouse around a whole bunch on the page you're on. This
generates "interaction time".
* Eventually, you'll see a new request pop up to /page_views. Look
at the response headers for X-Canvas-Meta. It should have a field
r=<guid>|<timestamp>|<seconds>. The `guid` field should match the
page view id from the original page you loaded, and `seconds`
should be about how long you've been moving your mouse around.
Change-Id: I7c418c1c690e7c2384fbcae86f21f5081b834a7e
Reviewed-on: https://gerrit.instructure.com/63818
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: Zach Wily <zach@instructure.com>
Rack generates a session_id internally which we like to include in logs
for tracking requests. This session_id wasn't getting picked up by out
log wrapper because of interdependencies in the middleware call stack
and bugs in rack/rails. Read on for details:
See the order of the middleware stack by running: `rake middleware`
The main players in this saga are:
- RequestContextGenerate middleware
- session store middleware:
ActionDispatch::Session::EncryptedCookieStore <
ActionDispatch::Session::CookieStore <
Rack::Session::Cookie <
Rack::Session::Abstract::ID
- Rack::Session::Abstract::SessionHash
How to intercept the session_id:
The Rack session_id is generated lazily the first time the SessionHash
(which is a thin wrapper around a ruby hash) is read from or written to.
This needs to happen after the session has been loaded out of the cookie
by the session store middleware, which happens after our
RequestContextGenerate middleware. We don't just want to move the
generation of the request id later, because then the first couple log
lines will not tagged with a request id.
So our idea was to capture the session_id in an un-encrypted cookie that
could be read early in the middleware call stack (which is fine to be
public, and only used for logs to not a big deal if it's tampered with).
Again, this happens lazily on first access, so our best bet is to catch
it on the way out of the middleware stack. But when
RequestContextGenerator returns it's already too late, because cookies
have already been written to the header. So we introduce a new
middleware that captures the session_id, writes it to a cookie, and then
modify RequestContextGenerator to read from the cookie.
This works great except that with this setup, after a log in attempt the
redirect after login would still be logged with the old "unknown"
session_id and not the new, logged-in session_id. When a session is
cleared (what happens at log in time), ActionDispatch implements
a `reset_session` that we call, which calls session.destroy, but rack
had not implemented session.destroy, so rails patched it, but then after
calling destroy, they reset the session to a plain hash (not
a SessionHash), so an id isn't generated until the plain-hash session is
written to the cookie, which happens AFTER our new middleware finishes
in the stack (and never sets it in the place we look for it).
Rails 4:
Rack internals changed somewhat between rack-1.4 and rack-1.5 and the id
moves from being stored in the session options hash to the main session
hash. We'll need to fix this for rails 4.
A better way:
It may be better to try to keep a handle on the actual SessionHash so
that we can dynamically load the id for log lines, and pick up id
changes immediately as they happen, mid-request. We'd have to make sure
the lookups weren't too expensive though, vs just saving a string.
fixes CNVS-15259
Test plan:
- start a server, make a request
- you should see log lines start with [session_id, request_id] and
session_id should be present, not just "-"
Change-Id: I0289db255b2b0bc3b118e32fc1d0d9381455b1ec
Reviewed-on: https://gerrit.instructure.com/64092
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins
QA-Review: August Thornton <august@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
Prevents "A copy of LoadAccount has been removed from the module tree
but is still active!" on any changes to app/* code.
Change-Id: Ie539f99bc44c330902ab7c8f4abcd7d698d64f1f
Reviewed-on: https://gerrit.instructure.com/63718
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Ryan Taylor <rtaylor@instructure.com>
fixes CNVS-21479
test plan: make API requests to canvas, and verify that the X-Canvas-Meta
response header includes the controller, action, and context fields.
Change-Id: Ib2c8724d295d192c8b80125439cf68a7a6215c6f
Reviewed-on: https://gerrit.instructure.com/57143
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Tested-by: Jenkins
Product-Review: Brian Palmer <brianp@instructure.com>
closes CNVS-18285
rails 3 provides built in mechanisms for capturing metrics around
performance. switch to it and add in db and view creation timing to
statsd
test plan:
- enable statsd metrics collecting in config/statsd.yml
- visit several pages
- verify that controller action timing is still being collected
- verify that controller action view runtime is now being collected
- verify that controller action db runtime is now being collected
Change-Id: I06dcf51adb988f70c4c5152cd56e93b39795ff6c
Reviewed-on: https://gerrit.instructure.com/48024
Tested-by: Jenkins
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Jason Madsen <jmadsen@instructure.com>
The problem was that quiz questions were going through some
transformations when generated for a submission, but those
transformations were not applied when we re-generated the questions from
a regrade. This patch makes those xforms happen in both phases.
Closes CNVS-15727
TEST PLAN
---- ----
- create a quiz with two questions, the second being like MChoice
- modify the title of the second question
- take the quiz by a student
- edit the quiz, and the question, and choose a different answer (and
make sure it's not what you picked, so you get affected)
- choose the option to only give full credit to ones who chose the
*new* answer (again, so the student sub gets affected)
- reload the student view of the submission and verify:
- you see the "This question has been regraded." banner
- you see Question 1 and Question 2 as titles
- you see the same thing (for titles) from the teacher's perspective
Change-Id: I43a9edc03a381efa0d1c2ccfc7705d0ba912184b
Reviewed-on: https://gerrit.instructure.com/41906
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Derek DeVries <ddevries@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Derek DeVries <ddevries@instructure.com>
Include relevant request information, for easy storing in web access
logs
closes CNVS-11044
test plan: Make web requests, use your browser's web inspector to verify
the x-canvas-meta response header.
Change-Id: I07e31b571bd9a946c9bc753c60eb8872ff456ff7
Reviewed-on: https://gerrit.instructure.com/37276
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
test plan:
- regression test to make sure that you can navigate to different
domains and shards, create + process delayed jobs, and navigate to the
default and site admin accounts
Change-Id: I0ed4bf3309e3950a046ed1cd7bc7b1fe0a806a7a
Reviewed-on: https://gerrit.instructure.com/39972
Tested-by: Brian Palmer <brianp@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
refs CNVS-13987
what was called CanvasUuid was *not* generating UUIDs. it was generating
slugs. by default, its generate method only creates 4 character slugs.
these should obviously not be used as UUIDs. the misnomer already caused
a bug in EventStream where it used these slugs as UUIDs, causing
collisions. to fix:
(1) rename canvas_uuid gem to canvas_slug, and rename it's primary
class CanvasUuid to CanvasSlug
(2) create new canvas_uuid gem, with class CanvasUUID, extracted from
lib/uuid_singleton for actual UUID generation
(3) fix event stream use CanvasUUID, rather than following the rename
of CanvasUuid to CanvasSlug
test-plan:
- have cassandra set up for audit logs
- create an audit log entry (e.g. change a grade)
- look at the generated audit log entry's id field; it should be a UUID
value, not a 4 character slug
Change-Id: I19758fff4433cd6cb2e21219217dced19ee05c5a
Reviewed-on: https://gerrit.instructure.com/37506
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
Make sure it comes before ActionDispatch's logging of the request start
fixes CNVS-13890
test plan: turn on 'log_context: true' in config/logging.yml, and make
sure that the `Started GET "/path"` lines have the correct request id of the
subsequent request, not the previous request.
Change-Id: Ie6a77993955296b9032e07f8536506b6816517b7
Reviewed-on: https://gerrit.instructure.com/37183
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
moves the load account and session timeout plugin middleware
to set the expire_after before the session store is called,
and changes encrypted_cookie_store to use that option so it can
invalidate expired sessions when it unmarshals the data
for the first time.
The reason it seemed to work locally is because it sets
@options[:expire_after] after the first request.
Unfortunately this second time doesn't often happen
in the actual application when distributed amongst several
instances.
test plan:
* set the "Sessions" plugin settings to timeout after
1 minute using the following console commands;
ps = PluginSetting.
find_or_create_by_name_and_account_id("sessions",
Account.default)
ps.settings = {"session_timeout" => "1"}
ps.disabled = false
ps.save!
* (Note: normally this would be done
by going through the plugin settings ui, however, it enforces
a minimum of 20 minutes, which is difficult to test with)
* start the server and log-in
* shut down the server
* wait for 1 minute for the session to time out
* restart the server and try to click a link
* should be redirected to the log-in page
fixes #CNVS-7870
Change-Id: I843b73da7d3c001f7e632b1454c63f9d6c07f73d
Reviewed-on: https://gerrit.instructure.com/26911
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
This can successfully load rails console and rails server. There are
many, many problems still. The idea is this won't change anything under
rails 2.3, it's all backwards compatible.
closes CNVS-4711
test plan: `touch RAILS3` in your Canvas Rails.root directory. The run
`bundle update` and verify that you get rails 3 installed. Run `bundle
exec rails c` to load console or `bundle exec rails s` to start a
webrick server. You can login, though the dashboard currently breaks.
Also jammit isn't working yet.
But more importantly, Rails 2.3 should still work same as ever. All
tests should pass, and a basic regression sanity check would be good too.
Change-Id: Idd6f35de88adde84cd2db3a650f44b71bd6e9684
Reviewed-on: https://gerrit.instructure.com/18453
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
fixes#11388
This should work for single and multiple accounts.
You can now enable a plugin that lets you set
how long (in minutes) before users on your account
are automatically logged of because of inactivity.
You are required to set this to at least 20
minutes or more.
Test Plan
Steps:
1. log in as a site admin
2. [plugins]
3. [Sessions]
4. on the account drop down menu, select all
accounts, then enter a time in the text field
in minutes. At least 20 minutes
5. [Apply]
6. log out
7. go to /login and make sure the
"stay signed in" checkbox is checked
8. log in with any user that can get on the
account you enabled the plugin to work for
9. wait for a little longer than the amount of
time you set the plugin for
10. try to complete an action, like clicking on
course or the canvas home page logo
You should be logged out
Thanks Adam for writing this test plan.
Change-Id: If7dc772e4a1a59e646645c698d732308d3e0a19f
Reviewed-on: https://gerrit.instructure.com/15231
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Adds an infrastructure for using statsd (configured with
config/statsd.yml) and uses it to track a few basic stats. Stat names
are appended with the hostname.
test plan: without statsd enabled, make sure no errors are raised when
doing requests. add a statsd.yml configuration, restart the server, and
verify that stats are sent over UDP to the given host/port (this could
even be checked without statsd available, by monitoring UDP traffic)
Change-Id: Ie8c3ece7e08ff48616ffd968069bd760300e4fd2
Reviewed-on: https://gerrit.instructure.com/12673
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
test plan:
* set a custom css for site admin
* other root accounts should pick up that custom css
immediately without restarting the server
Change-Id: Ief1356f7a67b3ea461656bc8f6a9bf1938566b91
Reviewed-on: https://gerrit.instructure.com/8522
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
This will allow things outside of controller actions, like the soap
endpoint, to use this information and ensure that account-specific
request settings are set properly.
refs #3760
Change-Id: I85284d42b3206ff362c4aee6a998737ab89fc4b7
Reviewed-on: https://gerrit.instructure.com/2579
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Ethan Vizitei