-Updated middleware setting to use use middleware insted of
middleware_classes
-github install of django-method-override fork to support
new style middleware in django1.11
Implementation details:
* Anonymous users are assigned a unique ID (like
`anon42c08f9996194e2a9339`) which gets stored in the django session.
`block.scope_ids.user_id` and `block.runtime.anonymous_student_id`
will both return this value.
* User state for anonymous users is stored in the django cache and
automatically expires as the cache gets pruned. Because user state is
stored, anonymous users can use interactive blocks like capa problems.
* There is no mechanism for upgrading to a registered account and
keeping user state since the user state store for anonymous users
(EphemeralKeyValueStore) is completely different than the one for
registered users (DjangoKeyValueStore/"CSM"), and has no "list all
keys" functionality.
* "User State Summary" field values are shared among [recently active]
anonymous users but are not shared with registered users.
* Anonymous users can only access the `public_view` of XBlocks, not the
regular `student_view`.
- retires toggle DISABLE_DEPRECATED_LOGIN_POST
- permanently removes /login_post
Now that studio signin has been retired, we are able to remove the
unused /login_post endpoint.
ARCH-1253
This completes the work started in https://github.com/edx/edx-platform/pull/19453
to use the LMS login and registration for Studio, rather than Studio
providing its own implementation.
LMS login/registration are being used for the following reasons:
1. LMS logistration properly handles all SSO integrations.
2. A single logistration is simpler to maintain and understand.
3. Allows Studio to work more like all other IDAs that use LMS
logistration.
The original switch to use LMS logistration for Studio also added the
toggle `DISABLE_STUDIO_SSO_OVER_LMS` to provide the community some
additional time for switching. This commit removes this toggle, which
at this point means all deployments will use the LMS logistration.
This change requires sharing cookies across LMS and Studio. Should that
prove to be a problem for certain Open edX instances, there are
discussions of possible alternative solutions.
See https://github.com/edx/edx-platform/pull/19845#issuecomment-559154256
Detailed changes:
* Fix some Studio links that still went to old Studio signin and signup.
* Remove DISABLE_STUDIO_SSO_OVER_LMS feature toggle.
* Remove old studio signin and signup pages and templates.
* Fix url name "login", which had different meanings for Studio and LMS.
* Use the following settings: LOGIN_URL, FRONTEND_LOGIN_URL,
FRONTEND_LOGOUT_URL, and FRONTEND_REGISTER_URL.
* Redirect /signin and /signup to the LMS logistration.
* Add custom metric `uses_pattern_library`.
* Add custom metric `student_activate_account`.
* Add Django Settings to allow /signin, /signup, and /login_post to be
disabled once ready.
This work also relates to ARCH-218 and DEPR-6.
ARCH-1253
We need to do this because when I tride to go to the JSON serializer a
bunch of tests started failing because various parts of our code are
putting things into the session that are not JSON serializable.
We can't keep using the default pickle serializer because it defaluts to
using the highest available protocol and that will cause issues with the
python 2 to 3 upgrade since both will be running in production at the
same time. We need to use a version of the pickle protocol that both
can use interchangably.
We also need to make sure we read with latin1 encoding to make datetimes
work correctly between the two versions of python.
This will force a logout as sessions fail to load but this should be a
more performant and secure serializer moving forward. The reason we
overwrote it in our config is that it previously used to be the default
and we didn't want things to breake and force logouts when we changed
it. We're no more okay with people getting logged out.
If this isn't installed, the sample_task provided by
openedx.core.djangoapps.heartbeat isn't imported, and thus are never
registered with the celery workers. This sample_task is used for the
extended heartbeat api call. Since the celery heartbeat check is turned
on by default, we should also make sure this djangoapp and thus
sample_task is registered by default. Otherwise the extended heartbeat
check fails with the default configuration.
We are currently running this plugin from a has directly off of master
to get support for a newer version of DJDT. However even on master
there is not yet support for python 3. We're running into this when
running runserver and when collecting static assets.
A quick survey of the development team at edX shows that people are no
longer actively using this debug panel.(14 responders all saying no to
the question "In the last year have you used the mongo portion of the
django-debug-toolbar in edx-platform?")
This makes sense since the module store and courseware related
developement is not very active right now. Given all this, I'm removing
this toolbar for now and if we need it again we can survey what's
available at that time to choose the best tool.
ENABLE_MKTG_SITE has been serving double duty to both indicate that
an Open edX installation is using a Drupal marketing site AND
is using the Publisher workflow tool for managing course metadata.
But now that publisher-frontend is available and the Publisher
feature is no longer tied to the marketing site, we want to tease
apart those two concerns. Hence ENABLE_PUBLISHER.
Only really used so far in Studio, to control which fields are
shown (if using Publisher, some fields are only editable in
Publisher).
- The fields need to be unicode not bytes. In python 2 it was auto
converting.
- The static url base has been allowed to be a unicode string for a
while.
https://github.com/edx/edx-platform/pull/20645
This introduces:
* A new XBlock runtime that can read and write XBlocks that are persisted using
Blockstore instead of Modulestore. The new runtime is currently isolated so
that it can be tested without risk to the current courseware/runtime.
* Content Libraries v2, which store XBlocks in Blockstore not modulestore
* An API Client for Blockstore
* "Learning Context" plugin API. A learning context is a more abstract concept
than a course; it's a collection of XBlocks that serves some learning purpose.
