Update Your LMS and CMS SECRET_KEY
Note that the following issues will result for updating the SECRET_KEY
Ephemeral tokens generated with the original secret key, say, for password resets or mailing list unsubscribe, will be invalid.
Users will be logged out as their sessions IDs will be invalid
Hashed tracking IDs in logs generated prior to the update will have a different obfuscated session id. This is less important because of item 2.
The obscured ids used in proctoring will also change. This impacts Proctortrack proctored learners directly. After the secrets change, the learner who user the old secret to establish their onboarding profile will fail graded exams because new user_id does not find the right onboarding profile. In MST-637 we changed proctoring to use a different non-rotatable key, and MST-639 covers making this new secret rotatable.
MFEs that don’t properly handle auth endpoints suddenly requiring re-auth will see a spike in JS errors until users have logged back into the LMS.
Please Note
You should not undertake this lightly and we cannot make any specific guarantees about the process described here. At a minimum, familiarize yourself with the uses of the Django SECRET_KEY described here: https://stackoverflow.com/questions/15170637/effects-of-changing-djangos-secret-key. Additionally, ensure you have current, valid backups of your data and test this in a pre-production environment thoroughly.
Step-by-step guide
Stop the LMS and CMS (unless you have a mechanism to hot-reload settings changes)
Update the lms.yml and studio.yml with a new secret key (same value for both files)
from django.core.management.utils import get_random_secret_key print(get_random_secret_key())
Restart LMS and CMS
References
https://docs.djangoproject.com/en/1.8/howto/deployment/checklist/