query_string_redacted in Requests Table?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I downloaded the requests table in Canvas Data. I have only one day's worth of data in the requests table, but I am assuming that I need to request the historical dump of our data, is that right? That said, within the requests table I get "query_string_redacted" on quite a few of the URLs. Is this normal? Or is it an error?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Krista,
As for the historical data, yes you'll need to make a request for historical back fill. This can be done through Canvas Support.
As for "query_string_redacted" this is a completely intended feature of Canvas, and how it's data is stored in the requests DB. Query string redacted is put in place whenever a query string contains an authentication token. This is very important from a security perspective from multiple reasons here are three major ones:
1. Requests are actually stored in a different database application than the normal data (which is postgres). PostgreSQL is the High performance DB Application, however Cassandra (the leading NoSQL Storage system) has many features valuable to the requests table. Especially considering how huge the requests table can be. It also prevents a requests table query from slowing down normal postgres queries which function everywhere else in the application. As such splitting up the access rights is a must. Say in the most horrible of solutions Cassandra has a security vulnerability, it is impossible to get access information from Cassandra, to then take over user accounts. Obviously this is an extreme scenario, but it doesn't need the access tokens stored. The fewer places it's stored (even if it's stored securely) the better.
2. If page views ever had a bug/new feature where it should new queries, we wouldn't have to check to make sure it didn't leak any access tokens. It will always not leak access tokens since they're redacted. It creates a safeguard for non-leaking of authorization tokens.
3. Instructure from a sales perspective occasionally likes to run anonymized usage reports (and by occasionally I mean frequently), obviously this is agreed to by the school in some sense, either in the initial sign up of canvas, or in some other method; however this prevents sales employees (who do not have access to others accounts, even though they are internal because they don't need access), can't get access to accounts by making these queries/graphs.
The basic point of these redacted messages is part of a security push. Basically "Don't store tokens where they don't need to be (regardless if they're stored securely)", "Don't give people access to tokens who don't need it".
