openedx / openedx/openedx-platform
[DEPR]: Marketing site login and user info cookies
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 8.2k
- Forks
- 4.4k
- Avg merge
- 6d 18h
- Merged PRs (30d)
- 42
Description
Proposal Date
2023-06-15
Target Ticket Acceptance Date
2023-06-30
Earliest Open edX Named Release Without This Functionality
TBD
Rationale
The following marketing site cookies were deprecated in code long ago, but they did not go through a DEPR process.
- EDXMKTG_LOGGED_IN_COOKIE_NAME
- EDXMKTG_USER_INFO_COOKIE_NAME
The 2U private marketing site is using these cookies, and is blocking removal. However, it is unknown at this time if anyone else in the community is using these cookies.
This would resolve potential security issues, login related bugs, performance and stability issues given that the user info cookie is ~1k, which is a large part of our cookie header size budget.
Removal
Copying details from ARCHBOM-1172...
Once the Marketing site is updated to use our new header component, we can remove:
EDXMKTG_LOGGED_IN_COOKIE_NAMEEDXMKTG_USER_INFO_COOKIE_NAME
Notes:
- Here is a link to code related to setting these deprecated cookies.
- The
EDXMKTG_LOGGED_IN_COOKIE_NAMEhas an existing alternative and simply should no longer be used. In place ofEDXMKTG_LOGGED_IN_COOKIE_NAME, we should be using frontend-auth code from frontend-platform to determine if the user is authenticated and to get basic information on the user. (This happens to use JWT cookies behind the scenes, but that should be encapsulated away.)- For
EDXMKTG_USER_INFO_COOKIE_NAME, there is not yet an existing alternative.- Using EDXMKTG_USER_INFO_COOKIE_NAME (until replaced):
- Do not use this cookie to determine if the user is logged in. See notes about frontend-auth.
- Only use this cookie for supplemental data if you have already checked that the user is authenticated using frontend-auth. For additional security, only use data from this cookie if the user matches the authenticated user, although that should be the case.
- Replacing
EDXMKTG_USER_INFO_COOKIE_NAME:- Some of the required data may already be returned from frontend-auth code.
- For data that is specific to this cookie, we should consider API calls that can use a local cache in place of a cookie.
- Not using a cookie would help our cookie size problems, because this is a big one.
- For data helpful to all MFEs, this could be loaded from frontend-platform.
- We probably don’t want to add more to the JWT cookie.
- For data helpful only to the marketing site, this data could be loaded from Prospectus.
- Using EDXMKTG_USER_INFO_COOKIE_NAME (until replaced):
- For
Replacement
Details included in earlier section.
Deprecation
It is already marked as deprecated.
Migration
No response
Additional Info
Additional notes:
- The legacy marketing cookies that are created at login predate our use of JWT cookies.
- The decision to deprecate the marketing cookies is captured in the code via names like
DEPRECATED_LOGGED_IN_COOKIE_NAMES. - The original JIRA ticket was
Note: This ticket used to beARCH-245`, which is what was used in the login cookie code comments. - It seems the mobile app ran into discrepancies with when and if the marketing site considers a user to be logged in, based on this outdated cookie.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in openedx/core/djangoapps/user_authn/cookies.py, especially the deprecated cookie names and their setting code. First confirm that the marketing site has moved to the new header component and that replacements exist for the user information data; done means both deprecated cookies can be removed without breaking authentication or required marketing-site data.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- authentication, backend, security
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100