Instead of adding new attributes for each cookie name we create
consistent attribute names. This should prevent any issues where we
have too many different unique attribute names because the cookie names
are unique to the user.
We added two new settings to make the number of cookies and groups
capture configurable:
- TOP_N_COOKIES_CAPTURED
- TOP_N_COOKIE_GROUPS_CAPTURED
Setting a new metric per cookie name resulted in a lot of metrics
getting added to New Relic. In some cases, this was causing other
more important metrics to not get registered.
We want to be able to easily figure out what our biggest cookies are and we
want to also group cookies by prefix because certain services create multiple
cookies and then put unique identifiers in the cookie name.
For example braze cookie names use the following pattern:
ab.storage.<userId>
ab.storage.<deviceId>
ab.storage.<sessionId>
In this case we want to group all the `ab` cookies together so we can see
their total size.
New attributes:
cookies.<group_prefix>.group.size: The size of a group of cookies. For example
the sum of the size of all braze cookies would be the value of the
`cookies.ab.group.size` attribute.
cookies.max.name: The name of the largest cookie sent by the user.
cookies.max.size: The size of the largest cookie sent by the user.
cookies.max.group.name: The name of the largest group of cookies. A single cookie
counts as a group of one for this calculation.
cookies.max.group.size: The sum total size of all the cookies in the largest group.
There is certain gating logic around pre-reqs, timed exams, etc.
that happen at the SequenceModule level, and should be respected
when rendering descendant XBlocks (like individual problems) that
are in that Sequence. Rather than do a risky refactoring, I'm
keeping that logic where it is and having the render_xblock view
climb up through the ancestor list to call the SequenceModule for
that gating information.
We do _not_ check all descendants (so cousin leaf nodes in the
sequence) for cotent-type-based restrictions because sequences can
become very large (esp. when content libraries are used), and there
is a performance overhead.
If the enclosing sequence is gated in some way, we redirect to the
render_xblock view for that sequence, where hopefully some useful
messaging will be available. This is a stopgap. That redirect
should never happen because we should never be calling the leaf
XBlock for a sequence that is restricted in the MFE. But if somehow
we get there anyway, either by bug or by intrepid user fiddling,
it's better to redirect somewhere that an error _might_ be surfaced
rather than just failing.
This will actually be a little overzealous and lock things down
that should be made visible later. If there's a timed exam and the
exam is completed, it should be the case that content is visible
(just read-only). This commit will block the content before the exam
starts (this is right), open the content while the exam is live
(this is right), but make the content unavailable after the exam
period has finished (this is wrong).
But I am going to go forward with this even knowing it's wrong
because:
1. The render_xblock endpoint should never currently be used in
timed exams in an intentional way. Neither the mobile experience
nor the courseware MFE support it.
2. This fix will address security concerns for creative access
patterns, even if it goes too far.
3. We're going to need to do a lot of work to address both pluggable
access permissions handling and special exams in the courseware
MFE, and a better implementation can be done then.
4. I've had multiple failed attempts to get this to work without
breaking things on and off over the course of weeks, and this
is a relatively low risk way of doing it that doesn't involve
a major refactoring (though the bill for that will come due
when we bring timed exams to the MFE).
