openedx / openedx/openedx-platform

[DEPR]: Marketing site login and user info cookies

Open
#32,343 8 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

depr
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_NAME
  • EDXMKTG_USER_INFO_COOKIE_NAME

Notes:

  • Here is a link to code related to setting these deprecated cookies.
  • The EDXMKTG_LOGGED_IN_COOKIE_NAME has an existing alternative and simply should no longer be used. In place of EDXMKTG_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.
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 be ARCH-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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.