Hi everyone,
we recently changed the LMS SECRET_KEY setting for one of the Open edX
instances we maintain, which resulted in different per-course
anonymous ids for students [1].
[1]:
https://github.com/edx/edx-platform/blob/open-release/eucalyptus.2/common/djangoapps/student/models.py#L149
For each student and course, a single anonymous id is stored in the
database. This stored id is used to retrieve the original user given
the anonymous id in the function user_by_anonymous_id() [2].
[2]:
https://github.com/edx/edx-platform/blob/open-release/eucalyptus.2/common/djangoapps/student/models.py#L201
If the anonymous id changes (e.g. because the SECRET_KEY changes), the
function anonymous_id_for_user() returns the new anonymous id, but
does not update the id stored in the database. So for users who
already have a stored anonymous id for a given course, the new ids
can't be inverted anymore, which causes problems for us.
1. Why does the function anonymous_id_for_user() compute a new
anonymous id even when there already is an id for the given user and
course in the database? It could simply return the stored id instead.
2. Why does the AnonymousUserId have a unique_together constraint on
user and course_id [3]? Without this, we could store multiple
anonymous ids per user per course, making it possible to invert all of
them.
[3]:
https://github.com/edx/edx-platform/blob/open-release/eucalyptus.2/common/djangoapps/student/models.py#L126
Since we already have multiple anonymous ids per user per course in
the submissions database, we would be particularly interested in an
answer to the second question. If we could remove the unique_together
constraint without breaking anything else, we would be able to fix our
problems with relatively little effort.
Cheers,
--
Sven
@OpenCraft