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>
James Williams